Shane Hastie and I taught our Working with Geographically Agile Teams workshop last week in Sydney. One of the questions that arose is “What tool do I use with a distributed team?” That same question is on the scrumdevelopment mailing list this week.
Shane and I don’t know what is wrong with a whiteboard and cards and stickies, updating the board at the standup and taking a picture of it, making sure everyone receives a picture of the board wherever the heck they are, and then they can see the board, or they can update their board. It’s fast and easy. And, unless you are trying to coordinate a program of many teams, it’s quite reliable. Program management may require other tools, especially if your management has dispersed several feature teams around the world.
Why do people want to move to tools when they can barely use agile approaches to their projects? If you can’t stick to a timebox, a tool is not going to help. If you can’t finish your standup in 15 minutes, a tool is not going to help. In fact, futzing with a tool during your standup will only prolong your standup. If you don’t have team agreement on what done means, a tool won’t help; it will only obscure that fact. If you have bottlenecks, a tool may not help you see that.
I like tools. But sometimes the best tools are the simplest tools. I stopped using Gantt charts when I realized they perpetrated lies on the organization. Do I still use them? Sure, at the high level only, not at the detail level. And not for agile projects. On non-agile projects, I start project scheduling with stickies, never with a scheduling tool. There is tremendous power in being able to move a sticky around.
If your team doesn’t know how to track an agile project without a tool, you need to learn how first, distributed/dispersed team or not. That’s what cards and stickies buy you, the ability to move them around. Do not underestimate the power in a card or sticky, and especially the ability to move it to “in progress” or “Done.”
With manual tracking, you will learn about the impediments and bottlenecks in your organization. Once you know about them, you can decide what to do. Can you use a tool to learn about the impediments and bottlenecks? Sure, if you look at it. But that’s the problem. You have to go look at it, by yourself. The team is not looking at it together.
Once you’ve learned from your manual tracking, you will see what kind of a tool to use, not just one that’s free, because that’s what the organization is willing to spend. Maybe the free tool is the right one for your situation. Maybe it’s not. A whiteboard that meets your needs and a camera that takes less time to futz with is even “free-er” than a free tool that does not meet your needs.Tags: tool, transition to agile