My teams have been practicing Scrum for nearly a year, and it has been an eye opening experience. I have learned a lot, as has everyone at Mailtrust. I hope to post a few Scrum tips every now and again to help others learn from our mistakes and experiences.
The first tip is don’t pick one tool for all your teams. Picking one shiny tool seems like the route to go when you first start Scrumming (that feels like a dirty word), but it isn’t. The Agile manifesto states something very important about how teams should be managed, and it says it for a reason.
Individuals and interactions over processes and tools
Team dynamics should influence the tools used during the Scrum process, not management or the company or anything else.
We have been through a few major iterations of tools, and here is what we have seen.
First Attempt - Excel
Excel was the obvious first choice we made for managing Scrum projects. The problem is, it is very hard to collaborate. This was a huge draw back that everyone hated. We quickly looked for other options.
Second Attempt - Google Docs
Google Docs took the power of Excel and made it collaborative. Pretty awesome. Many teams loved this approach. It was easy to have burndown charts, calculate availablility, etc.
The teams it didn’t work for were the larger teams. These larger teams needed much more flexibility than Google Docs had to offer. The fact is, Google Docs is pretty cumbersome when you have to make a lot of changes. Large teams are large for a reason. They have a lot going on. Lots of bugs come in. Lots of tasks are getting worked on. Lots of impediments occur. Lots of notes need to be taken on tasks. Lots of tweaks to the process need to happen each sprint. These teams needed something better.
My smaller teams took the exit ramp at Google Docs. They are still using it and it is working great. They don’t have as many changes or bugs coming in, so Google Docs isn’t as cumbersome. These teams are usually backend teams where priorities are much less volatile.
Third Attempt - The Board
The larger teams needed ultimate flexibility. Managing dependencies, priorities, and status of tasks and stories needed to be easier. So we went backwards in time, to the days before computers. To pencil and paper.
It has worked great for larger teams. At first, I didn’t think it would but pencil, paper, and a wall are so free-form, the team can develop the process that works best for them. That’s exactly why the larger teams are loving the wall. Here are some different things teams are doing with the board.
Different color post it to signify things like dependencies and test failures
Organize bugs at the top of the board. This is great for managers like me to see whether a team is getting killed with bug reports.
Limit the number of stories available to be worked on. This helps prevent teams from getting 90% of each story done instead of 90% of the total stories.
Limit the number of tasks in each status, like working, review, and testing. This forces team members to move tasks through the process and not leave them hanging around
Next Attempt - ?
If you haven’t noticed, the teams have been iterating, not just on the product, but on the process over the past year. This is at the heart of making Scrum successful for you teams. Each team will adapt and change the process to their needs, which is fine with me. As long as they continue to operate effectively, they are free to use whatever tool they need.