DEV Community

Cover image for Is Jira an antipattern?
ItsASine (Kayla)
ItsASine (Kayla)

Posted on

Is Jira an antipattern?

This article was shared on my work Slack and it's pretty fantastic: JIRA is an antipattern - TechCrunch

It's clearly an opinion piece and seems meant to generate discussion, though only 1 other person wanted to chat about it on #general

The biggest part that caught my eye was:

Doesn’t that sound a little … um … waterfall-y?

It does seem like Jira's hyper focus on the little pieces encourages a waterfall approach. Each issue goes through a waterfall. A sprint is successful if it finishes its waterfall in x weeks.

What do you think? Does Jira help developers lose sight of the big picture, or is the worth towards making workable slices of issues more than worth it?

Latest comments (48)

Collapse
 
nastya0058 profile image
nastya005

I don't think so. I think now Jira is much powerful tool than before, and it's flexible enough to work greatly in different teams in any business (check the link to learn the cases: polontech.com/blog/is-jira-only-fo...)

Collapse
 
powerc9000 profile image
Clay Murray

Jira has always been a tool that I've never seen any developer actually like. It always seems like only managers want it. Because it's easier for them to track progress. "Do the process this way so I know what you are doing."

Collapse
 
powerc9000 profile image
Clay Murray

I prefer: Managers define what needs to be done in a more general sense.

What the project will involve and what it doesnt involve.

Then give it to the developers. They come up with their own todos and flows.

Collapse
 
andrewbrown profile image
Andrew Brown 🇨🇦 • Edited

I don't know if its anti-pattern, but I can say it certainly is awful.
Its a struggle to consistent attach screenshots to tickets. 50% of the time it doesn't work and I have to do a hard refresh.

Sadly it checkboxes all the requires most companies want.
Hard to live without swimlanes.

I had at one time wanted to create my own app on Github called swimmer which added swimlanes.
I had stopped since at the time I didn't know how to best architect the backend. I do now but have moved onto other things

Collapse
 
jessekphillips profile image
Jesse Phillips

Well I kind of think the concentration on the bigger picture is the problem. You're supposed to make small valuable progress, sure there is usually a larger goal but each step is about what the client wants to provide them with value once complete.

I do understand why that isn't what happens, but that is probably why we see so much butchered scrum. Big picture in Jira does suck, but you're not supposed to be asked for big picture progress.

Collapse
 
dariusx profile image
Darius

JIRA definitely enables one to lose track of the big picture. It starts off by being DIS-integrative: exploding things into atoms.
Then, as the next layer, it allows you to build an integrated picture through the use of classifiers: Labels, Components, Fix-Versions and so on. And, ... classification is hard.

One aspect of a detailed breakdown is that one may end up with (story-points or other) estimates at a very low level of detail: too low a level. When you add across JIRAs you might end up with twice what you ought to spend, because you picked up the same artifact 4 times, in 4 different sprints, even though you did have visibility to all 4 changes at the start.

Collapse
 
lexlohr profile image
Alex Lohr

My squad adopted jira as our sole board 4 months ago as an experiment.

There have been some drawbacks, for example the burn down is unusable if you use subtasks to keep stories transparent, but the advantages (especially if you work from home) outweigh them.

Yes, jira can be a really clunky tool at times, especially if multiple teams at multiple sites work with different approaches and work flows inside the same instance.

It's important to remember that it is but a tool. It's not a pattern, it merely supports certain patterns. That being said, you can use it both to your advantage and disadvantage until you find ways to improve it (e.g. automate a lot around your work flow, leverage filters and views, integrate bitbucket, slack etc.) or find a better one.

If you do succeed in the latter case, please come here and tell us what and how.

Collapse
 
petarov profile image
Petar G. Petrov • Edited

I never understood the waterfall argument. We use the Kanban board in Jira, we decide when the release is ready or not and we definitely do not have sprints or hard deadlines.

So Jira does not really stop me from achieving any goals, in fact it helps.

Collapse
 
xortype profile image
xorType

No. The culture is the antipattern.

Remember - Individuals and interactions over processes and tools.

The tool should adapt to how your team works - change the jira workflow. Organizations should adapt to how the dlivery teams need to work. In Agile, everything is built on trust and transparency.

The real problem is leadership took a 2 day certificate class and parade around as they know everything. Then hire people that know nothing and press for results on a waterfall budget while monitor using waterfall KPIs. Add in the marketing hype and your back to a sprint being a mini-waterfall or in SAFe (program increment). Agile and its tools are being abused right now.

 
itsasine profile image
ItsASine (Kayla)

measuring things that don't actually matter to the paying customer

Implying there are paying customers :) A lot of what is being worked on is internal, so there are stakeholders, but no one's getting rich off of it. The devs are 3 levels removed from stakeholders, so our perception is more that we're making a thing and telling people to use it rather than them actually wanting the thing. And our actual users are the employees several layers down from the stakeholders...


Sounds like you've got a really solid group and a good workflow in place! :D

Thread Thread
 
rhymes profile image
rhymes

The devs are 3 levels removed from stakeholders
And our actual users are the employees several layers down from the stakeholders

Are the end users part of the team?

One of the principles is "customer collaboration", where the customer (or a representative of them) should be part of the team.

If you're "making a thing" for who knows who, no wonder you feel that way :D

Thread Thread
 
itsasine profile image
ItsASine (Kayla)

Are the end users part of the team?

Nope! The product's three-letter-acronym person at the top talks to the customer, who is the stakeholder, and people several organizational levels below the stakeholder are the ones actually using the thing that the stakeholder bought (it's a sister company, so we know of their org structure but aren't coworkers).

The stakeholder has access to our Jira as a part owner of the product, but what they want and what the person actually logging in to the system want are quite different.

Collapse
 
forkandpie profile image
forkandpie

IMO, Agile stops (and Waterfall starts) when the tools are not chosen by developers, but "applied" to developers.

If developers are happy with Jira workflow and see the benefit - it's Agile. If Jira is imposed to handle and monitor developers (but it slows down the work and create obstacles) - it's Waterfall.