I was a newly hired Director of Engineering a company that drank the Kool-Aid of Agile and had an independent team of Scrummasters who just facilitated morning stand-ups. They had no project management responsibilities, so I kept asking what do they do all day after the morning stand-up and no one could answer me. I got severe pushback that they should take on any set of greater responsibilities.
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.
I've always interpreted the 'scrum master' role as the person on the team that is both the process expert and senior enough to be able to generally coach others and help unblocking issues. Ie. one of the senior devs on the team that has been interested enough to learn the scrum agile process, but who takes on the role can change depending on circumstances.
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.
More responsibility for the same pay, corralling people, and inevitably adding their workload to yours? Because SME/mentor < sr dev when it comes time to rightsize the CxOs gambling losses.
Not surprising sr devs weren't jumping on this whole hog.
The agile manifesto is pretty short and describes basically the opposite of “Agile” used today.
> 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.
One way to look at it: did you ever see a place explicitly following the manifesto successfully ?
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 agree with you, but I read this as: > No process and tools > No / limited documentation > No RACI or alignment (yay, kumbaya) > No plan or managed dependencies
I'm not saying this is the outcome of an Agile approach, but sure seems common on the Scrum projects I work on.
Agile processes are agile the same way the Democratic People’s Republic of Korea is a democracy.
Holy shit, this is the best way to describe it. I mean, just that we have Scrum “ceremonies” should be an indication that it’s the opposite of what it says it is.
And it makes waterfall look nice. Evidently manifesto writing is harder than the author(s) thought it would be.
"Waterfall" is pretty well conceived, to be fair. It only gets a bad rap because people stop reading after the first paragraph.
The following paragraphs, what everyone misses, essentially say "but that is not enough, you also need..."
Agile is not supposed to make development faster. The core element of being agile (small "a") is to avoid doing work that results in features that are hardly used, not needed, etc. In lean terminology this is called eliminating waste in a process.
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.
Agile was meant to be "agile in change", not following tickets blindly. It was meant to foster collaboration between people rather than putting every detail in tickets by whatever manager/PM. So people know why they are doing stuff, and can make change accordingly. Agile was meant for making things that people actually use. Not about how many features were developed in last sprint.
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've had good tickets where things were laid out like 1) here's the golden path, 2) here's where I want you to put everything, 3) here's how we handle expected errors, 4) here's all of the interactions the user should be able to do
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 "bad" tickets is where you actually bring value though.
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.
>JIRA sucks.
i used to think the same until i had to use azure devops.
i legitimately miss JIRA nowadays.
Just because you found something worse it doesn't mean the first thing doesn't suck.
CVS isn't good because Visual Source Safe exists.
One issue is that many many ticket management solutions suck a lot more that JIRA.
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.
Maybe you end up using fossil?
Fossil sucks in its own specific ways, that are different from git's, but still exist.
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?
i mean, i never said jira was good. i said that it was not as bad as azdo.
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.
I used to think JIRA sucked until my company migrated to ClickUp. In general most of the tools can be made to be usable if a tech lead or engineering manager can tweak them to what a team actually needs. Usually they are left in the hands of TPMs or Scrum Masters who generally make the whole process too heavyweight and complicated.
> Usually they are left in the hands of TPMs or Scrum Masters who generally make the whole process too heavyweight and complicated.
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.
Yes, ClickUp was the worst I’ve used out of Pivotal Tracker, Trello, Wrike, Jira, Excel, Notion Calvinball, threatening emails, or text files
> Notion Calvinball
You got me looking, but this doesn't seem to exist. I kinda want to see a Calvinball issue tracker now.
What would y’all say are their best features? The must haves done right?
Our team used Redmine from a decade ago, but people like all the pretty ways to drag items between columns or something
oh wow, redmine!
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).
ADO is not worse than JIRA... it's just a different kind of worse.
Having been inflicted with both, I agree that if I have to choose between the two, Jira is the lesser evil. Azure devops makes almost anything else look great by comparison.
JIRA sucks, and amazingly there are products out there that suck _even more_.
Same, now that I'm forced to use Monday. Jira was so feature rich and power-user-friendly in comparison.
I just want an issue tracker with a customizable sate machine to transition status.
JIRA is a form of Stockholm syndrome. Your life truly sucks if you think that makes it better. Some of the least agile places I've worked in used it (over-used it really). To be more agile, ironically.
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.
>JIRA sucks That's what I thought until I started a job that has Asana. It's even worse.
I'm being forced to use Linear right now and I keep asking for things I used to be able to do in Jira and it seems like the answer is just "you can't"
Big fan of [lower-case] agile. If its goal isn't to make development faster (by eliminating wasted effort), what is the goal?
The goal is fine-grained alignment with your customers or stakeholders. In the long-run this should make product development more effective, though it's probably not going to be the fastest way to accomplish any individual task.
Unconfigured JIRA which the vast majority of JIRA users are subjected to sucks.
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.
Over-configured Jira is so much worse because it only gets slower the more configuration happens and some sorts of managers love top-down micro-management and force wild workflows that make no sense other than for wasting time on red tape.
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.
Less waste literally means making things faster. See the problem with agile? All the jargon and stories that the agile tribesman like to build upon simple things.
Less waste means less waste.
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.
In software development, time is the wood we carve stuff out of.
But the waste in software development is time/labor, not wood.
we can spin the semantics how much we want, but if you ask 100 managers what they mean with "agile" is "do things faster".
I guess define "faster". If it means getting to product/market fit earlier, agile is your guy. And that could mean eliminating waste so much that it's just 2 devs hacking on an mvp, testing it with real users every few days / week, adjusting the mvp to solve the users problems better each time, with 0 distractions.
If it means delivering features faster, whatever they are, to make an executive feel better, agile will not help you.
Not really. Less waste means not spending time on non-essential features. That doesn't mean that the core features people are focused on will go any faster at all.
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.
Agile isn't agile when it becomes a proscribed methodology complete with tooling as it violates the final point of the Agile Manifesto:
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.
Yep. The issue has never been "Agile" the issue has always been a desire for command and control, leading to a bunch of "sounds good" ideas with lots of side effects.
There's no scope creep with agile, only responding to feedback.
I don't mean this in a snarky way, more just to inform: proscribed actually means forbidden unlike the word prescribed, which means recommended.
I wanted to leave this comment, but now I’m going to have to leave a helpful correction to your comment instead: prescribed is closer to “forced”, or “made the rule”, than to “recommended”. :)
TBF, while the Agile Manifesto really truck a cord, it wasn't saying anything concrete (talk to each other, collaborate, be flexible, react to reality etc.), that of course by design.
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.
> it wasn't saying anything concrete (talk to each other, collaborate, be flexible, react to reality etc.)
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.
That's an interesting perspective. I'm not entirely sure you're right, but I feel you're not wrong! I've going to have to chew on this one.
There are two methodology that are both called "Agile". They are very different, even opposite to each other.
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.
I really don't get the Jira hate. I need a place to read about the problem/project, comment/question it and know what work was completed and what remains to be done, which it all does well enough. It also integrates directly with GitHub.
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!)
My hate for it is based on their UI. Lots of clicks, lots of panes opening everywhere. Scrolling to see everything, having to expand various thigns to see all fields. Navigating to new tickets sometimes takes you full-page, sometimes open yet another panel. And it all is slooooowwwwwww.
You can make Jira functional for the team. But you can't make the UX performant.
I also don’t get the hate. My theory is that, because it is often self-hosted on-prem, some orgs under-provision the hosting and end up with a really sluggish instance, but at the companies that I’ve worked at it has always been quick. Maybe someone here can confirm or refute that theory?
I've had to use Jira Cloud, hosted by Atlassian themselves and presumably meant to be their hosting showcase, and it still chugs and is sluggish once "configured" for a large enough team or the whims of enough managers above that team. That Inner Platform Effect of Jira's weird scripting languages and SQL-like-but-not-exactly SQL filters provides a lot of room for management to slow everything down on every page forever.
Talk to people who have admin'd it instead of just users and you will understand very quickly there are a host of issues. Even with tons of hardware the software is just bloated and slow (tons of reports of "I threw a big system at it and payed for on-prem and it's still slow as cold molasses), the backend/api is atrocious, the tooling isn't foss (who customizes versioning?!), migration is another level of PITA, etc, etc, et al
> I guess if GH had its own version that would be slightly easier.
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.
JIRA is a little overbuilt and overconfigurable, and I think that leads to it often being used in confusing ways. I don’t think it’s a bad product or anything, but my experiences on teams that use something simpler like Linear because the tool kind of guides you toward sane behaviors instead of letting you go nuts.
Kind of a convention over configuration thing.
My biggest gripes are mostly Atlassian's fault, in that their products seem to take AGES to load (wasting my time) while also providing a UX that seems designed to force as many page loads as possible (wasting even MORE of my time). They keep hiring product people from the Marquis de Sade School of User Interface Design, and it shows.
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.
Yeah Jira is just a ticket tracking system. Everything to do with the fields that need to be filled in, the workflow steps you need to move tickets through, and the granularity of tickets are entirely an organization specific thing.
My theory is eventually every ticket tracking system converges to the same bloated thing which is a completely customizable slow mess because every company and every team within every company wants something slightly different. The developer adds all these features and then the team running the product at each company customizes it to meet all their internal feature requests.
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.
It has become a fashionable thing to hate. I don't really like it but I don't really like any ticket tracking system. It's just meh
0. It takes too much effort to create and manage tickets. There are too many things to click, too many fields too fill, and half of them should be auto-filled.
1. Manager types think JIRA is a solution to getting shit done when the real problem is bad communication and politics.
Mandatory fields should be banned. If it's actually important it'll get filled in anyway.
At some point, I need to learn what Jira is exactly. I only used it once, at an org, for a couple of years. It tracked tasks and bugs and such, and integrated with the source control. It seemed… fine?
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?
I actually kind of like the subset of Jira that I use. Put tickets in a project, create related tickets when I'm breaking down larger projects, expose the project as a Kanban board so we can see at a glance if the right things are being worked 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
JIRA is a management tool with an enormous amount of configurability and absolutely no opinion on how thing should be done.
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.
It's not particularly agile. It's just another tool. If you just use it for bug tracking, it's fine. At least, for a small team. But when a manager starts using all the other features (progress tracking, time administration), it may become your enemy.
I am under the impression that Jira is a really poorly designed text editor, with the addition of boxes that can be dragged around to serve as a fidget toy for those who have nothing better to do.
I think most of these solutions are "fine" for their stated goals, but the problem is that bookkeeping is tedious. And that's what Jira (or insert ticket system of your choice here) exposes, the tediousness of the task of keeping proper book of your work.
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.
I've said before but I'll repeat:
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 not dying a slow, painful death. It's won. Iterative development is the order of the day in software.
Agile is an iterative methodology, but all iterative methodologies are not agile.
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.
Well yes, because there's also a product development side to the original vision.
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."
grammar nerd sidebar:
> 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...
It's agile only in name, far from the agile manifesto. But yes, it seems to be the most prevalent methodology and it doesn't appear to be dying..
"Agile" is not a methodology, it is a collection of techniques and methodologies which have similar characteristics. The people who signed the Agile Manifesto all had their own frameworks (including Scrum); they just were trying to find out what they had in common.
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.
It's easier to say X is dying when X is easy to define.
Iterative development is Royce's "Waterfall" model. It long predates Agile.
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.
> Agile is about eliminating management in favour of self-organizing teams.
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.
> not feasible in the majority of cases.
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?
> The Twelve Principles makes it very clear that you need extra special people to have any chance.
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.
Again, Agile has no specific leadership. It is a model, for lack of a better word, for self-organizing teams where all participants are the same as all others. It is lead by the shared collective of all taking part. That's its while deal.
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.
Jira isnt agile. IS just bloeatware.
If you need more than a board, and maybe some notifications, you are doing it wrong.
I appreciate how you added an extra letter to "bloat". It's like visual onomatopoeia.
I love the idea of agile. And I've tried to apply the principles to hundreds and hundreds of projects.
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 just don't think agile is designed for fixed-anything. Every project has unknowns: you can either spend effort to de-risk the project and increase your confidence in the time/cost estimates, then sell the job (ie waterfall/big plan first); or you can Just Try Stuff and adapt as you figure out that various things are easier or harder than you thought.
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
Sounds like your clients know what they are doing. That’s very nice way of working. I was involved as employee in countless dubious agile called projects. It’s good way to hide missing project management covering it with dubious rituals like daily standup. That’s exactly what happens in kindergarten and is called morning circle. I must smile thinking adults doing the same in the office.
Basically that's exactly the problem, a serious lack of leadership in nearly every organization. Very little adult behaviour.
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 hate labelled methodologies like "agile" and "waterfall". Manager types routinely think that they're going to change the world by being "agile".
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.
Most shops are doing (theoretically) agile, and specifically scrum.
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.
Unpopular take: Agile was effective at the beginning, before it turned into a certification/rubberstamping goldmine and became so complicated that any efficiency gains evaporated when faced with the amount of ceremony.
These days you don’t really need specific tooling—nor should you rely on it to rate features and keep track of meaningful work.
> The World Doesn’t Need More Features
Whereas a PM's job is all about that. We have bloated products. Mostly. Feature packed with FOMO. Incoherent. Inconsistent. Incompatible. But features.
Exactly. PMs motto seems to be: You will have more features and you _will_ like it!
Coincidentally it seems the reason Jira is a mess is that it has too many PMs chasing too many 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.
Unfortunately, words often lose their meaning. For example, Democracy. As in the "Deutsche Demokratische Republik", or East Germany as it was. You can put any name on anything. You can call a tyranny democracy. Does that mean Democracy is bad, or does it just mean some people either don't understand it. Democracy is a system of interaction. Agile is a system of interaction. And one could say that Jira is to Agile as the GDR was to democracy. It is designed to sell, right?
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?
It's not agile... it's Scrum and Jira.
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.... :-)
Link that does not require Medium account: https://archive.is/NYtYD
> The World Doesn’t Need More Features
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.
defend your existence! hundreds of hours have been pumped into this framework so ... yeah. something has got to give. can bad be replaced with a lesser bad?! why not take the hit, eat the loss, and uturn to good, perhaps ...
Jira is dying? Hope it is a slow and painful death!
Well.. actually, it doesn't needs to be slow.
RIP both.
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.
I'm writing this while sitting in a "sprint demo", mobilizing the entire dev team, wasting time and money over 2 hours to demo a bunch of small features with no tangible ROI.
Move it to EOD Friday and make it optional. Tune will change! However, these meetings can be helpful every so many months.
I find it strange how there's been so much digital ink spilled over agile and Jira, yet they keep being used everywhere. The author talks about how folks he "routinely interfaces with, including upper management on both the business and tech side, at startups and Fortune 500 companies alike, are done or close-to-done with Agile", but I'll believe that when I see it.
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.
In the 1990s, I was working on eCommerce and was sent to our factory in another state for a week to understand that side of the needs, then a few days at a customers place of business in another state. This was a government contractor. Understanding the whole process was important even in that industry at that time.
>Understanding the whole process was important even in that industry at that time.
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.
Agree. People now might think a 5 minute call is a deep dive. Haha.
Agile peaked with Extreme Programming and paper story cards, since then all that seems to have happened is the adoption of more tools/process that missed the whole point of it. The most productive project I ever worked on followed that method - but it's very hard to scale up.
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.
I'm also a fan of XP, but it really wants everyone to be in the same room.
JIRA escalates quickly. You're smart to put things in place to prevent that.
XP says that cards are tokens/mementos of conversations. That's the problem with Jira - the conversations didn't happen. All you have is electronic versions of the cards, but what made the cards useful is missing.
"Agile Ceremonies Bible: the decline of the Church of Agile", this will be the tile of my next book.
Who in their right sane mine would use a product like Jira with its bad UI?
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 miss FogBugz.
Although Jira is mentioned in the title, it's never really discussed.
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.
Non paywall link https://www.freedium.cfd/https://ehandbook.com/the-slow-pain...
I've heard Sr. Architects call Agile "formalized micromanagement."
Given self-management was an intent of Agile [0], an apt quote is "We have met the enemy and he is us." [1]
0. https://www.scrum.org/resources/blog/scrum-team-self-managin...
1. https://www.thisdayinquotes.com/2022/04/we-have-met-the-enem...
Somewhat related website: "Real opinions from real people about a project management system which unfortunately is also real"
Jira and the modern cargo cult agile make me hate software development.
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.
Meh, I get people hate Jira, but every time I ask people "What would you rather do instead" there's absolutely no agreement on what's a better solution.
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 hate that we eat a bowl of feces every day, can we switch to something else?
"I want steak!"
"I want salad!"
"I want fish!"
"Alright, well, there's absolutely no agreement, let's stick with the feces."
I feel like maybe you're intentionally misunderstanding the point I'm making, because your example kind of illustrates my point:
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 once worked with a surly backend developer at a company where for whatever reason the relationship between front and backend was quite poor. One day we were sitting in a long boring meeting and this guy told a story about how his children learned to talk with one another in preschool. The point was we had failed to achieve what the toddlers had, and this comment garnered a big round of laughs. Later on I filed a bug ticket with backend that was legit and this same developer acknowledged it as such. Then what happened was he and the other backend devs made the endpoint completely non-functional, removing even the workaround I had been using. The ticket stayed in limbo until they got back to me and basically said they could return it to its original buggy state or "explore" the matter further. Not keen on more passive aggressive shenanigans I said just return it back to original form. All this to say that.. making a fun joke that obscures the actual complexity of the problem is a sure way to score points with thoughtless buffoons, but it doesn't mean you aren't a hypocritical jerk and that you're mostly wrong.
Same point I'm trying to make, but you _absolutely_ win on effect. Well put!
Best comment of 2024, maybe even 2025 just on trust.
Don't give me that sort of trust, I'm sure I'll find some way to milkshake duck myself.
This is a defeatist attitude. There are plenty of jira alternatives that have fewer problems. There are obvious problems with jira that have gone unaddressed for years. For instance performance is horrendous. I would also remove infinite customization. It’s a sales pitch to executives but doesn’t benefit line managers or people working on tickets.
For my money Linear is just about perfect.
I think Jira is in there just because it is the most used tool. Pick and choose any other tool, if the mindset with the new tool is the same, then we are in the same spot. The point is that all the prescribed rules pushed down the throat of developers. (e.g. You must have a daily stand up. You must have a story that is no bigger than x Points, you must NEVER roll in our out stories into a sprint once it starts.. and the list goes on and on..The rules - no matter how "small" they are, they are still a big barrier to being agile in the truth sense of the word. The above are only my observation and my thouhgts, your mile may vary.
How about "figure out different solutions that work better for different teams instead of force-fitting everything from three-person startups to enterprise organizations into the same straitjacket of a framework"?
I think you just described SOC2, which your dumb-as-fuck customers will insist you do anyway because their even-dumber-than-that customers insist on it.
Do programmers not end up taking any management courses? Because we learned of contingency theory within the first month of the semester when I was in college.
But it indicates that something is really wrong, right? And that we should all keep noticing that and keep working on a solution?
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.
Isn't that the point though? Should there be an alternative we all agree on? All our situations are different. The whole point of being agile was to not take a one-size-fits-all approach to solution development.
Every individual, and on a broader perspective every group, has innate preferences to different forms of organization. It‘s called contingency theory. Agile fails because it was a form of adaptive organization, built out of the highly adaptive/performant cultures of software development, that was never able to be scaled like they tried. In major part because it lost the adaptive aspects in the hard-coded systems, and created unproductive busywork because people were too busy putting something on the board, rather than focusing on work.
They probably hate Jira for the UI/UX or something similar.
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.
I remember MS Project. Those were the days...
I just left a place that had three different tracking tools that devs had to update, with the Azure boards being customized with all kinds of unrelated 9001 process fuckery that necessitated failing to save any update ever until you dug out the field that was missing. The fields changed on each move across the board.
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.
[dead]
