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 a less experienced observer waddles in 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.
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.
- 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.