At this point, most people in software dev have had some experience in dealing with Jira or similar tools.

These tools get a lot of hate for being clunky, annoying, and insert-other-often-valid-issues-here. Jira specifically gets a lot of hate for how it forces a lot of bad behaviors. This sort of makes sense when you take into consideration that Jira apparently started its life as a bug tracking tool.

But that’s not what I want to talk about. I want to talk about a way in which Jira, and Jira-like tools, should emphatically not be used – but that seems to be one of the main ways that they are used.

Don’t use Jira as a management tool.

You can use it to get a view of the work that is currently in progress, but far too many places obsess over the content of “In Progress” tasks and the metrics that go with them. This is an unhealthy practice and it needs to stop.

That’s not to say that Jira is useless. It isn’t. If you use it as a tool to help a team coordinate with itself, it’s actually not half bad as long as you realize that it does have limitations.

It’s a pretty decent tool to use in a geographically distributed team in order to have a view on the work that we think needs to be done in the next week or two. It also helps you track blocking issues if you do it right. It even helps teams not get off into the weeds if you use it to break up cards into thin vertical slices.

Yes, you can do all of this with a set of index cards, but that really only works for teams that are co-located in the same physical space. Digital Kanban boards open up a lot of opportunities for remote collaboration if you treat them as collaboration tools and not management tools.

Instead of using it as a collaboration too, a lot of businesses try to use it as a management and reporting tool.

They inspect the board to “make sure everyone is working” – which is a problem for a lot of reasons. Putting aside the fact that this is a terrible Taylorism-style management practice, the tools just plain aren’t made for it. Jira, for example, only lets you assign one person to a card, so using it this way discourages pair and ensemble programming.

They will insist that every thing you work on be added to the board. This is a bad approach. The board is for the team to self-organize and should only contain work that helps move the project forward. Ancillary work doesn’t belong there. If you want to know what people are doing outside of directly project-related work, ask.

Insisting that “all work should be tracked” is just a symptom of the Taylorism obsession that everyone be “utilized” at 100%. This is unhealthy for the people who work for you and will lead to burnout and high rates of attrition (which, among other things, will lead to a loss of institutional knowledge).

This leads to one of the other major problems with using Jira as a management tool (coupled with Taylorism management approaches) – an obsession over velocity.

Just because you’re moving a lot of cards doesn’t mean that you’re doing meaningful or impactful work. Focusing on throughput as a metric for productivity is a bad idea for reasons that I’ve written about before.

The list of reasons that Jira (and its competitors) are horrible management tools could go on for several pages, but I can’t blame the tool. What I do blame is the misuse of the tool to satisfy management ego and the desire for simple (but wrong and destructive) metrics to “manage” people as though they were cogs in a machine.

Jira is a useful tool. Just not for the way that a lot of places use it.

Writing software is a creative endeavor. You’re solving problems that nobody has solved before. If you aren’t, you should strongly consider buying the product that already exists to solve those problems so you can focus your time, money, and effort on solving problems that are core/differentiating to your business.

If you think that you can’t trust the people you hired to get work done, that means either that you hired the wrong people or that you have trust issues that you need to work on – both of those are failings on your part as a manager, not the part of the people doing the work, and those won’t be solved by obsessing over metrics.