I really like JIRA Agile. In fact I like all the Atlassian stuff, the ease of functionality and how it all integrates so well. I use JIRA (with the JIRA Agile Plugin) to manage my company’s backlog as well as with the client teams I work with, and it is always the first tool I’d recommend to folks who ask. The tool provides the ability to create a Product/Sprint Backlog that is easily accessible without having to leave your seat, which can be a good thing. However, I observe that it can also have a very negative impact on agile teams.
One of the things that the tool does make easy is the ability to self-task, i.e. any team member can assign a task form the Sprint Backlog to themselves to work on via the interface. This is a useful mechanism for providing the kind of empowered, “pull” tasking that we want in agile teams, rather than have some manager assign work out to the workers (as in a more command and control environment).
The same capability can also discourage team self-organisation and self-management, which are also essential for effective delivery. The individual team members do not necessarily need to talk to each other to allocate tasks amongst themselves, as each one can interact directly with the Backlog via their own JIRA dashboard. The tool doesn’t actually prevent people from collaborating, they can still talk to each other, but it does make it much easier to avoid collaboration if they want to.
Similarly, the ability for each team member to raise an issue, assign it to themselves and carry out work on it, interacting only with the tool, can be divisive. The fact that the issue details are recorded in the tool give the false confidence that their work is being shared with the rest of the team, but in reality, a great deal of understanding about what is behind the issue could be lost to others. Again, the tool doesn’t prevent collaboration, but it does make it much easier for individuals to go off in their own directions.
The biggest issue though is the ability to record individual work estimates against tasks. This encourages a number of bad practices. It encourages allocating tasks to individuals at Sprint planning (to work out team capacity for the Sprint). This reduces the agility of the team, i.e. team members can’t easily switch to other tasks during the Sprint if problems/opportunities arise.
It also moves the focus away from the team’s shared commitment to deliver and on to the individual team member, to deliver their own “backlog”. This could only mean that the team’s overall objectives are not met, i.e. as a team they fail to meet their Sprint goal, because not all individuals meet their separate goals, but also potentially create dysfunction within the team, i.e. team members are reluctant to help each other because they want to complete their own work list.
A more manual approach to managing agile delivery, such as using a whiteboard and post-it notes, generally doesn’t suffer from these kinds of problems. One of the benefits of using a more manual tool is that the static location of the board forces teams to come together to view it and discuss its contents, creating opportunity for collaboration.
Of course, a more manual tool has limitations (post-it notes fall off, burn-down charts take more effort to create, information needs to be copied elsewhere to persist, etc), which is undoubtedly why software versions are useful (and popular) and, particularly if teams are not co-located. It’s difficult to imagine an agile team not using one.
The Agile Manifesto statement reads that “we value individuals and interactions over processes and tools..”. The danger of using a tool like JIRA Agile, is that it is easy to forget that the tool doesn’t make you “Agile”, and, used without thought, the tool could create a non-collaborative environment that is decidedly anti-agile and ineffective. The trick, I suggest, is to use the tool, with such agile principles in mind, to get the most out of the convenience it provides to the individual, while keeping the focus on team working and collaboration.