Jira as a Cultural Barometer - Cogent

Jira as a Cultural Barometer

Duncan Bayne

Duncan Bayne

May solder together his own computer if the ones in the office stop working.

Jira is a common project management tool for software projects. Having seen it used across a range of projects, Duncan explores the common misuses of the tool and discovers that sometimes, issues with Jira can point to the very real human challenges that maybe driving the project’s problems.


Jira has a poor reputation among Agile practitioners, for good reason.  Many of the large organisations I’ve worked with have used Jira, and most of the time it’s been a mess.  

Common problems I’ve seen in the wild include:

  • Restrictive permissions:  Jira will be configured so that only certain people have the ability to create, delete, and re-organise projects.  Workflows will exist that prevent tickets from being moved between states arbitrarily, in an effort to prevent people from working in the ‘wrong’ way.

     

  • Misuse:  Jira artefacts will be used for purposes for which they’re not intended, which in turn messes with statistics.  For example, neverending Epics that actually exist mostly to allow swimlanes on Kanban boards.

     

  • Underutilisation:  Jira offers several powerful reports and analysis tools, but I’ve seen many teams running manual analyses, even exporting raw data from Jira into Excel for that purpose.

     

  • Overcomplication:  Every organisation I’ve worked with that uses Jira has modified the default configuration, usually a lot.  It’s not uncommon to see literally hundreds of possible ticket statuses, half a dozen plugins, and the aforementioned complicated workflow rules.

A natural reaction, common to most of the developers I’ve worked with, is to rip out Jira and replace it with another tool [1].  It’s more profitable to look into why your team or organisation has chosen to use Jira in such a counter-productive way.  Dig under the surface of the problem, and you’ll likely find strong cultural issues of which Jira problems are just a symptom.

Restrictive permissions are often a symptom of lack of trust [2].  If your organisation doesn’t feel comfortable giving everyone the ability to use the full power of Jira, ask why.  The answers will often be enlightening.

Misuse is usually taken at face value: as evidence of a lack of familiarity with Jira.  But in my experience it’s usually driven by a lack of deep understanding of Agile principles, or the Agile methodology in use by the team.  For instance, if your Epics are never-ending – without a clear definition of done, evolving forecasts of completion date [3], etc. – then you should dig into that, not Jira training.

Underutilization might point to one of a few distinct underlying problems.  One is genuine unfamiliarity with Jira; not knowing what it can provide out of the box.  Another is that the built-in reporting and forecasting tools only work well if your process is sound, with small consistently-sized stories that aren’t often blocked.  Yet another is fear: used properly, Jira forecasts will give you a good understanding of your progress and likely completion date. If your organisation doesn’t reward transparency, this will be seen as a bug rather than a feature.

Overcomplication can sometimes be benign: the consequence of a sprawling Jira configuration that’s been around for years accumulating cruft.  Other less positive reasons can include fear of errors, and lack of trust. Fear, because micromanagement of Jira configuration is seen as a way of preventing errors, or worse, ensuring that the ‘right’ people get the ‘blame’.  Lack of trust, because in many cases developers or others aren’t trusted to be able to operate a Jira workflow without making errors.

At a surface level, my preferred response to all of the problems above is to create a new Jira project, and recreate any relevant artefacts in there.  Almost always, I use a simple kanban project with the default workflow. In addition to demonstrating trust and at least in principle unlocking the ability to generate useful projections, such a step also provokes some great conversations. For example, a common characteristic of bad Jira projects are massive, thousand-ticket backlogs.  Creating a new project also creates the opportunity to explain why such backlogs almost always represent a huge waste of human productivity [4].

Just remember that any or all of the above Jira smells can be great pointers to the very real human challenges that may be driving some of the project’s problems.  Once you’re done addressing the surface issues, dig into the underlying reasons, because that’s where the real opportunities for improvement are.

[1] A common tool to reach for is Trello. My personal opinion is that, out of the box, Trello offers insufficient analysis tools to manage a non-trivial software project; I’d much rather use Notion.  But opinions vary, and I’ve seen teams achieve success with pretty much every project management tool out there, including plain text files.

[2] Or a symptom of a regulated environment like finance or medicine.

[3] Out of the box, a Jira kanban project will give you everything you need to project completion dates for Epics: cycle time tracking, cycle time metrics (courtesy the Control Chart report), and Epic progress (courtesy the Cumulative Flow report).  Outside of regulated environments, I’ve never found the need for any customization, or any additional reporting.

[4] For much the same reason that inventory is a liability in manufacturing.  Only the finished product counts; partially-complete product sitting around is no asset.  A lot of surprising conclusions flow from this observation when applied to software.

Related posts