The Only Agile Tools You'll Ever Need

Source: Tim Ottinger and Jeff Langr
Font: BrownBagLunch

Perhaps you were expecting a list of software products?

Agile's raison_d'ĂȘtre stems from backlash against "heavyweight" methodologies that insisted upon voluminous documentation, never-ending and never-useful meetings, and vendor-lovin' high end tools. Yet in 2010, there are at least three major high-price, high-profile agile project management tools and dozens of lower-end ones.

We contend that using one of these expensive software tools says, "you don't get it, and maybe shouldn't bother, because agile may not work well for you." No doubt this will perturb those of you who have found some value in agile management tools, so let's step back and talk through the issues.

Agile is primarily about team communication and collaboration. It is predicated on continual face-to-face interaction. Every step in the opposite direction decreases the chance of success. Kent Beck had it right: The best opportunity for success, still, is having all project members sit in a single room and work as a team, instead letting a bunch of self-interested individuals retreat to the isolated comfort of their cube.

There is no room in agile development for "avoidance technology." If you can't find a way to meet its demand for close-contact, continuous communication, then you are not ready. If you don't want your programmers sitting together, talking through problems, writing code socially, then try something else.  Attempting to bolt avoidance technology onto agile methods is like castrating a stud horse.

Once you diminish teamwork,  you have to compromise other agile principles. If we're not in the same room, we need more meetings to talk to one another. We need to write more things down and produce more centrally-stored documentation. We need to have more contractually-oriented agreements between people who really work on the same team, because we can't trust one another, because we're can't see each other face-to-face every day. The agile practices topple like dominoes.

There is always questionable rationale about why things must be that way. "Every project has to be split evenly between low-cost [read: offshore] labor and high-cost [local] labor." That's not a definition of project success, just a broad-brush attempt at cost control. Having some remote team members should never force all team members to work as if they were remote.

Perhaps the executives could use their hard-won corporate smarts to organize the teams differently. "Half our projects must be low-cost" should appease the bean-counters, and could just work. Here come the excuses: "But we don't have business experts who can act as customers in Bangalore." Really, that's a problem you can't solve? Having two truly agile teams producing quality code should be better than having two teams pretending to be, and failing at, agile.

