Yesterday I hinted that I’m not a big fan of Jira. In the interest of keeping this short, I won’t go into a long list of Jira failings. Instead I’ll just address the two prongs of the framework I established yesterday:
Does the tool make useful things easier, and unuseful things harder?
Jira is an incredibly “powerful” tool. It can be configured six ways from Sunday. This makes it a popular choice for teams that have complex project management needs.
But agile teams, by definition, should favor “individuals and interactions over processes and tools”, and strive for simplicity, or “the art of maximizing the amount of work not done.”
Work about work (i.e. issue management) is part of the work that we ought to maximize not doing.
So based on the premise that agile teams need lightweight processes, and want to maximize the amount of work not done, is Jira a good tool for this purpose? Let’s look.
Does Jira make it easy to do useful things?
Not really.
Jira definitely makes it possible to do these things. Jira can do almost anything, if properly configured. But it’s not easy to configure Jira to be lightweight. It probably requires several weeks (or longer) of trial and error, or a highly experienced expert to configure things to be “lightweight”.
But on to the second of my criteria:
Does Jira make it difficult to do unuseful things?
Again, not really.
The fact that Jira is so configurable means that it really doesn’t offer any enabling constraints by default.
In fact, Jira often encourages a lot of anti-patterns. I recently saw a post boasting that Jira now supports “larger backlogs”! 🤦
Large backlogs are not lightweight, but I’ll save that rant for another day.
In my honest opinion, Jira is responsible for more lost human productivity than any other software ever created. And yes, that’s even when considering Windows Me!
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)