Stefan Roock

All About Agile and Lean

To Tool or Not to Tool


A recurring question in my coaching engagements and training classes is about tools for Scrum (Product Backlog, Sprint Backlog, Taskboard, Burndown Charts). My recommendation is always the same: try index cards, pens, post it’s, card walls etc. My collegues at it-agile do the same.
Sometimes have the impression that we are very dogmatic when it comes to tools. I don’t think that I or my collegues are dogmatic. We simply base our recommendations on our experiences. Over the last 10 years we tried a lot of different tools and we have seen even more tools at our clients and the experience so far was always the same: for agile teams physical tools like index cards worked better than software tools.

But why work physical tools better than software tools?

Software tools are used with another focus than physical tools. Software tools are used for managing (e.g. for managing the Sprint Backlog). Physical tools facilitate communication and cooperation. When somebody moves an index card at a card wall, the other team members can see that directly and step into a discussion. When somebody changes the status of a ticket in an issue tracker nobody notices immediately and starting a discussion is unlikely.

And facilitating communication is more important than easy management?

This question is easy to answer with a look at the agile manifesto: The first value statement of the agile manifesto reads „Individuals and interactions over processes and tools“. And principle number six says: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Yes, communication and cooperation is king.

So whatever tool is used communication and cooperation should be the goal, not management. And I think that this goal is easier to achieve with physical tools than with software tools. But in the end the decision is up to the team.

Things to try

  • The team should at least try physical tools for one Sprint to make an informed decision.
  • As ScrumMaster shield the team from existing tools and do the mapping from the physical tool to the software tool during the trial period.

Published by

stefanroock

5 Antworten zu „To Tool or Not to Tool”.

  1. Avatar von Meike
    Meike

    Great Post!

    I would add two more advantages, that are very important to me:

    First of all, people often underestimate the difference in satisfaction between a haptic system and a tool. To klick a checkbox isn’t nearly a satisfactory as to manually move a physical ticket. And satisfaction can drive us very far!

    The second advantage I see is visualization. Most tools provide a way to change how you see the information. That may be useful in various cases, but it often leads to a state of dis-information. No matter if you use some kind of spreadsheet or a tracking-tool, if you customize your view, you no longer see the big picture in the after.
    Most people reduce their view to the tasks they work on. Maybe they don’t want to see how much work really needs to be done, And once they have this reduced view, they mostly don’t tend to go back to a view where they can see the whole lot of information.
    Sometimes they even say their screen is not big enough to show all the work to be done. There is (almost) always a wall that can hold all your sticky notes.

  2. schlossBlog » #466 IT-Reader

    […] for Fools auseinanderzusetzen, beschäftigt sich Stefan Roock mit der existentiellen Frage: “To Tool or Not to Tool?”.  In diesem Zusammenhang ist es schon beinahe nebensächlich, dass er sich dabei mit dem […]

  3. Yes We Kanban « Alles agil

    […] Akteure häufig besser unterstützen. Stefan Roock hat dazu den meiner Meinung nach richtigen Text To Tool or Not to Tool […]

  4. Avatar von d:evolute (@d_evolute)
    d:evolute (@d_evolute)

    what about remote teams?

  5. Avatar von stefanroock
    stefanroock

    With remote teams there may be a need for an electronic Product Backlog and/or electronic Taskboard. It depends on the context. If the Product is remote from the development team but the development team itself works co-located, you may need an electronic Product Backlog but not an electronic Taskboard. If the development has two locations you may avoid an electronic Taskboard by using the buddy concept and having a physical Taskboard at each site. And if there is really the need for an electronic Taskboard I would experiment with a hybrid solution like JimFlow (http://jimflow.jimdo.com/).

Hinterlasse einen Kommentar