The Agile Manifesto values "individuals and interactions over processes and tools". Historically, this value has discouraged the use of software tools and encouraged more use of white-boards, index cards, and other low-tech tools. The Agile Journal's April issue reexamined the relationship between tools and agile development. The diversity in the articles mirrored the current diversity in the community.
Ron Jeffries, one of the authors of the Agile Manifesto, and Ryan Martens of Rally Software debated the usefulness of tools on software development projects. They agreed on the usefulness of technical tools such as a good IDE with a built-in refactoring and a continuous integration machine. They disagreed on team-oriented tools. Ron indicated that he was against the use of these tools because, more often than not, they inhibit communication:
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.Ryan answered that tools are a need for larger teams - that whiteboards and index cards cannot scale:
Agile Application Lifecycle Management (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.
The other articles in this issue highlighted different sides of this debate. John Scumniotales wrote that times are changing - that wide scale adoption of Agile methods and practices are necessitating the use of tools - we have no choice if we want to succeed. Dave Hoehn, in the Renaissance of Paper, took a different approach and encouraged that low-tech solutions because the physical aspects of these tools reinforce the non-tangible work of software development. And Jim Reuhlin made the argument that what makes an Agile team perform well is their level of collaboration - the use of tools should be measured against how much they enable effective collaboration.
The common thread to all of the articles was that of communication and effective collaboration - the question is do tools hinder or help communication and collaboration? This view has much in common with Alistair Cockburn's model of software development as a cooperative game of collaboration and invention. Therefore we need to keep this end-goal in mind when we use tools in software development.
