The JIRA anti-pattern
JIRA is one of the most used "tasks management" applications in software development projects today. So JIRA can be used as an example to see how these applications used. Unfortunately, many projects are not using JIRA correctly and hence don't get the expected benefits. Let's see why.
In the year 2001, the Agile manifesto introduced a new way of thinking about how to develop software applications. That was a significant change in the mindset of the software industry. This industry used to work with the waterfall mindset for decades. With this change, a new set of task management applications appeared to support this new way of thinking. These applications provide a simple and iterative way of managing tasks. These applications came as a direct replacement to the traditional old project management tools of the waterfall development model. These project management applications were part of the problem that the Agile methodology came to fix.
After almost 20 years, task management applications are almost used in all software development projects. What we have seen in many projects is an anti-pattern which I call the JIRA anti-pattern.
Let's remember what were the main principles that came with the Agile manifesto in 2001 (https://agilemanifesto.org/). I will pick two of these principles as an example:
- "Individuals and interactions over processes and tools"
- "Working software over comprehensive documentation"
let's jump to 2020 and see how things turned dramatically in many projects and how the wrong use of JIRA introduces the Anti-pattern.
- The process became more important than the individual and the interactions. The project management is using JIRA to standardize and streamline how the developers should work. This type of control kills personal preferences and innovation.
- The focus has been shifted from the value produced (Working software) to the documentation. The documentation is represented in JIRA tasks, sprints, estimates, time spent, story points, burn-down charts... None of these tells anything about the value produced or ensures that the team is producing working software.
JIRA supposed to enable the development team to practice Agile development methods. In reality, JIRA has been misused by many project managers to control the development team. JIRA is supposed to be used as a communication tool between team members in the project. But it is now used mainly as a tool to micro-manage the project.
In my opinion, the problem mainly is the lack of trust between the project management and the development team. Some of the management still does not fully trust the development team and their ability to develop the application. With the lack of trust always comes the micro-management. JIRA provides the perfect tool to micro-manage any project. That is why the focus has been shifted from the value produced to the process used. JIRA is even a more dangerous tool in micro-management compared to the old project management tools.
Let's go back to the original principles of Agile. Applying Agile has nothing to do with the tools in the project. Applying Agile is about the mindset of the whole project members. JIRA or similar tools will not turn the project to Agile. If you want to apply Agile:
- Use whatever tool that enables the team to produce value. Use sticky notes if it works for the team. The team should decide for themselves.
- Trust is key to Agile. As a project manager, you have to trust your team. If you don't trust the team, replace them with a team that you trust.
- Control is bad. Agile teams do not need control. Agile teams do not need the management to tell them how to develop software. They already know that better than anyone in the project. They need facilitators that fix any problems the team may face.
If you are using or planning to use JIRA, it is a very powerful tool with a huge set of features. Just make sure to avoid the JIRA anti-pattern.
Principal Software Engineer at Milestone Systems
4 年Really good points. Specially if/when it starts to be micro management between PM and engineering it can kill the whole idea of agility :)