There are tons of agile tools out there. Just have a look at this looooooong list on Mike Cohn’s site. But what is the best way to introduce such a tool in your team or company? I collected the following steps for you.
1. Start with no tool at all
A fool with a tool is still a fool. Before you introduce a highly sophisticated agile tool, you need to know how Scrum, XP, Kanban or any other method are working in your own context. If you use a tool right from the start, you won’t follow the process that best fits your situation, but the process the tool dictates. Every agile tool has it’s own understanding, how to implement Scrum or Kanban.
2. Use pen and paper
You don’t need a full blown agile collaboration tool to start your agile journey. All you need is a white- or cardboard, some super stickies and pens. That’s it. If you’re working in a collocated team, this is all you need. No distracting electronic tools and no fiddling around how to get this thing working. This is the best way to find out, how to implement your agile frameworks. When you understand, what agile is all about and how to adapt to implement it, that it fits in your context, it is time for step 3.
3. Start with the simplest possible
If you still think you need an agile tool, start with the simplest possible. You can set up a Kanban board in 15 minutes with Google Docs. Or use another simple card based tool like Digaboard, Flow or Linoit. Most of them are free, at least for small teams. The main advantage of those tools is that they don’t follow a certain process, and you can easily adapt them to yours.
4. Choose wisely
You’re still here? So I guess that you still think you need a „real“ agile collaboration tool? Than choose wisely! As already mentioned, there are a lot of tools out there. If you followed step 1, you know what your agile process looks like. You need a tool that is easily adaptable to your process. Don’t become a slave of the tools process! If you can’t adapt the tool, skip it. Don’t hurry, when selecting the tool. You’ll probably have to work the next decade with it. That’t why it has to be the right one.
5. Get a training
After you chose a tool, it is important that everybody in your team gets trained. It is important that everybody knows how to use the tool. Nothing is more drowsy than a ScrumMaster fighting with the tool during a Sprint Planning. The tool has to serve you, not the other way around.
IMHO a full blown agile tool only makes sense, if you work with a distributed team. In all other cases, it decreases the productivity instead of increasing it. At least that’s my experience. I’m looking forward to yours, so please leave a comment.
Short, but to the point 😉
Couldn’t agree more. Try simple things first, experiment and calculate time invested. Weird ideas like having two physical boards and keeping them in sync manually might in the end be more feasible than an electronic solution. Do not underestimate the advantages of a board you happen to pass by, you can’t avoid to see, over one you have to think of opening.
Thanks for your comment Olaf.
Good article. I can fully agree with it. We used to run pivotal tracker, which is great, but unfortunately not free anymore. So we’ve made our own.
We would be happy if you could check our brand new tool Planthat. http://www.planthatapp.com
Nice post. I guess point 1 is of great importance for anyone who is about to start agile journey without a doubt. Product owners of tools itself suggest this.
+1 me too.
Yes, good article. But in contrast to paragraph 3, we immediately had chosen not simple, but complex Tool. This will allow us not to worry about what this software will limit our ability to project management in the future.
You can estimate we were right or not by yourself:
You made some good points, but finding the right solution for the right team can often be big problem. We’ve tried TFS, JIRA, SmartBear and are currently running Countersoft Gemini with which we have seen some good results in going all-in with Agile development. It’s really tough finding a good fit!