Ryan:
Ron, I'm very proud of the planning and tracking tool that my company builds andmarkets, and there's something I've been wondering. You're always pushing forsimple tools like cards and paper charts. Do you have something against tools? Are you still coding in binary out there in Michigan?

Ron:
Well, Ryan, I do trust some tools ... and not others.
As one of the authors of the Agile Manifesto, I do value individuals and their interactions more than I value their processes and tools. The right individuals, interacting well, will find or create whatever processes and tools will serve them best. The best processes and tools, on the other hand, can't bring effectiveness to the wrong individuals, interacting poorly.

In development tools, I would favor having the strongest and best you can get. Today those might include Eclipse and Java, or C# and Visual Studio. {sidebar id=1} Or perhaps Ruby on Rails. There are lots of excellent platforms for development, and any team should use the best one they can get.

Agile projects are inherently iterative, and therefore the design evolves over time. To do that well requires refactoring, and it's therefore valuable to have the strongest refactoring tools possible. I might even favor a development platform a bit more if it had better refactoring. To support refactoring and make it safe, we need tests. Almost every platform we might use has its own JUnit or NUnit or xUnit, and I consider that tool to be on the mandatory list.

Most of the above are individual developer tools. There are also development tools that support team interactions, and I'd favor using some of those as well. I'd like to see a good code manager, supporting frequent check-ins and making it easy to keep all the developers' code synched up. I'd like to see a solid automated build system to keep the code integrated all the time.

Ryan:
I like to think of development tools as the "go fast" tools. By keeping the cost of iterating down, the business and technical teams are not forced into a typical mode of trying to get things right up front. In contrast, teams that employ quot;go fastquot; tools can work in small, maybe even parallel, chunks to find the simplest design to do first.

For me, the critical signaling for these technical teams is to have the visibility to "stop-the-line" when there is a problem that is urgent, like a broken build or customer-facing defect. The team has to be presented with these signals in a way that forces them to stop and keep from building on a house of cards. This type of signaling is a fine art; it needs to be big and bold, yet not generate too many notices that people will ignore it. I like physical lava lamps, orbs, but I also like them combined with virtual counterparts too. Teams that practice "stop-the-line" discipline clearly illustrate that they get the notion of flow and iterating on small increments quickly.

Beyond technical tools, the business needs to have simple and effective tools in place for soliciting, engaging, and managing feedback from stakeholders on these rapid designs, increments, alternatives and market dynamics.

We know from the simple physics of agile and agile tooling surveys that customers want tools to help them adopt and mature their agile disciplines.[i] They want help working in small batches, bringing testing forward, getting clear visibility, and reducing wasteful inventories to enable a smooth flow of value. This is the genesis of Agile Project Management (APM) or Agile Application Lifecycle Management (AALM) solutions.

Ron:
As we move beyond technical practices into the more 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 to be integrated with "go faster" tools, but primarily they help growing teams expand and help larger incumbent teams manage synchronization. To enable this coordination, the iteration teams use these tools to reflect status and enable roll-up of task, story, test, and defect status. To reduce the collaboration burden on iteration teams, AALM tools work to make it easy to round trip from white boards and cards to tool and back again. These products serve a critical visibility role that is almost impossible to achieve when you try to roll-up white boards.

Ron:
I do agree that larger teams need the kind of tools you describe. In addition, there is always a need to communicate upward and outward, and those external communications often need to be more fancy, better formatted, more "corporate."; However, even though in a sufficiently large situation I might well use such a tool myself, I still don't feel comfortable recommending that an organization start out by using such a tool. The reason is that I fear that they will never get back down to putting their hands in the soil and working the garden. They won't have the opportunity to develop the kind of intimate teamwork that is possible, and as such they'll never really get the benefits that we spoke of when we wrote about "individuals and interactions."

You begin to see the pattern, I hope. I think that people and how they interact on a project are the most important thing, and I think that they need to create a way of working--a process--that works best for them. Because their interactions are critical to project success, I suggest that teams begin the work with an approach that will bring them together as people, not one that will let them remain apart, communicating electronically.

Ryan:
I live by and teach your perspective. I know it to be the best way to adopt agile and run iteration teams. For me, the debate is around the value and alignment of AALM tools for bringing the benefits of agile to medium and large teams.

Ron:
I'm with you on that. agile-focused tools are far more appropriate than the previous generation of tools. They understand the agile cycle and support the agile ideas. While I would like everyone to start with cards, pens, and white boards, many teams are going to wind up using tools. When they do that, they should use the best tools out there, and today, those are the ones that are focused on agile.

[i] Agile Project Management Tooling Survey, Pete Behrens, Trail Ridge Consulting, December 2006.