Agile Tools Usefulness Debated

Posted by Amr Elssamadisy on Apr 26, 2007

Sections

Process & Practices,

Development

Topics

Agile ,

Artifacts & Tools ,

Agile in the Enterprise ,

Agile Techniques

Tags

Information Radiators ,

Scaling Agile ,

Agile Manifesto ,

Continuous Integration

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.

1. Back to top

   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.

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   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?

   Reply

4. Back to top

   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.

   Reply

5. Back to top

   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.

   Reply

6. Back to top

   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.......

   Reply

• Older >