If you want to succeed at agile, find a way to put each team in its own room. Give them the tools we list on the card, and they'll rarely ask for more. We guarantee they won't ask for a high-end agile tool, because they don't need one and don't want to be bothered with one. Executives of various stripes might ask for one, but all they really want is a simple way to view and present status across significant numbers of projects. You don't need a high-end, specialized, complex tool to do that, and you definitely don't need to waste the time of everyone across every agile team to do that (hint: see Tracker and Coordinator on Agile Roles card. This is what you pay project managers to do).


  1. Now that we've said that, you really need a good refactoring editor and a reliable coffee pot. And breath mints. And a CI computer. But you get the point.

  2. - coffee and ostensibly mints come under "food"
    - good refactoring editor comes under "pairing station." In the card that will appear in the book, we indicate that the pairing station comes replete with the best possible tools to create quality code.

  3. It is also probably worth noting that we're both remote agile developers right now. We are "virtually" present during work hours, and collaborate like crazy, and we know and expect (practically demand) that we'll be inconvenienced by being remote.

  4. I would add brains and hearts to the list

  5. I guess my brain/heart count, because most people do think I'm a big tool.

  6. How would you automate your tests? May be this would work for small co-located team of size 5-7 members!
    I'm not sure you have a scalable set of tools!

  7. We recognize that we should add "build/test servers" and "automated acceptance test tools," although that's not the point of the card.

    This minimal set of tools, BTW, has worked for many teams, including those up to triple the size you suggest. It's worked for organizations with numerous such co-located teams. But as you
    scale to and beyond that point, you start seeing communication issues. That's a limitation of agile-focused oral tradition, not of the toolset we suggest. As mentioned in the post, it just means you have to make concessions to agile, which means you are moving in the direction of less potential for success (at least if you buy into the precepts of agile itself).

    Most agile teams can do just fine without an expensive tool. Instead of justifying the use of one, we're suggesting that you should move in the other direction and find ways to eliminate constraint-reinforcing assumptions.

  8. What about DISTRIBUTED TEAMS? Any suggestions there? thanks

  9. Hi Donna--thanks for the inquiry. Both Tim and I work distributed and helped teams improve at being distributed. While it's not ideal, you can certainly succeed with distributed team members.

    To be fair, since we came down hard against conceding agile's strengths, we'll do a card on distributed agile in the future (maybe a month or two out--we're backlogged a bit).


  10. The first rule of distributed teams is not to have them. The second rule is that if you *must* have distributed teams, remember that latitude hurts but longitude kills. With increasing distance between members, the agile practices fall "like dominoes."

    Jeff touched on that a bit, above, suggesting that it is better to have a strong team in each location than a crippled team widely scattered across continents and time zones.

    Tim Gifford and I have conducted a workshop on remote pairing. Again the first rule is "don't." The second rule is "if you must then don't drag down the nonremotes."

    Our company (Tim G., Jeff, and I work together) has most employees on-site and a few of us oddballs off-site pairing via remote desktop/audio/video software. We remotes pair with on-site people who can ask questions, overhear conversations, view the work board, and keep us up to date.

    Being able to work from home is an advantage and a disadvantage. I am frankly surprised that it works at all. It does allow GeoLearning to hire people who aren't neighbors, and it allows us to work with a great company that isn't local to us, but it is not without some struggles.

    Again, first rule is "don't", second rule is "latitude hurts but longitude kills", and the third is "don't drag down those who are close enough to work closely." I'll let you know about the other rules when we make them up.


  11. Any suggestions for what to do if the team is co-located but the stakeholders are remote (distributed across NY, SF, and Japan)?

  12. Hi Malapine--

    Immediately the concern that comes to our mind is the bigger problem of stakeholderS, i.e. plural. One of the most important things is that the customer speak with a single voice. If you have many stakeholders, how are they coming to consensus on what they want and what has priority? Usually if you can solve that problem, the distributed nature of the project isn't quite as problematic. The goal would be to get to a single point of contact for all stakeholders, and have them available (on the phone, I suppose) as much as possible. This proxy would be the one who would need to clarify what the customer is looking for, and to accept what the team has produced.

    It's a tough problem without them being there.

  13. Dont forget version-control in the list of things right after "now that we've said that, you really need ..."

  14. @brad: Absolutely! That's not even agile or even software, that's basic development of ANY shared artifacts. It is so foundational, that doing any work without versioning should be considered unprofessional.

  15. Come see what else has been said along these lines?

  16. Hi! Nice article, it is very helpful and the comments too.

    I arrived here because Tim Ottinger suggested me this post because I was looking for an agile tool for Scrum, like Xplanner (it had to be Open Source)

    Perhaps I was not clear (I twitted my question). What I was needing was a tool to control de product backlog and the sprint backlog, because the experience teached me (as a developer on teams) that the team never team will complete all the documentation of the sprint, they just will add/remove stories, complete their board with the sprint backlog and use it as a tool to show to the product owner what they do and that kind of stuff (we dod that every sprint and it work very well).

    So, I think that it is important metion that because it is very difficult to control the backlogs from an spreadsheet or a simple text editor.

    Am I wrong?


  17. I'm not sure what you mean by "control" in this context, and what you're trying to prevent or cause to happen. Maybe a little more info and I can help?

  18. What I was trying to say is: If you dont have any software tool (like notepad, spreadsheets, gdocs, xplanner or anything you want), how can you manege (add, delete, and modify stories, mark them as duplicate, show them to the product owner, let him add new functionalities) your product and sprint backlog?

    The point is, Do we ever need a software tool (no matter the power, it can be Notepad or Redmine) or do you recommend some techniques or tips to remember all the product backlog and manege it on an easy way?

  19. The best tool we've seen in common use was a cork board with story cards attached and a set of simple rules behind it. As far as control, generally the customer or proxy (often a project manager) decides what goes onto or off of the board. If everyone is in the same room, the state of the sprint and the status of each story is always clear.

    Behind the scenes, the customer can (and almost always will) still choose to manage a project/product backlog. He or she can maintain this list on index cards, in a spreadsheet, or whatever, and choose to broadcast it or not (via google docs, email, etc). The point is that the team only controls movement of story cards (i.e. updating of their status) within the sprint. They do not update the backlog directly--that's a customer's job.

    [If your team is unfortunately deriving and controlling its own stories, then you'll need something to manage the backlog--as before, as simple Google spreadsheet will suffice. Give your product owner access to this. If you are worried about people corrupting the integrity of it, Google docs allows you to set read vs write access. But you then really have a bigger problem that access rights in a tool will only mask. ]

    A story board is not effective, of course, if your team is distributed. And that's really the primary point of the post. Distributed agile--which is counter to the values system of agile--demands software tools. Agile as intended and designed does not.

  20. > What I was trying to say is: If you dont have any
    > software tool (like notepad, spreadsheets, gdocs,
    > xplanner or anything you want), how can you manege
    > (add, delete, and modify stories, mark them as
    > duplicate, show them to the product owner, let him
    > add new functionalities) your product and sprint
    > backlog?

    It sounds like you could do all of those things via index cards. You can delete (throw away), add (add), show, modify (rewrite), and stack them up in piles for backlog. I'm not sure why you would need software for that.

    Now, there are tools that are neither agile nor non-agile, and those might include some kind of bug tracker (my employer uses jira), CI tools (hudson, cc, etc), and email, and production logging, etc. Anyone with half a brain has a good version control system (we like git).

    For tracking details, you should have your ATs. You can do a lot of backlog grooming by writing acceptance tests. They really are executable specification and executable documentation.

    If you have to have a fancy tool to manage backlog, I suspect your backlog is too large and too deep. You really only need to have enough stories in hand for the current iteration, the coming iteration, and maybe a few you're grooming for the one after that.

    As jeff says, being distributed hurts. We are in the midst of the "distributed agile" experiment, which works far better than we had expected but still has a obvious downside.

    But when someone asks "how do we manage hundreds of stories in the backlog", the answer is generally "don't have hundreds of stories in the backlog." When the question is "how do we get more detail on the cards" the answer is "don't put details on the cards, put them in tests."

    As a result, most of the need for tools is from having too much work in progress and too much of a big design done up-front. Neither is agile, nor lean. I think it is better for a team to wean themselves off of troublesome practices instead of devising electronic systems to enshrine them.

    Your mileage may vary, of course, and I'm willing to be convinced otherwise.


  21. Jeff and Tim, thanks for your answers.

    They were very clear and useful, I could learn a lot.

    I am very convinced about agile methodologies since I read about them at university (I am 21) and I got more convinced since I work with them, but I have to encourage myself to follow your advises because you success doing that.

    >If you have to have a fancy tool to manage >backlog, I suspect your backlog is too large and >too deep. You really only need to have enough >stories in hand for the current iteration, the >coming iteration, and maybe a few you're >grooming for the one after that

    So, my Product Backlog should have nearly the same number of stories than the sprintBacklog*2, isn't it?. Does it mean that the client must think on the project as a small piece of software since the first sprints instead of think about it as a big software and then trim the project?


  22. That's a reasonable number of _groomed_ stories. It doesn't hurt anything to keep lists and all. I don't want to cramp anyone's style, but for managing the work it's all about the art of immediacy.

    I worry when we're looking further into the future than we can reasonably predict. What will we be doing in 8 months? What will the priorities be in 4? What will the customers really want once we've delivered the first 1/3 of the system?

    So grooming stories (adding details, tests, acceptance criteria, etc) for distant dates and features a year out is waste, though thinking about the future is a good exercise.


Note: Only a member of this blog may post a comment.