The Slow, Painful Death of Agile and Jira
ehandbook.com
ehandbook.com
I founded several new teams at that company and was approached by the head of the Scrummasters to integrate with their process. I flatly said no, I don't need your services, I've been running teams for 20 years and I'm good. It became this huge blowup that went all the way up the chain of execs until a compromise was reached - I had to accept Scrummasters for my teams but I could direct them to do nothing except basic JIRA ticket shuffling.
Fast forward a few years, I've left that place, but my teams became the centerpieces of the company and all new teams are now modeled after them. The Scrummaster team was cut in half.
The best part is my team structure is closer to the spirit of Agile with self-organizing teams empowered to operate how best suits them and the Scrummaster team was forcing rigid ceremonies that were at best time consuming and at worst completely useless.
But obviously this means it's not a dedicated role and so a missed 'opportunity' to create more "manager of something" roles, especially for project managers who feel threatened.
Not surprising sr devs weren't jumping on this whole hog.
That's perhaps what you would do to your team but that's not what I suggested in my comment.
> Not surprising sr devs weren't jumping on this whole hog.
Senior devs interested in growing beyond pure dev do jump on this opportunity and job satisfaction an retention increases.
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
I would read it, but I am running late for my daily standup and haven’t finished updating JIRA yet to document my progress since yesterday’s standup.
The following paragraphs, what everyone misses, essentially say "but that is not enough, you also need..."
To me the real message was "think for yourself and do what works best for you", and the organizations that actually do that typically don't need to be given directions and don't follow advice from productivity gurus. Toyota didn't read the Agile Manifesto and come up with their own solution to their own problems.
The people that fell in love with Agile where the most further from it, the message was vague enough that they would seek more concrete frameworks, which inevitably would put them out of the "think for yourself" zone.
I'm not saying this is the outcome of an Agile approach, but sure seems common on the Scrum projects I work on.
Smaller iterations of deliverable work prevents a big up front design and putting in features including UI designs, software designs, coding, tests, QA testing, etc. and then it doesn't get used or has minimal ROI.
JIRA sucks. If you think your issues with delivery are tied to your work tracking system then you're looking at the wrong things.
You can carve a guitar neck out of a single large piece of wood, but 60% of that piece of wood turns into waste.
Or you can glue three much smaller pieces of wood together, and 5% of that wood turns to waste.
It takes longer to make less waste.
If it means delivering features faster, whatever they are, to make an executive feel better, agile will not help you.
Someone (product owner) should be prioritizing the core things needed to be delivered which means you don't waste development and testing cycles on things like an extra button on the MS Office ribbon bar that does a hardly used feature.
i used to think the same until i had to use azure devops.
i legitimately miss JIRA nowadays.
CVS isn't good because Visual Source Safe exists.
As an analogy, it feels the same as saying "git sucks", and going on a journey to try CVS, SVN, VSS, DropBox's version management, Apple's TimeMachine, Synology's file management etc. to discover the strength and weakness of these random solutions one by one.
At the end of the day you end up really liking git, but when telling to people that git is really great you're met with grunts and middle fingers.
And that's the issue most people on this thread miss. If every tool for reaching some goal suck in some way, do the best of them really suck?
after 17 years working as a dev, i came to the conclusion there's no good ticketing system, there's only less-bad-ones. and i honestly think a well configured jira instance is the pile-o'-shit king.
Our team used Redmine from a decade ago, but people like all the pretty ways to drag items between columns or something
i worked at a place back in 2008 and we used redmine -- i even wrote a plugin to track worked hours so we could properly bill clients (i ended up learning rails because of this).
You got me looking, but this doesn't seem to exist. I kinda want to see a Calvinball issue tracker now.
This is what happened to us for years, trying to create a common process for multiple teams on the same jira project. Then the manager that oversaw those teams left and during the last reorganization we all split up into our own jira projects where each team could configure it however they wanted. There's still rough edges, like with how links are inconsistent, but overall it's been pretty great since then.
Even the original waterfall model empahsized on feedback, feedback of design, feedback of usage https://en.wikipedia.org/wiki/Waterfall_model#/media/File:19...
I also have had bad tickets that define loose acceptance criteria and leave it up to the developer to decide the UX, edge cases, error handling, etc.
The former removes a lot of burden of decision from the developer. It feels like the author of the ticket is showing ownership. I can mostly worry about how to implement it and not worry if my decision is going to negatively affect users that I'll get blowback from.
The latter feels like they are letting an assumed-to-be-smart person make more decisions on the product and that they're closer to an ideas person hitting you up to make their latest world-changing startup idea.
With the latter, the developer is taking on more responsibilities and accountability. They need to be good at development and also good at understanding the users and the product and UX. That's two roles in one if they're good at both responsibilities (they probably aren't), but the compensation is likely only around 1 job.
And now that developers are also mixing with operations/cloud management responsibilities, you now have a lot of groups of people hitching their wagons to what the developers do or think is best. Everyone is here to support developers so developers are now making a bunch of decisions in areas they aren't experts at.
Following tickets (almost) blindly should be an advantage. At no point should I get a ticket and have to ask the question "will users actually want this?" because someone else should be answering that and not a developer. Being able to deliver a ticket that a developer can follow (almost) blindly means that thought and care are going into the decisions about how to deliver something. It ultimately means developers can make decisions in the areas they are experts at, and other staff can make decisions on things they are experts in.
Edit: definitely not disagreeing with your post, just some thoughts on the issue
The "good" tickets can be given to junior dev/low cost contractor/ChatGPT.
Whenever I read things like this I feel like a lot of developers don't understand what their job actually is. It's not just translating tickets to code.
I had to eat my shoe on Jira, railed on it for 10y easy.
Once you find a workflow requirement complex enough, very few things can do what JIRA does, including configurability.
Hiring a senior experienced JIRA consultant made a huge difference.
Other options look nice until complexity explodes.
Given the (forced [0]) choice I'd rather use unconfigured Jira than configured Jira. The mysterious "well configured" Jira is a Goldilocks zone that I've heard theoretically exists but have never once encountered in the wild.
[0] If the choice is Jira or a gun to my head, for instance.
I hired a single Atlassian consultant, and after taking the time to understand things, he delivered something that shut my opinion up about JIRA.
Like you are implying, every company can be different, and tools like JIRA have many ways to get the same thing done.
Still, since JIRA self-hosted version has gone away, there is opportunity for something new to cover it's feature-set in a new way.
If you aren't allowed to do anything if there's no Jira ticket, you just created a lot of process friction to get anything done. That's a great way to weed out things like independent thinking, initiative, and pro-active thinking. Jira is the perfect digital idea shredder.
Add approvals and nitpicking middle management and we're back to the good old days of people asking for TPS reports. Which is an Office Space reference, a satirical movie from the pre-agile era (25 years ago). Replace TPS reports with Jira ticket and you got most scrum sweat shops covered. It's uncanny how on point that movie still is. If you think things are different now, go (re-)watch that movie.
Organization wide agile is not a thing. That never really caught on. Processes like scrum are designed for small teams. Attempting to coordinate that with 100 teams is hard. And mostly futile. I've seen the results of companies that attempted this; not pretty. I once attended a sprint planning with 14 teams from all over the world. Because flying them in was expensive they only did that four times a year. So, to get anything on the agenda you needed to plan months ahead or you'd be too late. The agility of an oil tanker. I never saw so many postits in my life. All backed by Jira of course.
Most large companies have no such thing as company wide sprints for the simple reason that that's not a great way to run a company. Mostly they still operate the same way they always did: on quarterly and yearly reporting and targets. If products involve more than just software (like actual hardware of physical goods), that tends to dictate the planning.
Responding to change over following a plan
The whole point was to be agile enough to work in a manner that's most effective your team and organization - and even that may change on a project-by-project bases if different stakeholders are involved.
There's no scope creep with agile, only responding to feedback.
The one you will find in the Agile Manifesto and related writings. e.g. "Individuals and interactions over processes and tools"
The other is a top-down, upfront-planned, tool based, process heavy corporate method of task-based micromanagement. Usually in Jira.
There would be no point in killing Jira, as the management that wants what it does, would simply find a similar equivalent.
So any actual working system can be stamped as "not agile" as surely there will be some aspect that is not perfect.
My favorite was "Customer collaboration over contract negotiation": a contract is there to protect both parties, so of course it will be central to a project and people will preferably stick to it, even adjust it when it doesn't fit the bill anymore. So in any case where things go wrong for whatever reason, we can inevitably say more collaboration was needed and that Agile principle wasn't respected.
That probably comes from the same sentiment as parents telling their kid to not fall from their bike, it's in human nature.
No, there is something concrete there: No managers. Traditionally those would be the concern of the manager. Agile says it best be the concern of the developers.
Which, of course, is Agile's whole deal. It is all about self-organization. The Twelve Principles goes into more detail about what to think about in the absence of managers; to ensure that developers take over the jobs that managers would traditionally do.
Ironically, it seems only managers have an interest in Agile, in a bastardized form, as a way to push their workload off onto others, but without giving up their paycheque. Which is also why we're seeing a death spiral now. With higher interest rates seeing businesses cracking down on the work being done, managers are finding it necessary to shape up and start doing their job again.
I guess if GH had its own version that would be slightly easier. I think most people dislike Jira for how their orgs use it, with sprints and points and as a management/overseer tool. I feel like 90% of engs hating anything is due to management using something as a shortcut metric to battle royale their team with BS efficiency stats (tickets closed! PRs pushed!)
1. Manager types think JIRA is a solution to getting shit done when the real problem is bad communication and politics.
I also have a huge dislike for all the horrible things so many companies do with Atlassian products, and although that is not necessarily their fault it is still somewhat related to those products. Want a guaranteed raise next time? Just chop your code up into a zillion commits, and write a crapton of sub-issues. SMH
GitHub issues/projects are great for small teams, but can't remotely stand up feature-wise in a larger organization (and assumes everyone is a developer) so as much as I love their stuff, it cannot really compete in the Enterprise space by design.
ServiceNow, Jira, you name it. Under the hood they are just a database but the customizable monstrosity of fields and forms rules and reports and workflows on top makes them all eventually suck. Heck, this is probably why SAP and PeopleSoft suck too.
Kind of a convention over configuration thing.
You can make Jira functional for the team. But you can't make the UX performant.
GitHub does have its own version. You can organize GitHub Issues into GitHub Projects. GitHub Projects have all sorts of iteration planning tools and team management tools and metrics reports that light up as you configure it. I've heard and seen screenshots that even more light up if you have an Enterprise Cloud account and/or pay a GitHub Consultant (they way some companies love their overpaid Jira Consultants).
I've tried to make the case for GH Projects to employers before. Supporting only one tool is very nice from a developer experience viewpoint. Of course, that's not something management often cares about, and Jira isn't always just software development, but also sometimes incident tracking and support desk and everything else and having more "synergy" there appeals more to some sorts of managers.
I had no idea it was specifically linked with “agile”, that org wasn’t doing agile. Is Jira “fine”? Is it really the Agile process that people are hating on?
That's it. I've essentially built this for myself a few times over so I doubt this is what people are actually paying for so I must be missing all of the features that people hate
You want to know what's being done, what needs to be done, who's working on what, where they are, what branches or repos are related to that work, how long will it take, etc. And someone's got to write that down, someone's got to keep that up.
There are ways to get things to talk to each other to automate some things, but at the end of the day, you gotta enter the data. It's a lot like the "blockchain" in that regard. The issue has hardly ever been the tools around asset management, the issue is about getting reliable data into the system.
Bookkeeping also takes time from actual development. So estimating how long something takes and recording that estimate makes that task take even longer.
That directly means it will only be as good as their manager, and also the process manager's vision will be perfectly reflected for the better, and in many cases for the worse.
If they want to review every ticket and manually accept state changes, they can. If they want to keep track of every minutes you spent on micro-tasks, they can. If the manager has no idea how the team process should work JIRA won't give them any direction and will perfectly reflect the chaos in the manager's head.
Of course from the admin side it can also be a nightmare to host, as any similar long lived B2B product.
I think people are mostly hating on Agile, and JIRA helps experience the full blown of it the most.
Agile™ was born from web development consultancies as a defensive process for managing bad clients.
A lot of the process will make sense if you think about it in terms of business stakeholders eventually suing you. You want to make sure every decision is documented, never commit to a firm timeline, produce artifacts of work at a super granular cadence, and make sure to give stakeholders the illusion of control.
It's not a good way to make software but it is a consistent way to make software.
This makes it attractive to large non-tech businesses because it means that they can effectively reason about and plan software development at a high level. They'll never be super fast in delivering that product but for most of these companies that doesn't matter. Their moat isn't their technology - it's something else and they just need the software to work well enough to facilitate the actual business processes that are their moat.
Agile is about eliminating management in favour of self-organizing teams. Hence how we ended up with all these tools (standups, Jira, etc.) to try and help developers do the work that managers would normally do.
Although, frankly, I'm not sure Agile ever happened. What we got instead were managers trying to force developers to use tools intended for self-organizing teams, but still with managers and without self-organization, and everyone suffering from the impedance mismatch.
Now that we're in a new age of higher interest rates, managers are realizing that, if they want to keep their jobs, they'd be best get back to doing the work themselves rather than trying to pass the work off to others. The passing of the buck is what we're seeing the death of.
Yeah . . . no. The biggest mistake the Agile movement ever made was sidelining management and claiming they were irrelevant. You can't do any kind of work at scale without some layer of management and coordination. OK, sure, there's the pie-in-the-sky dream that every company will be able to swarm on problems and self-organize at every level. But that's not feasible in the majority of cases.
The correct answer is to manage correctly by recognizing the professional expertise of people doing the work and giving them latitude to come up with creative solutions as opposed to dictating everything. But companies have CEOs and boards to set the overall direction of the organization, and that's reality as opposed to some anarcho-capitalistic pie in the sky.
Was it supposed to be? The Twelve Principles makes it very clear that you need extra special people to have any chance. It was clearly never meant for everyone. It literally says so.
Perhaps our biggest mistake was thinking that we are special?
Nonsense. If anything, the failure is on leadership for not adapting and growing their people. There are three kinds of people in any organization: the rockstars who will naturally excel, the incompetent who should be fired, and the vast middle whose success is a factor of leadership and seniors putting effort into their growth and development.
That very well may be an unrealistic deal[1], sure. There is probably good reason why Agile never happened, instead seeing management cherry-picking from a a bastardized version of its idea to lighten their workload. But you cannot meaningly remove what it is as it seems you are trying to do. If you do, it no longer exists.
[1] In fact, I posit that it was written under "Agile Manifesto" to purposely draw parallels with the "Communist Manifesto". Communism isn't meant to be realistic either. It is a sci-fi look into what life could be like if we achieve post-scarcity. Agile is similar in vein – a look into what life could be like if everyone became excessively driven high achievers; not meant to be a reflection of this world.
That said, The combination of lean, scrum, iterative development, and infrastructure as code and cloud replacing dedicated operations teams "won." That's currently called "agile" but is a subset of the original vision.
> Agile is an iterative methodology, but all iterative methodologies are not agile.
is a sentence that contradicts itself. You meant
"Agile is an iterative methodology, but not all iterative methodologies are agile."
Notice the universal quantifier moving across the negation is not semantically stable.
And the reason i thought it "fun" to mention this is to segue to this cool topic, which is exactly what i mention above.
https://en.wikipedia.org/wiki/De_Morgan%27s_laws#Extension_t...
That said, though, what does need to die are the online flamewars about what is or isn't "true Agile," because the true north star is delivering quality software faster in order to realize a business need.
We can go down philosophical rabbit holes about "true Agile" all day long, but in the words of Manfred von Richthofen, "all else is rubbish."
And everyone also seems to have this pie-in-the-sky view of the manifesto whereby nothing on the right exists or matters . . . that's not what that means. You still have processes and tools. You still have documentation. You still have contracts. You still follow a plan. You're just not handcuffed by these things unnecessarily or having them force you to do stupid things.
If you need more than a board, and maybe some notifications, you are doing it wrong.
Also, I don't fancy the term 'Tech Bloat' because it doesn't seem to cover at all what the issue at hand really is.
To me, the real problem is that:
- People don't like to think about process because it's hard and not fun
- People don't take responsibility for a process or don't want to due to risk and little reward
- People add tasks steps because a minor thing went wrong once, years ago (and nobody involved is still around)
- People NEVER remove tasks because they only see risk no reward
- People don't seem to understand that processes should be as minimal as possible
- People don't seem to understand that you need to hire people that need minimal process and still understand what needs to be done (like asking questions instead of making assumptions)
What you end up with is an organisation that has a ton of complaints and gossip, but nothing changes.
But as a consulting type, I've never understood how you run a project with a fixed (well, ok, continuously growing usually) scope, a fixed budget and a fixed timeline. Which are basically the constraints on every single project.
I think I have found though, that if you can get a client that will spend the time to really define the project goals and how they will be measured, you can almost steer the scope in the direction of priority features.
Then, you can be somewhat successful with running agile on certain parts of a project (like UX design), while "phase-gating" other components of the project that have real dependencies.
You end up, in effect, with a waterfall process with some phases being done using agile methodologies.
I mean, as a fast learner, I'm already agile, have been for 20 years, it's not like you discovered it yesterday. Lots of people have been agile for thousands of years.
In reality things get done if you, the manager, unblock blockers, fund necessary shit without piles of documents, make employees happy to work, and make sure nobody is wasting time doing things they are not good at.
Rather than discuss how specific features can and will solve business objectives and how exactly they will be measured, it's all a bunch of hand-waving and arbitrary deadlines.
I think consultancies and corporations looked at vertically-integrated tech companies having lots of success with agile & decided they needed agile themselves, but didn't want to give up fixed-price. Probably correctly! But the key to those tech companies' success was the vertical integration, not the agile methodology
The important part is to create a team, people working together, helping each other, trusting each other.
Anything that increase trust and organic collaboration is useful, most of the rest is a waste of time.
Ex: if your estimates are used once to put the blame on someone, congratulation you just destroyed the morale and trust of the whole team. Now everyone will start to lie and pad their estimates, the game is now how to behave to cover your ass and the one of your friends.
Whereas a PM's job is all about that. We have bloated products. Mostly. Feature packed with FOMO. Incoherent. Inconsistent. Incompatible. But features.
Maybe this was the point of the linked text but I could not get past the paywall.
If it was just a board with cards with text it would probably be quite usable.
Where I work we are theoretically doing scrum, but it is the worst of all worlds. Tickets (I mean - stories) are very vaguely specified. While we get almost no specs for the stories, we are asked to point the stories, and are then held to those estimates. We have deadlines, even though the point of scrum is not to have deadlines. Also, the features often tend to be complex and incremental, so if I am off doing other work, no one can easily step in and work on the feature I am doing, so that there is the agileness to move me off the feature I'm working on to fix some fire, but not the agileness to have someone else work on the story.
"That's not really agile, that's not really scrum" - well, whatever. Most of the SWEs I know are in similar boats. It can depend, I did have a PM a few years ago who actually did spec out the stories more. I can get on my PM's back to spec out the stories of course, but I can also spend all day getting on everyone's back to do their jobs as well.
It's none of the benefits of waterfall, with almost all of the downsides. Plus the theoretical benefits of scrum like no deadlines or the ability to move people around like cogs is not something found either.
And who really cares about Agile? It is a name for a system of interaction in software product development. Just a name. The question is whether there is something better. It is easy to say Jira sucks and Agile sucks. The questions are a) is there a better system of software product development and b) are there good tools that help you implement that system?
And perhaps the other question is WHY? Why is democracy supposed to work? Why is Agile supposed to work?
These days you don’t really need specific tooling—nor should you rely on it to rate features and keep track of meaningful work.
Complex systems will always accrete complexity. New elites will bulldoze a nice location and start a new, open and beautifully designed quarter for themselves. And pretty soon it will be swallowed by the mud of complexity.
Seriously, I do not want to use a UI that gets in the way of my process...which is why I use kanban boards....so much simpler...and I use it in every process from code to design to writing...
I have been on multiple teams that switched from Scrum to Kanban and will never go back. I'm convinced the whole process of fitting things into two week sprints is a huge time drain, gets abused too easily, and doesn't justify itself if you have decent CI anyway.
Give a Scrum Master and a Product Owner a Jira install and you can do the most amazing tricks with disappearing thousand dollar bills.... :-)
I worked somewhere where we dumped our (very complicated) 'agile' tracking tool and went back to cards, and productivity increased, people actually communicated. We did eventually add in JIRA, to support remote team members but banned 'customization', 'workflows' and all the things that actually get in the way of being an Agile team.
JIRA escalates quickly. You're smart to put things in place to prevent that.
Well.. actually, it doesn't needs to be slow.
Jira is a loss of time. And Agile is even worse, just a useless, counterproductive dogma that only drags the development of the product. We dropped them both during the pandemics, and that's how it stayed.
Unfortunately, "more features" is a lot easier to market and sell than "simple and actually works", at least on the timescale most companies operate on.
The author also notes how one sign of tech bloat is talking to customers repeatedly without becoming an expert on customer behavior. One of the reasons for this is that the people who talk to the customers are often times PMs/POs who aren't subject matter experts, and their "talking" is simply asking users if they want a new feature instead of doing discovery as to what users need. This is a UX issue first and foremost, but alas, companies are laying off UX researchers and UX people in general.
Understanding the whole process of the issue you're trying to solve is important in any industry, but that requires people to be proactive. Unfortunately, these days there's a lot of "well, we know what the customer really wants" because they looked at a NPS score or rely exclusively on survey responses, which are inherently reactive.
0. https://www.scrum.org/resources/blog/scrum-team-self-managin...
1. https://www.thisdayinquotes.com/2022/04/we-have-met-the-enem...
I think it's imoprtant to recognize that if a whole crowd of people say "We hate X" but everybody in that crowd hates eachothers proposals even more, it just creates a facade of agreement where there is none.
"I want steak!"
"I want salad!"
"I want fish!"
"Alright, well, there's absolutely no agreement, let's stick with the feces."
In that case you'd probably find nearly 100% agreement on steak over feces, or salad over feces, or fish over feces. You'd have complete agreement on any alternative to feces.
But if you read this thread, it's actually full of people actually saying "I was forced to use [alternative tool] and I prefer Jira". There is no tool that has 100% support over Jira.
In fact I'd be surprised if there's a single alternantive to Jira that even 40% of people agree is better.
I've worked at places that tried to do project management via worksheets and it's quite a challenge to keep those up-to-date, much less add dynamic connections to different repos for updates, adding new stories/tasks, etc. Jira is a godsend by comparison.
Unsurprisingly, they were planning a project to introduce another tool on top of it all. Pretty much just bike shedding the company into the ground.
I think the negative responses are directed at the use of "meh" and the seeming indifference to an actual problem that could really use a solution, even if we don't have a perfect one everybody agrees on yet.
For my money Linear is just about perfect.