Agile Tooling: A Point, Counter-Point Discussion

team-oriented aspects of software development, my concerns about tools generally increase. In particular, new agile teams commonly ask what time-tracking, task-tracking, or bug-tracking tools are recommended. I generally respond with the suggestion that white boards, cork boards, and cards are the best planning and tracking tools I know of for within the team. The primary reason for this is that these tools are more collaborative than the typical computer-based tools.

I have watched many teams plan or track their iterations using the available tools. The process seems almost always to go like this:

Some person in the room, often the ScrumMaster or equivalent, brings the tool's screen up on a projector. Then they go around the room one person at a time, asking that person what they worked on, what they're going to do next, and so on.

At base, this is a reporting process not a conversational process. As such, it is a weak form of communication compared to, say, a discussion. The team is taking turns being asked questions by some leader and answering them.

Compare this to a meeting around a table with cards on it, or around a white board where anyone can grab the marker. A meeting like that becomes much more dynamic, with the center of the meeting flowing around more freely as people have things to contribute. It is less controlled and more interactive--and that's a good thing in my book when it comes to teamwork.

Ryan:
Since our early days, we have been following your lead and others' by teaching teams to form co-located and dedicated teams to enable this type of collaboration. You clearly articulate why there is no better tooling answer than white boards and cards for individual teams and bottom-up team adoption of agile. However, white boards and cards are not enough to support agile development on larger programs, teams of teams, or distributed teams. In these environments, people need tools and techniques to bring the benefits of agile to medium and large teams.

I find that multiple-team agile starts when your team has more than 10 or 12 people. At that point, you need to break into multiple teams of seven people, plus or minus two. However, once you create two agile teams, the issues of coordination, synchronization, prioritization, and commitment tracking across teams start to increase. Scrum works to address this with Scrum of scrum meetings, but in my experience that meeting and release readiness needs to be supported with some form of artifact management for distributing the backlog and coordinating multi-project dependencies.

Here's where APM and AALM solutions make a big difference over earlier predecessors. Waterfall processes and plan-driven approaches drove suites of highly specialized tools for individuals and inventory/workflow tools for groups. These first-generation tools were part of the problem--they helped reinforce the walls between roles and encouraged the management of large inventories of requirements, bugs and enhancement requests that built up during the process. Managing all this work-in-process was a huge waste on the delivery process. It helped reinforce the high cost of change and the need to get things "right" up-front.

With the guiding ideas from agile and innovations in the collaborative infrastructure of Web 2.0, the industry has spawned a new breed of tools. These new tools leverage the messaging, signaling, and lightweight machine interfaces that make coordinating and collaborating among distributed teams, roles, and players easier. Today's tools don't need to do many of the things first-generation tools did, including compile perfect documents, load-level resources, and drive hand-off workflows. Although second-generation tools have fewer features, they instead obsess on the usage, quality, and user enthusiasm for each feature.

AALM tools are beginning