Skip to main content

Managing Scrum: The Right Tool for the Job

So what is the best tool for managing Scrum? Well, it depends. It depends on you and your situation. Michael Dubakov recently asked When is a whiteboard a better choice? He proposes a decision matrix to evaluate the choices, based on a list of 9 criteria:
  1. Planning process
  2. Plan visibility
  3. Plan update
  4. Velocity tracking, Time tracking
  5. Burn Down Update and other charts update
  6. Communication
  7. Reporting
  8. People involvement
  9. Cost
Agile Tools Decision Matrix

I've captured Michael's Agile Tools Decision Matrix in a spreadsheet which you can download and modify to suit your needs. Just as an aside, he also stumbled upon a great name for cards, post-its and manual burndown charts: tangible tools. Even though he didn't really use it, I love it! It's succinct and correct, and the inherent advantage of tangible tools just jumps off the page - I will use the term moving forward. 

When to use tangible tools

Tangible tools are great for learning the processes and principles. Hung on the wall, they radiate information for all to see. They are extemely flexible for structuring and displaying information. Use them to get started with Scrum. Use them as long as you are happy with them.

I like to use tangible tools for initial planning (getting personae & and first cut at the user stories in a group workshop) and retropectives. In both cases the volume of information which needs to be permanently recorded is small and the flexibility and collaboration requirements for creating the information are high. I would also think about complementing a dedicated tool by hanging burn down charts on the wall: either printouts or manually maintained copies, especially if management is collocated.

When to use Office and Wiki

The use of office tools as a primary agile management tool appears to be on the decline. The dedicated tools are better.

Office tools are really good for slicing, dicing and presenting data. Dedicated tools can be great and do many wonderful things, but there is always something they won't be able to do or won't do the way you want it, and for that you need the flexibility of an office tool suite. So the data import/export is an important feature of these tools.

While using Target Process as a primary management tool, I have used Excel or OpenOffice to record the Sprint Contract, allocate costs between two parallel projects, and do preliminary scheduling. The Wiki has been useful for storing information about the project which does not readily belong to a story, feature, release or sprint (although this is a very small amount of information).

When to use Dedicated Tools?

When you need to. ;-) The advantages of dedicated tools range from information reuse, handling multiple or geopgraphically far-flug teams. A customer of mine wants to have one tool and one process for coorindate work and information flow across 3 suppliers.

How to decide for yourself

Start with Michael's Agile Tools Decision Matrix. Think about the importance of the various criteria. Perhaps there are others which are important to you. But feel free to tweak the weightings and the scores to get a result that you like. (uh - the politically correct phrasing is 'get a result that applies to your situation').

What do I do? I start with cards for teaching Scrum. I like cards for the initial concept and planning workshops and for the sprint retrospectives. I also use cards to manage my own work (just me planning my work a scrum coach and trainer).

Beyond that, I like web based tools. Available everywhere, even on the train. Manage workflows, find information effectively, reuse information. The bigger the project (and the longer the product should live), the more important these advantages. I think these factors explain the growth in dedicated agile project management tools over the last 18 months.

Comments

Scrum Tools said…
I personally found that the best tool for managing scrum is Excel. More recently i moved to ScrumEdge (http://www.scrumedge.com) because it saves time when setting up.

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …