Agile Tools Usefulness Debated

by Amr Elssamadisy on Apr 26, 2007 |

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.

Related Editorial

Agile Executive Primer: Partnering Across the Organization

10 Key Guide Points for Continuous Delivery

How do you Develop a Shared Understanding on an Agile project?

Continuous Delivery: A Maturity Assessment Model

How do you estimate on an Agile project?

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Small teams/multiple projects by Nick Coyne Posted

Re: Small teams/multiple projects by Amr Elssamadisy Posted

I feel the pain by Bruce Rennie Posted

Re: I feel the pain by Deborah Hartmann Posted

Re: I feel the pain by Ryan Martens Posted

Re: I feel the pain by Sudheer Raju Posted

Small teams/multiple projects by Nick Coyne

We find tools help in our web development environment - we are a small team (3 devs & 5 designers) that will run 5+ projects simultaneously. Sometimes some of the team will be working remotely. So using ProjectCards provides a central point to communicate around and also facilitates communication with remote parties. When we were using physical cards and whiteboards things were always out-of-date. Using a software tool has helped provide some discipline.

I feel the pain by Bruce Rennie

For one of our projects, we currently track using index cards. So far, it works just fine. At the same time, I've been evaluating some of the new agile tools that are out there.

What really baffles me is how quickly the vendors of these tools seem to forget the value of "simplicity". I don't really want my agile tracking tool to look like Microsoft Project, but that's what a lot of them smell like to me.

You know the part of index cards that really doesn't scale well? Writing out a few hundred of them after a good breakout session at the start of a project. So far as I can tell, none of these tools make that any easier. If fact, it's even more tedious with all the mousing around and entering things in extra fields I really don't need.

Re: Small teams/multiple projects by Amr Elssamadisy

That is really interesting. Can you tell us more? Coming from a <em>lean</em> perspective (ala Mary Poppendiek) we would expect to see a slow-down because of the multi-tasking of 5 different projects at once - thus the need for tools to alleviate that slow down. Would this be an accurate representation?

Re: I feel the pain by Deborah Hartmann

You know, I'd be happy with something like my Excel spreadsheet, but that wouldn't break when a user accidentally hits the wrong key. Everything in one place, multi-user, protected against concurrent update, can be filtered, sorted...

I agree: mousing around and filling in a dozen little boxes has turned me off a number of tools, just from looking at their screenshots.

Re: I feel the pain by Ryan Martens

Bruce,

So we know your pain, and we provide a couple of things to make your need of bringing lots of stories into a backlog quickly.

At Rally, we provide three answers for fast recording of stories:
- a quick import template from spreadsheet
- an AJAX-enabled UI that allows for inline additions in spreadsheet/dashboard mode
- a pop-up editor with "Save & New" capabilities (the only required field in Rally is "Name" on a Story

All of these controls happen on our Dashboard pages to keep you in context to the iteration, release and project that you are working in. We try to make those dashboards the center of your world and give you all the rich functionality you need right there.

Go ahead beyond the screen shots and try out our hosted service. You will see that it is not just a static web application, but a rich environment to help teams realize the benefits of agile. (shortening cycles, burning visibility, pulling testing forward and prioritization based on value and feedback)

I hope this provides some light on both your question and Deborah's point about screenshots.

Re: I feel the pain by Sudheer Raju

Bruce not sure if you have tried few tools like AgileBuddy or upcoming tool SwiftKanabn they appear to have very simple interface with very less clicks.....

You may also wish to refer to www.toolsjournal.com for all agile tools listed with detailed features/screenshots/videos.......