The Trouble with Tools
Photo by Anthony Beal
Inspired by Ty's "My Fear of Robots, er... Tools" posts (parts 1, 2, and 3):
The Agile Manifesto tells us that we value individuals and interactions over process and tools, but it is quite common for organizations to adopt an agile tool that all of their teams must use. These tools are intended to enable managers to see at a glance what work is in progress and what work is coming. To show how productive teams are and where they are blocked. To roll up reports across multiple teams to show project/program progress. But I've observed that the realities of using a tool are quite different.
1. Teams don't understand how to use the tool effectively. Regardless of the tool, odds are it is more complicated than using index cards on a wall. Teams that do not understand scrum thoroughly and have not used index cards in the past struggle the most--which features in the tool need to be used? Which can be ignored? What should team members be looking at and when? Teams are less likely to be looking at a task board during their daily scrum, so the feeling of committing in front of your peers is lessened. It is harder to see the big picture view of the sprint, so the team might not recognize when it needs to swarm.
2. Managers don't understand how to use the tool effectively. They look at reports from their offices and don't discuss them with teams. Teams and projects are not setup properly for roll-up reporting to be useful. Reports are looked at more often than backlogs, so the focus is on where the team is and where it has been rather than where it is headed. They aren't having meaningful conversations or making decisions based on the information available.
3. It's an information refridgerator rather than information radiator. Burndown charts are not reviewed as a team, and conversations about whether or not the sprint will be completed successfully are not occurring as often. The data in the tool might not be updated as often as it should--backlogs are stale and tasks are outdated. There's no way of knowing who is looking at the tool, when they're looking at it, and what they're thinking based on it. Tools also allow users to add more information to backlog items, so historical notes and attachments are added that also get outdated.
I wish more teams and organizations knew their processes before moving to tools. Focus on behaviors that are effective and translate them to a tool instead of picking a tool that seems like the right thing to use because it's popular. Stay low-fidelity for as long as possible and consider alternative ways of sharing information before moving to a tool; if working within a distributed team, it's acceptable--perhaps even preferable--for each location to have physical scrum boards setup.
