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?
Top comments (48)
I saw an meme awhile ago "scrum is faster smaller waterfalls, change my mind". Somehow I believe that when JIRA is leverages as the end-all source of 'done'.
Item 1 from the Agile Manifesto: "Individuals and interactions over processes and tools".
So yes, if JIRA becomes the blocker it is the anti-pattern to fluid and rapid product creation.
My new PM gets annoyed when I call it mini waterfall, but like, if I'm spending half the sprint waiting on things to get in QA, and then I get flooded with tests to write, isn't that waterfall?
Devs can pick something from next sprint to pull in and work on to be occupied, but there's only so much automation I can preplan without code in front of me feature complete from a dev. I was able for one sprint to argue that I could fix a bug as a dev before the QA flood, but that hasn't really worked since (because I don't feel like arguing for work every single sprint planning)
Do you think, getting flooded is a direct result of using Jira or is it related to the way the project is structured? Getting flooded is always a bad thing (and probably your PM should get annoyed by that), but I believe that could happen to you with any other tool.
Jira's a variable, for sure, but it's mostly management.
Mainly, Jira metrics are what run our management (actual HR managers, not PMs). Because of needing set qualitative measures to judge teams on, no one is allowed to use anything other than the Approved Jira Workflow For Scrum Teams.
My team is over 50 sprints in with a fleshed out backlog... there's no reason other than politics for why we can't go Kanban. And Kanban is pretty much the only way to stop that flood since more things can ebb and flow naturally rather than in structured time frames. The alternative would be to make stories ultra tiny to get the burndown started earlier, but that would cause a dramatic drop in effectiveness since we'd be bogged down with the process of it all.
While Jira does have Kanban boards, the concept of something not being done by the end of a sprint is too ingrained in how teams are deemed successful or not.
Yeah, the devs aren't considered responsible for having completed testing. As you say, they pull in additional work for the sprint rather than making sure the rest is DoD.
Im constantly sadden by
Too many people out there in the industry, trying to push Agile as a solution to problem X... Without understanding this first line.
The end result is many projects being, agile in name only.
And unfortunately with my very terribly small dataset of personal experience. This correlates strongly to those who insist on JIRA being the answer.
The Agile Manifesto works. All (Agile) methods/processes/frameworks do not work. The idea about he manifesto is to constantly (re)think about improving your process (read: way of working). When you adopt a process, like Scrum, and stick to it, you stop doing that. Thus, you are no longer agile.
I complete agree with you. Violation of the first principle of the Agile Manifesto happens way too often.
It would be weird if we were invaded by buzzwords at each stratum of software development but not on the methodology level. Judging by the amount of books, courses, silver bullets, variations of agile, self anointend gurus and so on, it's perfectly understandable that meanings get lost in the process.
On this website we debate all the time about the viability of this or that approach, of this or that technology, it's not easy to debate the viability of different approaches to develope software as a whole or to manage teams only by the cover.
Ben's approach, to be always changing and refining, it's probably the most functional, but as you said, many people read an article or a book, decide it makes sense because they used it successfully in company X and then use Agile as a hammer. Kinda like some devs use microservices as a hammer because they used them successfully at Netflix ;-)
I'm guilty of using my favorite programming language as a hammer in the past.
This "agile confusion" we're in is understandable and Jira's complexity doesn't help.
I feel like this article represents a certain angst I’ve felt for a while.
In our small org, we have consistently re-written and re-factored our communication approach over and over again since the inception of our company, and we’re only six people. It’s that important.
I don’t think we have a perfect approach, but I think the part we get right is that we need to bend our approach to fit over and over again.
We use Slack, GitHub, ZenHub, email, Google Drive, Asana, with other context-specific stuff mixed in. We recently overhauled a few of these. I hope we can drop and merge a few of these, but time will tell.
This stuff is hard, and trying to solve too much of it with a standardized Jira approach is a recipe for waterfall IMO.
What I personally struggle to reconcile is my experience with Jira vs. what I see so many people in the industry do with Jira. You've made a good point that re-factoring communication is a requirement and the same is true of any tool you use. Every organization is as unique as a fingerprint or someone's taste in food. You can't take the way you did Jira (or your favorite foods) and transplant the same style to another team/org (or feed your new boss your cordon blue recipe when she's lactose intolerant).
Similarly, Jira is incredibly complex and understanding those moving parts to create effective communication patterns is difficult. You have to step back and have the experience of solving the problem as well as the wisdom to know what will elicit the correct outcomes.
When people complain about jira, they’re really complaining about how their managers have used jira and similar tools.
Definitely a people problem through and through.
I've never met a dev saying "I love Jira, it's my favorite tool" :D
As @preciselyalyss said, it's quite complex (though it got better in the last few years).
I think this complexity is by design though, because Jira is marketed to managers, not to developers.
I think a large part of the problem with JIRA is that there's simply too many options - they're trying to please everyone (and his dog) which just ends up creating about a trillion possible horror configurations for every sane configuration.
I've recently switched to an ultra simple workflow, fields, statuses, etc. - and don't really hate it so much anymore. But the thing is, a tool with about 100 times fewer features could have done exactly what I'm doing with it. And it took 4+ years to work out the details.
So who's winning with a tool like this really?
It just seems, in trying to make it right for everybody, they actually managed to build something that isn't right for anyone at all, because it's simply too complex for most people to understand.
I think it also comes from a place of different org sizes having way different needs.
Small business:
Big businesses:
(I may sound salty, but that's mostly because I wrote a 15 page paper on how companies use Agile metrics wrong)
True Agile kind of sounds like exactly the process you've been doing. Try it. Does it work? Keep it. Did it not? Ditch it. Though I'm with @rhymes that the timing of the email-less post was perfect :)
This just popped up on dev.to, you called for it :D
How we stopped using email at IOpipe
Pam Selle
Wow, great timing. Also amazing to see a first post from @pamasaur , I’m a big fan!
That's how I was working at a former client (mid sized company). After a while, they hired an agile coach to explain agile to the PMs (and after to the devs) but in the end the only things that stuck with the PMs were: sprints and tickets. Sprints were just used as containers to do as many tickets as possible and tickets were shuffled around week by week depending on possible changes of priorities or upper management requests. They basically ended up doing "agile waterfall" in a few teams. In another, the one where the coach was more hands on, the whole "goal" was far more present (and Jira far less).
Going back to the article:
After a few iterations of this in different companies I've worked with and various chats with fellow techies I came to the conclusion that this is due to the lack of UX designers working side by side with PMs from day one. All the PMs I've ever worked with more or less openly regarded design as the following: "please designer, these are the requirements, now do the wireframes and mockups to send to the devs". So, in that "school of thought" of software development, Jira is perfect because it feeds the ego of the developer closing the tickets, feeds the ego of the PMs that sees the tickets closed and so on. If the app ends up being subpar, well... you can just open new tickets to correct it :D
In truth, this is not an issue of tools but of communication and roles and team management.
#bestofdev :)
My current PM is very upfront about working at the Epic level. Like, she at the end of the day doesn't know what the nitty gritty of what we're implementing is, she is mostly in meetings with our UX guy or making sure overall features are being prioritized right.
On the one hand, cool, someone with a vision for the actual app. Normally I feel like since I'm working at an end to end level, I'm the only one who ever sees that. On the other, though, we're not really able to mix epics her way. It might make more sense for dependencies to work on a few api layer things at once to be prepared for the UI stuff once the wireframes are done, instead of scrambling before a release date to do everything all at once to Ship It.
Now that I'm on this rant, I'm a smidge disappointed the author didn't address how date driven Jira is. Every sprint has a day countdown. Every issue has dots for how many days they've been in a swimlane. Every release has a date. Dates are everywhere as the target rather than points or epics or something. Shouldn't we be more focused on the actual stuff of the app?
Basically like one of those social networks full of metrics causing anxiety to the users :-D
On the one hand, I love metrics. I like Jira as a tool for obtaining metrics.
On the other hand, for gods sakes, don't compare teams using those metrics. Keep them internal and use them for retrospective discussions, not dick waving in front of management.
That basically summarizes my awful 15-page paper on Agile metrics from my grad program that I alluded to in my comment to @ben xD
Metrics are a sharp tool. Easy to cut yourself.
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.
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.
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.
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.
i don't know if jira itself is an anti-pattern, so much as it's such a powerful tool that people forget that there are other ways to plan for and map the future. we've definitely run into this issue at my work where we have hundreds of discrete tasks stacked up in the jira backlog, but the overall vision of the company would be lost in that chaos. so we've opted to use other apps, other processes to keep that vision visible.
i think the best thing we've done is drop the whole pretense of a "source of truth" that lives in a computer somewhere. we have one whiteboard dedicated to front end concerns and the major milestones coming up ahead of the holidays, next month, and then for the future. and another whiteboard with broader company goals mapped along a picture of a road stretching out into the future (pole position / cruisin usa style).
bringing stated goals and vision out into the real world makes them more concrete and harder to forget about. so when you're given the task implement the upload button you can immediately see how it fits into the wider picture. if it's the only upload button on the roadmap, great! one and done. but if your roadmap is full of upload a thing features, you have a chance to reconsider how you're approaching the task at hand: as in making a more generalized implementation that will be useful in all the upcoming cases, or reconsidering the assumption of needing the button in the first place.
Very good point :) It's a tool that brings out the antipattern in all of us haha
It sounds awesome that you have a place that's worked hard to keep those goals so visible!
I mentioned it elsewhere, but I think the issue starts with companies paying for a tool and expecting all little bits of it to be used. And then buying tools that integrate with it. And then not wanting to budge on adding more tools.
So when Jira has the issue tracking and metrics you want, you end up using it for all your Gantt charts and high level stuff, and then using it for emergent work as well as long-term stuff, and then using it to track timekeeping and test cases, and then hooking into Confluence for documentation and ultra high level requirements/goals. And then you can't leave because the whole company is in there. But adding Trello or something would mean more money and only vetting options that have webhooks with the existing thing. And that would fragment the company, so keep everyone doing everything in the one tool that only does a part of it really well.
I think this is also a sticking point for areas that have high dev talent. I'm in Pittsburgh, so there are places looking for Carnegie Mellon Software Engineering graduates. They want the best students from the best schools, taught to engineer and architect a piece of software, just to put them in the little boxes mindset... Code monkey a little button and move on to the next button. That seems silly and a waste of that talent.
Jira does have a reference to the Epic on every story view, which I guess is to keep in mind how things fit into the larger picture, though I would prefer a better visualization of that. And a trust that the decisions made when implementing one issue aren't tossed aside by the people managing the Jira flow. "Why can't you just add a few more user roles? We're supposed to be agile." "Uh, the original requirement was we would have 2 roles. Not these mismatched middle roles. The entire thing needs gutted now." "You should have planned for this better." "wat, you never mentioned more roles. Ever."
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.
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.
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.
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.
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 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.
😂
Complex human problem solving is hilariously underrated in so-called knowledge work.
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.