JIRA and The Deckard Defense

Rachael: It seems you feel our work is not a benefit to the public?

Deckard: Replicants are just like any other machine. They are either a benefit or a hazard.

Here’s a familiar pattern: An experienced observer notes that a certain tool, mental model, or practice should be avoided because it is causing more harm than good in the industry. Then someone reflexively responds with The Deckard Defense: “Thing X can be used for good or bad.” (Deckard is a character in Blade Runner.)

The Deckard Defense is logically valid, but misses the point that Thing X usually has a harmful effect, and removing it usually has a beneficial effect.

While I’ve heard this argument used to defend velocity, burndown charts, and Scrum of Scrums, it most frequenly comes up around tools like JIRA.

JIRA is particularly harmful to collaboration when used for the Sprint Backlog, the work a team has chosen to do during one Sprint. Even if there’s a shared Product Backlog in some electronic tool (ideally something much simpler than JIRA), the Sprint Backlog is meant to belong to the team that’s working on it. Unfortunately you can’t spend much time in a JIRA-based shop without hearing people talk about “my ticket” and “your ticket.”

Jacek Bochenek writes:

I think a lot of people who dislike Jira (myself included) go off previous personal experiences on how the tool was used and what problems it coincided with.

• Micromanagement,
• little or no agency for the team in organising their workflow,
• complex work management workflows,
• artificial metrics obsession without going to the gemba,
• dislocated teams.

Jira has little reason to exist outside reinforcing these problems.

Bas Vodde had this to say:

I’ve gotten a lot more aggressive against Jira as I saw it (used as Sprint Backlog) truly destroy teams as it led to individual isolated work.

I then convinced management they don’t need it, explained the drawbacks to the team, and I consider that the single most impactful thing I did. Overnight it improved about 30 teams.

From https://less.works/blog/2020/01/16/digital-tools-considered-harmful-jira.html

At the time of this writing, Jira is probably the most widely used digital tool in Scrum and LeSS adoptions. Unfortunately, using Jira commonly leads to some predictable dysfunctions. Some of these are:

• Scrum confusion and tool-owned processes
• Micro-management due to integration of Product and Sprint Backlog
• No shared team responsibility due to poor Sprint Backlog”

From Large Scale Scrum: More With LeSS by Craig Larman and Bas Vodde:

What Product Backlog tool at scale?

Use nothing more complicated than a spreadsheet and wiki.

Why? Because of the problems with using so-called “agile” tools:

• The focus is on tools rather than the deep systemic problems, and that diverts or avoids focusing on what’s important: changing behavior and the system. These tools don’t solve the real problems.
• These tools contain and promote reporting features, reinforcing traditional management-reporting and control behaviors.
• They convey a facade of improvement or agile adoption, when nothing meaningful has changed; “agile” tools have nothing to do with being agile.
• They often impose inflexible terminology and workflows to the teams, taking away process ownership and restricting improvement.
• The backlog is often hidden for most people as access requires an expensive account.
• These tools enable complexifying rather than simplifying.

It is, of course, possible to gain all these problems also with spreadsheets by maximizing their complexity. Try to avoid that.