Agile Tooling: A Point, Counter-Point Discussion

It has been six years since the authoring of the Agile Manifesto, and the technology and tooling landscape has changed since then. This conversation between Ron Jeffriesand Ryan Martens debates the merits and weaknesses of tooling agile.

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?

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.

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.

As we move beyond technical practices into the more

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.