Search

Wednesday, October 01, 2008

The role of tools in agile planning

The value of tools
I had a great discussion this morning with the CEO of a company which makes a production management tool that supports agile methods. We discussed the issues of tool use on agile teams and the opportunities for providing tools that don't yet exist.

I am not a big fan of tools that help automate sprint backlog management. Management of the sprint backlog (tasks that the team estimates and updates to achieve their sprint goals) is best left to the team. Any tool that takes any of that ownership away from them is going to harm the team's ability to commit to their sprint goals and take control of improving their effectiveness. Sure, it might save the Scrum Master five minutes a day in producing a burn down chart, but the Scrum Master's role is to facilitate the team to become self managing and commitment driven. Sprints are about adding value and commitment, not about perfect task tracking.

On the other hand, tools for backlog management are very valuable. Product backlogs are living complex plans for the product and must be frequently updated by the product owner to remain relevant. Tools can help.

So what do we look for with tools?'
First and foremost, a tool used to support an agile team must be built with the agile manifesto in mind. The first value applies in full:
Individuals and interactions over processes and tools.

While we value processes and tools, we value individuals and interactions more. Are these at odds? No. Processes and tools can support individuals and interactions. Certainly any process built using Scrum properly supports individuals and interactions. What can tools do to support them?

Let's take mind mapping tools for example. Teams have built and managed entire product backlogs using these tools. Mind maps allow a hierarchical structure to be built and viewesdwithout losing sight of the whole. Teams can form around entire branches of features (e.g. online multiplayer team). Some of these tools allow nodes in the map (user stories) to be prioritized and estimated. During release planning meetings, having the mind map displayed on a projector or large printed format can focus the meeting. It contributes to collaborative meetings where everyone contributes. If you want to have some fun brainstorming a backlog, provide the team with a very large sheet of paper and half a dozen colored Sharpies and have them create a mind map right there.

Compare using Excel spreadsheets to manage the product backlog or release planning, which is common. Hierarchies are not clearly seen in the column-row format of a spreadsheet. It's easy to get lost in the details and forget the big picture. Although I love using Excel for numerous functions, when someone displays a product backlog spreadsheet on the wall, the room usually becomes quiet.

Mike Cohn has suggested another way to visualize a large product backlog. I'd love to have a tool that supports this view!

So how can tools contribute to the value of "individuals and interactions"?
  • Mix global and local views together. Have a view of the data (backlog, plan, etc) that can be zoomed in and out rather than page-flipped. Page flipping a view probably sheds 50% of the context for people in the meeting unless they never blink.
  • Focus on tools that capture collaboratively driven knowledge rather than isolated data entry. For example, have a tool that projects the release plan, one story at a time, and prompts for the story point estimates during a poker planning session. Don't create a poker planning tool that allows everyone to estimate from their desk. The design discussion during poker planning is the point of the exercise!
  • Information radiators are solid gold (burndown charts, unit test coverage, build stability, release plan, etc). Tools should print them out whenever possible and support large format printers.
Distributed teams can't avoid some of the problems with their reliance on tools. The fact is that distributed teams have a harder time achieving the same velocity as co-located teams.

The good news is that the tool makers are listening. New versions of tools are being developed (some even using the agile process) to better support the needs of agile teams.


4 comments:

Dusan Kocurek said...

Hi,

take a look on ScrumDesk, please. It supports treemap view on the backlog. This view was developed based on Mike Cohn's article.

Dusan Kocurek
ScrumDesk Product Manager
http://www.scrumdesk.com

Clinton Keith said...

Hi Dusan,

Looks good. I liked the poker planning tool...exactly what was described.

Thanks,
Clint

Michael Dubakov said...

We at TargetProcess develop agile OM tool as well and I do agree with your points.

Check for example this post:
Agile Software Tool will not help you to understand Agile
http://www.targetprocess.com/blog/2008/09/agile-software-tool-will-not-help-you.html

Also we have the white paper about the topic.
Agile Tools: The Good, the Bad and the Ugly
http://www.targetprocess.com/LearnAgile/Whitepapers/AgileTools.aspx

Shubasree said...

Agile Development Software – ThoughtWorks
http://studios.ThoughtWorks.com

Agile Development Tools & Agile Project Management Software from ThoughtWorks help increase efficiency and cut down time. Try the ThoughtWorks Agile software development tools & see how they can help you in project management