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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …