The evil of tracking tools in the sprint

After 8 years of training and coaching teams I've noticed some very obvious patterns and anti-paterns.  One of them is the impact of bringing tracking tools into the sprint.

These tools are primarily used to:

• Build the sprint backlog
• Update the estimates during the sprint
• Display sprint backlog details during the daily scrum
• Spit out the sprint burn down

I understand that some teams, that cannot avoid being distributed, want to use such tools, but I rarely see them as positive for collocated teams.  It's not the fault of the tools, but how they are used.

One of the primary aims of Scrum is the boost in productivity seen with teams that have a sense of ownership in how they run their sprints.  Teams with ownership are accountable for their commitment.  They enjoy their work more and they explore ways to improve.

Sprint tracking tools can get in the way of that by:

• Not allowing an "all hands" approach to managing the sprint backlog: one mouse, one keyboard, one operator.
• The data in the tool is only brought out once a day because there are not enough licenses, developers don't want to learn the tool, or the extra effort isn't worth it.
• The team's ability to customize the artifacts (task board, burn down, etc) are limited by what the tool can do.
• The metrics of the sprint (sprint velocity, burn down), and even individual developer progress can be monitored by management.   Guess what happens when a developer or team is asked why their burn down is not diagonal enough?
• Making the daily standup a status reporting meeting by focusing on individuals.

Even if the tool is being used in benevolent ways, the team can suspect otherwise.  In organizations that are trying to grow trust, this can be a killer.

Also, teams need their sprint backlog to be radiated at them.  Tools refrigerate the backlog by storing it in some cloud.

When I bring this up, I often hear from the Scrum Master that the tool makes it easier to do their job; tracking the sprint and producing the burn down or that there is no wall space.  It's often news to such Scrum Masters that their role is not to be efficient creating the artifacts, but helping the team build ownership and trust...or just tracking down solutions, like a portable task board.  I don't blame them necessarily.  Adopting a tracking tool for sprints are often an interpretation of how Scrum should work in an amber or orange organization.  Teams in these orgs who are new to Scrum might even want tools in the sprint so that the "Scrum fad" has minimal impact on them.

The sprint backlog is owned by the developers on a team to help them organize and manage their shared commitment and forecast for achieving the sprint goal.  It serves no purpose external to the team.  

Courage, commitment, focus, openness and respect aren't always easy to instill, but it can start with a bit of tape and some index cards.