Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
What Makes a Tool Agile?
Posted 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?
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Case Study: IBM's Agile Transformation
Five Key Practices to Agile ALM
Agility at scale, become as agile as you can be
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
What the team wants
by
Kerry Buckley
Posted
Flexibility & Hot Communication
by
Paul Oldfield
Posted
It all depends on the circumstances
by
Siddharta G
Posted
Re: It all depends on the circumstances
by
JS Bournival
Posted
Re: It all depends on the circumstances
by
Amr Elssamadisy
Posted
Re: It all depends on the circumstances
by
Paul Oldfield
Posted
It's not the tools
by
Dave O'Hara
Posted
Re: It's not the tools
by
Amr Elssamadisy
Posted
Re: It's not the tools
by
Bruce Rennie
Posted
So - Am I hearing "It Depends?"
by
Amr Elssamadisy
Posted
Re: So - Am I hearing "It Depends?"
by
Siddharta G
Posted
Re: So - Am I hearing "It Depends?"
by
Amr Elssamadisy
Posted
Re: So - Am I hearing "It Depends?"
by
Siddharta G
Posted
-
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). -
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'.
-
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. -
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.
-
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 -
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? -
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. -
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? -
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.
-
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. -
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. -
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. -
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.
13 comments
Watch Thread Reply