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)
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...)
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."
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.
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
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.
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.
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.
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.
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.
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.
I've felt this way about Jira for awhile, while the tool is nice and can communicate certain things, it feels restrictive in many ways. Overall its great for management to know where things are in the lanes, and if you keep notes in there they can see how things go, but honestly I've felt that you spend a long time configuring Jira to get it to work the way you want it to, which kind of goes against the intention to me.
Lately we've been using Rally and I see similar things.
Makes me wonder if maybe going back to basics like sticky notes on a white board is the Paleo version of Scrum/Agile.
I want this on a cross stitch and hung up in my cubicle :)
It also depends on the individual managers, too. For some reason, we have an acronym level person with access to our board which then makes them nag the PM when something is pending acceptance. We also have a customer with access to the board, so we need nice, neat customer friendly names for features. Implement x becomes Fix y because they don't like y (which was an early requirement, not a bug) and don't care how it's technically implemented via x.
I've suggested having another Jira instance for developers only. The PM didn't take that well :P Though we moved from Rally to Jira, so it's a person thing, not a tool thing.
JIRA is a tool, it is conceptually impossible to be a pattern or anti pattern. JIRA in its massive configurability can adapt to most any pattern.
If I use a hammer to try to screw in a screw, was the hammer ill designed, or am I an idiot.
I current am teaching people how to use the entire Atlassian stack of tools, I always start off with a what is your process and lets see how the tool can help you, I get blank stares and get asked what all the tool can do and what problems it can solve for them. Without a process of how people interact and manage themselves JIRA and all tools are just a wonderful time suck to make it look like things are getting done and you are trying.
Here's completely different point of view - I assume other tools / repo hosting solutions can offer same feature, but as developer, Jira issue and BitBucket repo commit linking makes it much easier for both code reviews or tracking down issues for previous changes. Game changer.
Can't say I'm fan of their new UI tho, seems slower, unpredictable and not as clean visually as the last version.
As for "agile"...
The second Jira/agile is ONLY used to wrangle in and deal with those pesky developers, and doesn't get buy-in from rest of the company, you might as well give up there and then.
That's not to say if directors of company / project can only deal with waterfall approach that you can't make "waterfall-ly sprints" work for both directors and developers.
True waterfall, waterfall-ly and true agile all bring something different to the table, saying there's only one true workflow (or language, or framework, or infrastructure setup, or ...) in my humble opinion seems extremely short sighted.
The reason Waterfall exists is because it adds structure to an otherwise chaotic endeavour, by having large projects have a prescribed flow. What it misses is self-checks and the ability to shift course when needed.
Agile (and in particular Scrum) tries to remedy this by using much shorter cycles. And I say shorter because Waterfall also cycles, but on a project level, with the (large) chance that the product gets scrapped before a follow-up project is started.
That's structurally the biggest difference between Agile and Waterfall (though communication of course comes in as a big tooling difference). So shouldn't be that big of a surprise that an Agile tool feels Waterfall-y at the lowest level.
I'm not convinced that Jira is at fault itself, it's a very flexible tracking tool that can be used/abused in many ways. As others have suggested here, I think it's the tutorials, courses, examples (maybe the defaults too) and wider culture surrounding Jira that cause the problems, likely because of it's heritage.
My company is experimenting with alternative team organisation & delivery approaches: things like DAD (disciplinedagiledelivery.com/intro...), which is well supported by Jira, and working in autonomous squads, guided by a common System Development Life Cycle strategy that helps teams choose their local implementations and still be able to work together (yes, large org. fun).
The mantra of breaking problems/issues/delivery down into bite size pieces doesn't have many alternatives (please suggest some though!), and Jira let's a team do that, provided they choose why & how carefully, then write those principles down :)
It might be that my org is too large, but individual teams can't really pick what works best for themselves. Metrics need to be uniform across all teams, so no deviation from the norm that could cause your numbers to look off (though I haven't seen managers comparing velocities... yet...). I'll have to look more into that methodology, thanks for the link!
Only thing I can think of off the top of my head at night is only break down to the epic level and give that to one person and let them roll with it. Roughly T shirt size how long it should take, actually use stand ups to get feedback on your approach rather than status updates, but for the most part be trusted to break it down and manage your own workflow/implementation. Maybe you ship code daily. Maybe weekly. Lots of peer reviews or few. That could be a team policy or a personal one depending on how you work, whatever. You wouldn't get a diverse skillset if epics are taking a month or two, but you would get people who are experts in their zone who can pound out bits quicker than constant context switching and they'd have the high-level thoughts of how it should look and work in the end while doing the early work.
Perhaps the problem is managers trying to use a collaboration and work tracking tool as a way to measure performance. This inevitably distorts the work - whatever is measured or set as a goal will become the goal.
That sounds like a fairly unhealthy regime, measuring things that don't actually matter to the paying customer, only the kudos/bonus of the local manager(s) and feeding a morale destroying performance management system. It was stuff like this that encouraged me to leave my last employer (BT) and work somewhere smaller (320 people, ~100 devs in 2013) where I had an opportunity to help prevent us making the same mistakes... we're up to almost 1000 now, I'll let you know how it goes when we get to 1500 people around 2022!
This is pretty much what we are trying to do, with a team/squad (choose your metaphor) owning an Epic: typically delivery of a value providing (micro)service defined by an API (eg: data matching service, usage logging service, authentication service, etc.) or saleable things (products/featuresets) defined by their customer facing API/UI/UX. We have infrastructure and architecture squads, providing our base platform to deliver services into (currently in AWS) and managing our roadmap in the open (with customers!) for everyone to see/contribute if they wish. Critical to success in this trust model is open communication, not "managing messages" through traditional hierarchies. Jira actually helps with this, if a task is stuck people can see and help out (usually a hand raised in stand up), if a technology lets us down or a customer changes their needs we can see that in reports where tickets get bounced back, perhaps to architecture to try again...
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
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
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.
me_irl if rent wasn't so high in the city because of Google
Though it does make me wonder if software in Pittsburgh is its own little bubble of industrialization due to the steel city roots and East Coast ideologies. I don't expect full Seattle / Silicon Valley, but I haven't worked in enough places to know if this is a city thing or a tech thing.