BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

What Makes a Tool Agile?

by Amr Elssamadisy on Oct 10, 2007 |

Individuals and interactions over processes and tools is the very first of the values of the Agile Manifesto.  Tools, however, seem to be a big part of development on most Agile teams.  When does a tool help and when does it hinder (Agile) software development?

Chris Woodell put together a list of Agile Tools for .NET and briefly described each tool.  This list included tools such as NUnit, Nant, and NCover.  Kirk Knoernschild, among many others, wrote a review of tools that support Agile practices and included many of the Java versions of tools such as JUnit, Ant, and CruiseControl (and others). 

In both of those reviews there are tools that obviously fit in 'Agile' development, but many others that are just good for good software.  What they both lacked were project management tools such as VersionOne, Rally, and Mingle.  These tools, however, are purely targeted at Agile development teams, but are more controversial. Ben Hughes asked Are Automated Agile Tools Tactile Enough? And Ryan Martens (of Rally) and Ron Jeffries had a debate on the value (or lack-thereof) of planning tools.

There are several classes of tools used by us in the Agile community:

  • Tools that are good for software development, regardless of development process.  These are tools such as source control and bug tracking tools that don't necessarily make a team  more or less 'Agile'.
  • Tools that support Agile practices directly and are consistent with values and principles of the Manifesto.  These are tools like xUnit and continuous integration servers.
  • Tools that support Agile practices at a cost/trade-off against one or more principles of the Manifesto.  These are tools like the planning tools that reduce human interaction and possibly tools that generate tests for you and discourage the thought process that goes with test-first development.

What tools have you found absolutely necessary for Agile development?  Have you experienced tools that discourage good practice and/or communication?  If so, what are the trade-offs to be made?

 

Hello stranger!

You need to Register an InfoQ account or or login 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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

What the team wants by Kerry Buckley

I know it's a massive generalisation, but in my experience the tools that add value are those that the team wants, and that they've adopted to address a specific need.

The ones that get in the way are usually those that are imposed by management (often a specific planning/tracking tool).

Flexibility & Hot Communication by Paul Oldfield

I favour tools that take the drudgery out of the work without taking the flexibility. I favour tools that aid communication without making it 'cooler'.

It all depends on the circumstances by Siddharta G

I might be biased ( I write an agile project management tool - www.silverstripesoftware.com ) but this is how I view the role of project management tools in agile software development.

The question is whether the tools come at the expense of interactions or as a supplement to the existing process. A tool like JUnit is pretty clear cut because it is not replacing anything - or is it? Jonathan Kohl has an example where manual exploratory testing is not done because of an over reliance on automated tests and mock objects - www.kohl.ca/blog/archives/000182.html In this case perhaps the automated tests should have been complimenting manual testing, not replacing it.

In a similar vein, for a completely co-located team there is no need for a PM tool because the existing communication modes are pretty rich. When the team is distributed, the existing modes of communication are poor and the big visible charts are not visible anymore. In such a context, perhaps there is a need for PM tool to supplement (not replace) existing communication and keep everyone in the project synchronized.

I agree that running a process around a PM tool can get dysfunctional. That's why my personal preference is for a PM tool thats as lightweight as possible. However, larger enterprises might need something more heavyweight. Again it depends on the state and context of the project.

It's not the tools by Dave O'Hara

In my opinion it's not the tools that are agile but rather the practices and principles, continuous integration, unit testing, code coverage, etc., that they support. We need to be careful in labeling certain tools as "agile" vs "non-agile" given the spectrum of their implementation.

Re: It all depends on the circumstances by JS Bournival

Did not had a whole lot of experience with it, but Mingle looks pretty nice! I just attended a webex session with the thoughtworks folks and they did a great job.

JS

Re: It's not the tools by Amr Elssamadisy


it's not the tools that are agile but rather the practices and principles, continuous integration, unit testing, code coverage, etc., that they support.


I was wondering if someone would catch that. I agree with you 100% So, do these tools really support Agile practices or inhibit them? Which ones?

Re: It's not the tools by Bruce Rennie

A tool can be agile right up until the point where it inhibits or prevents a practice or principle in use by an agile team. Then it's not. :)

Perhaps what really identifies an agile tool is the willingness of a team to abandon them as soon as they outlive their usefulness.

Re: It all depends on the circumstances by Amr Elssamadisy

Tools look useful - and in the case of Mingle - pretty cool! The question is, do they inhibit or help practices?

So does mingle inhibit or enhance communications when compared to face to face meetings with whiteboards and stickies? Does it help the team to recognize and respond to change quickly? Does it replace Big Visible Charts (aka Information Radiators) for communicating important issues? If not, do the teams that use it continue to use Information Radiators or not?

Re: It all depends on the circumstances by Paul Oldfield

If I may combine my response with Siddharta's; in some contexts adding a PM tool makes the communication 'hotter'. In these cases it is 'good'. In other contexts it makes the communication 'cooler'. In this case use of the tool should be questioned. If we are using the tool as a proxy for a face to face talk, could we gain by having the face to face talk, or would that be too much pain? I suggest that if the team is all in the same room anyway, the conversation should be face to face. That does not rule out using the tool for recording decisions, if this is still of value.

So - Am I hearing "It Depends?" by Amr Elssamadisy

It sounds to me that all the comments point to the 'agile-ness' of the tool depends on the team using it. That there is no common context where a tool is always helpful (or a hinderance) to agility.

That sounds like a classic consultant answer. But is the classic consultant answer wrong in this sense? Are there always patterns of success/failure? If so - what are they?

Ok, so I'll answer one of the questions, IMO: Project Management tools are almost always a hinderance when used with a co-located team in running agile meetings such as stand-ups, retrospectives, and iteration planning meetings.

Re: So - Am I hearing "It Depends?" by Siddharta G

IMO: Project Management tools are almost always a hinderance when used with a co-located team in running agile meetings such as stand-ups, retrospectives, and iteration planning meetings.


Well, you have specified a particular tool and a specific context where it is a hindrance. I agree with you, it is the same thing I said in my comment above and what Paul and others have said.

What if the team is distributed? Or sometimes the organization needs to use it perhaps for regulatory reasons or for recording decisions as Paul posted in his comments. Or perhaps top management want visibility into the project and they are not co-located. In these other contexts it might be useful.

So there are some contexts where it is useful and some where it is not.

I don't agree that there is *always* a pattern of success/failure with a particular tool. There are successful agile teams that use a PM tool. Teams at Thoughtworks use Mingle internally, and it does not make them less agile. It's just the way that they use it and the context in which they use it that makes a difference.

Re: So - Am I hearing "It Depends?" by Amr Elssamadisy


Teams at Thoughtworks use Mingle internally, and it does not make them less agile. It's just the way that they use it and the context in which they use it that makes a difference.


Being an ex-ThoughtWorker myself, I know that TW folks are not super-human :) With that said, please explain to me how using a tool like Mingle in a stand-up meeting, a retrospective, and/or a Iteration Planning meeting can be as effective as using physical cards and white-boards.

Can people pass cards around? Can they have parallel discussions? Can they create designs and requirements in an ad-hoc manner? Of course not. There are not enough degrees of freedom from *any* tool to do this.

Re: So - Am I hearing "It Depends?" by Siddharta G

You are missing the point. I, and everyone else have already said that a completely co-located and self contained team does not need one. We are talking about other contexts, like distributed teams, or when the decisions need to be recorded for some other reason, or when top management needs visibility in a particular format, where PM tools can be helpful.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT