The Trouble with Tools

Photo by Anthony Beal

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.

Allison Pollard

I help people discover their agile instincts and develop their coaching abilities. As an agile coach with Improving in Dallas, I enjoy mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. In my experience, applying agile methods improves delivery, strengthens relationships, and builds trust between business and IT. A big believer in the power of community-based learning, I grew the DFW Scrum user group significantly over the five years I served as an organizer. I am also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.