Most teams who use Agile or Scrum today use some type of online agile tool or Agile Lifecycle Management Tool (ALM Tool). While I do believe there are some benefits of using agile tools, I think the use of tools is problematic for a number of reasons. Please see below for my opinion on why I don’t like tools. And please follow the link below to take a short survey about the use of tools in your organization.
Why I don’t Like Agile Tools
1. Less Transparency
For product backlogs, using a tool so that everyone can see and edit it in one place is convenient and improves transparency. For sprint backlogs, using an agile tool actually reduces transparency. The sprint backlog is where the team lists all the backlog items and creates the tasks needed to complete them. You would think that a tool might improve transparency but it doesn’t.
Oh, the tasks are all in there, but it is difficult to see all the tasks for the sprint in one place. To actually see the whole plan, you have to scroll and scroll and scroll. You cannot see it all on one page.
As a workaround, teams frequently filter the sprint backlog so that they show tasks by person. Now we can see what each person is working in. But we lose sight of what the team is trying to accomplish. The focus is on “my tasks” but not on “our tasks”.
2. Less Talking
When used to contain the sprint backlog, Agile tools can lead to less team members talking and collaborating. People simply enter and maintain their own tasks. The tasks are pre-assigned to individuals, there is no collective ownership, and teams do no swarming to complete all the work.
I once observed an agile team completing their sprint planning using an Agile tool. Even though they were all in the same room, there was no discussion, only individuals entering their tasks into the tool. The Scrum Master monitored their individual task assignments to track how much of their individual capacity was planned. Once everyone had filled up their 40 hours per week with tasks, the planning was done. Weirdest thing I ever saw!
3. An Agile Tool Can Cause Focus on the Wrong Things
Entering all the details on tasks and hours into an agile tool will generally result in misuse of this information. At the team level, it often results in a focus on hours or activities rather than outputs or outcomes. (See my related post about measuring the wrong things here.)
I witnessed an organization that each morning sent out emails with personal burndown charts that went to the managers of all team members. The reports highlighted any variance between planned work hours and actual work, by person, for the previous day. As with all metrics, the focus on personal burndown charts led to significant gaming and behaviors which reduced or eliminated the variance.
As expected, team members burned through the hours, without regard for the desired outputs, or more significantly, the outcomes! Unfortunately, I see this type of behavior all the time in organizations. The hours are spent, but the outcomes are not achieved.
Another common organizational dysfunction is that people outside the team begin to analyze the data from the tool. They want to see the accuracy of the team’s task estimates which they believe they can do by comparing actual time spent on tasks to the planned time. Or they want to see who on the team is working the most hours or the least hours. They run reports showing who completed the most story points. We have all seen this movie before and knows how it ends – with team members gaming the tool to say what it needs to say, and ignoring opportunities to perform well as a team.
4. Wasted time
When using an Agile tool, someone needs to keep the data in the tool up to date. Sometimes this falls on a Scrum Master, an approach I really don’t like. An equally bad alternative is for the Scrum Master to become the tool nanny and the person who is always reminding the team to update your tasks and stories.
So take your pick – the Scrum Master either becomes the Jira Lackey or the Tool Nag. Either way, they shoulder the burden of keeping the tool up to date, which means the team isn’t really responsible for their own plans.
And there is a cost. Scrum Masters often send reminders, sometimes multiple times daily, that team members need to update their tasks in TFS or RTC. Tasks need to be moved, and the actual and remaining hours need to be updated. All of this, whoever does it, is pure waste. To compound this, on teams where someone is watching the reports, the waste is increased by team members massaging the data for optics.
5. Standup failure
Teams that use Agile tools for their sprint backlog, inevitably take much longer to conduct their standups. And, some team members will never talk in the standup because they don’t have any tasks and it isn’t obvious.
Because team members only have to worry about their personal tasks, and not the team tasks or goals, the standup becomes a dull recital with everyone tuning out until it is their turn to speak. Typically the scrum master will filter the tasks for one person, prompt that person to pay attention, and then the team member checks in. Inevitably the individual is doing something else like playing candy crush and so everyone waits for them to shift their focus to the tool. Again, this doesn’t lead to a focus on accomplishing the sprint goals.
Alternatively, teams go story by story, rather than person by person. They drill in. Ironically, some team members don’t even speak when going story by story because they didn’t have any tasks.
6. People stop Thinking
Another common thing for teams using an agile tool is to begin templating tasks. They know that every story is going to get an 8-hour development task, a 4-hour test task, and a 1-hour UAT task. In sprint planning, the team simply uses a template for the tasks and the number of hours and they copy the tasks from the template.
The benefit? Speed! We can quickly copy all these tasks in and sprint planning will be done. Team members no longer think about the specific tasks. Is sprint planning effective if people aren’t thinking?
7. Overcomplicated Agile Tool Workflows
In many organizations, well-intentioned planners set up intricate workflows for user stories and tasks. They mimic their Waterfall phases and create states for each backlog item to go through with clear handoffs. And they have different workflows for backlog items, defects, new requests, changes, and spikes. Oh, and they have notifications so that each team member knows when things have been added to their queues. No no no!
Though it looks like automation, these approaches tend to create queues and handoffs, reinforce silos, and overcomplicate the completion of work. Items can get bounced around from person to person without actually getting completed. Or they are forced to go through unnecessary steps in the workflow just to get to closed. People may be doing a lot of clicking or moving things, but is that progress? Are the actual backlog items being completed?
Just for kicks, go into your tool and check out the history of any random item and see where it has been and who has touched it. Or try creating a new item and then moving it through the steps to done and count how many clicks you need to do just to close it out. The tools seem to be optimized to confuse and complicate, rather than to support the smooth completion of work.
8. Unnecessary Documentation
Most people use the user story format for their backlog items. Stories originated in the 1990’s in extreme programming (XP). The idea was to write a short note on a 3 x 5 physical note card as a reminder to have a conversation about a particular business need.
This great idea has been corrupted by the use of tools. Rather than a short note on a 3 x 5 card, modern Agile tools provide us with literally hundreds of columns of information so that we can capture every detail of the user story. Plus, we can attach documents! Oh goody! Now we can create an extensive database on each and every business need.
This is simply too seductive to those who miss their analysis phase and their “business requirements document”. They have been pining away for the waterfall days of old and are thrilled to find that despite the opposite statement in the Agile Values, there really can be quite a bit of documentation in Agile.
9. The Belief that Tools are Magical
Maybe I should say that Tools have the perception of being magical. Some people believe that having all the details in a tool allows for some sort of magic. They love the workflow routing and the automated creation of burndown and velocity charts. If it’s in the tool, it must be correct, right?
Sorry folks but tools don’t add any type of magic. A tool will create a burndown chart faster than you can draw one by hand but that is only seconds, and sometimes there is value in drawing it by hand so that you understand what numbers are behind it. Let me reiterate, “there is no magic added by any tool”.
Is there a Place for Agile Tools?
As mentioned above, I do see the value in using Agile tools. The best use of the tool is for the product backlog. A tool to keep the product backlog online provides transparency and a single source of reference for the team and product owner. This is particularly critical when the team and Product Owner are not co-located in the same place.
Tools that are integrated with version control also provide some automation in terms of tracking and tracing code.
Finally, when teams are distributed, the tool can help to provide a common view of the work. But rather than give distributed teams a tool, my first approach would be to find a way for them to work on a team that can be co-located. See my article about co-location here.
Agile Tool Feedback and Survey
I would really like to get a sense of the tools people use and their levels of satisfaction they have with them. Will you please take a moment to complete a short tools survey. You can jump here to take the survey directly. Or see the results of the survey in my related post on Agile Tool Survey.
I would love to hear your comments about the value or cost of agile tools.