Skip to main content

3 min read

Is Jira an "antipattern"? We bust the myths

Matt Saunders
12 December 18 Jira
Is Jira an "antipattern"? We bust the myths
alert2 Icon
The content of this blog is no longer updated

Is Jira an "antipattern"? We bust the myths

While installing and adopting software can bring huge benefits to both technology teams and to the wider business, doing so without ensuring that the tools are used in the right way — and in the right context  can cause problems.

Most organisations we see end up with very successful Jira implementations. Yet from talking with our customers, we also know that some teams adopt Jira only to find that it fails to produce a dramatic transformation on its own. And that's really no surprise. 

The expectation that out-of-the-box Jira is a solution that improves the work of all development teams is plain wrong. Yet that idea is surprisingly common: a case in point is a recent TechCrunch article denouncing Jira as a counterproductive 'antipattern' that encourages teams to get bogged down in microdetails and lose sight of the bigger picture. In addition to the false assumption that out-of-the-box Jira is intended to be a cure-all solution, the article relies on a number of Jira myths. Let's bust them.

poor comms

Myth one: Jira restricts communication 

Jira does not function in isolation  and nor was it designed to. Expecting teams to move forward coherently just by using the native structure of Jira is unrealistic, as it's intended to work best when complemented by an environment of other tools and communication methods. Ensuring that teams have the means to communicate regularly with each other  through stand-ups and regular progress meetings either face-to-face or via collaboration tools  is a fundamental step to ensuring that projects are kept on track.

What's more, restricting communication to the limited options within ticketing systems only leads to organisational dissonance. This is where adding appropriate documentation outside the ticketing system comes into play using a wiki platform such as Confluence is a prime example. But restricting collaboration to a wiki is a mistake as well, as this in turn should be supported by friction-free communication tools such as Zoom and Slack. Jira is not built to be a substitute for ongoing team communication, and it should not be employed as one.

Hinders Agile

Myth two: Jira hinders agile approaches 

For any development team, splitting work into manageable chunks is the only sensible way to break down large programmes and projects into actionable pieces of work. So it's understandable that teams put individual pieces of work into Jira — it's indeed the right place to track them.

In theory, what happens next is that the work gets completed, signed off and released, before the team moves on to the next piece of work. But the reality is that work cannot take place in isolation, no matter how well-defined it is. The output of any piece of work often affects the input of another, and the agile manifesto accounts for this. Regular reviews of progress and frequent course-correction is the only way to achieve a desirable outcome  Jira is just one piece of this puzzle. 


Myth three: Jira is restrictive

DevOps 101 suggests that in order for organisations to achieve their best work, they must allow room for innovation. Indeed, instilling a culture of experimentation within a team produces the least waste and creates an environment of delivering value rapidly to customers.

A key finding of the State of DevOps Report is that high-performing organisations release working software thousands of times faster than those that aren't. One of Jira's greatest strengths is that it's a very configurable product, but this can be a double-edged sword in that it can lead to restrictive practices being implemented. However, carefully designing workflows that collect the information you need, and enable effective communication without restricting the team, will help avoid this problem. 

Other techniques such as keeping the high-level programme and project objectives in Confluence, and making sensible use of macros to include data from Jira, can help substantially. Further, using tools such as Jira Portfolio can give an automatic view of the raw data in the tickets. The caveat always is that relying on tickets as a single source of truth, in any project management tool, can be misleading. Regular high-level reviews of this output are an essential best practice.

The verdict

In short, Jira is neither a pattern nor an antipattern. It's a toolset designed for organisations to shape around their specific people and process needs. Relying on Jira's configuration as deployed out-of-the-box is the antipattern. Atlassian 's tools comprise a powerful platform, and configuring them to deliver your business processes is crucial to unlocking the productivity of your organisation.

And that's where Adaptavist comes into the picture. We help organisations design and implement their software so they can truly make the most of it to create flow and drive productivity across their teams. While Jira isn't a silver bullet, when it's configured and utilised correctly, and employed within an agile culture of ongoing communication, it is a key building block in delivering real transformation.

Keep up with all our updates by following us on Linkedin

Follow us on Linkedin

copy_text Icon

About the authors

Matt Saunders

DevOps Lead in the Office of the CTO at The Adaptavist Group

Matt Saunders is the DevOps Lead in the Office of the CTO at The Adaptavist Group. After being trusted with a root password as a Sysadmin long ago, he now helps teams make the best use of people, processes, and technology to deliver software efficiently and safely.