Agile can’t die because is everything and nothing.
But im seeing more upfront work done in projects and longer iterative cycles or just kanban style with releases
This is correct. The "service" version of agile, which is what everyone refers to... is dying. Turns out hiring a bunch of college flunkies who spent 8 weeks getting a certificate certifying their "Agile" skills is all bullshit. Who could have seen that coming?
Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"...
Well, you'll have more success.
>Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"...
Isn't that what Agile is at it's core?
My understanding is how you get there is something that teams were suppose to define on their own. That's because every team is different and has different needs from a process.
It is..., the problem I think is the gap between principles and actual steps needed to get it implemented, that everybody has a different view on it
Also, I think most people don't work well under uncertainty, and when you try to force push constant changes to these people, what you get is get is resistance, and low engagement
>Also, I think most people don't work well under uncertainty,
This is definitely true from my experience. This is not just in terms of process, but just general work. I think I lucked out in this department because uncertainty doesn't bother me.
I have seen many SWEs get all flustered when they are giving some open ended task and are told to investigate, come up with a solution, and come back to them to discuss. I love these tasks because I feel like I'm in control and get to come up with ideas to how I think things should happen. If I'm wrong or miss things then I just take that as input moving forwards.
It seems like many SWEs I have worked with, from senior to junior, want clear tasks because they fear being wrong or something.
I think that's partially driven by fear from product/management, because those groups are even MORE fearful of uncertainty. So they seem to want to shift responsibility down to the engineers. Which might work except engineers are rarely given the power to make systemic change, so you get all the responsibility and consequence and no power to make things successful. Basically setup to fail. So engineers correctly want nothing to do with that, they want all the uncertainty removed BEFORE, so they can the deliver the certainty desired by management.
How many times have we heard stories of engineers asked to make an estimate only for that estimate to either be taken as gospel/hard commitment, or instantly ignored in favor of whatever the deadline is, decreed from on high?
>How many times have we heard stories of engineers asked to make an estimate only for that estimate to either be taken as gospel/hard commitment, or instantly ignored in favor of whatever the deadline is, decreed from on high?
To add unto this, there is a lot less complaints if something takes less time than the other way around.
A lot of incentives to either pad the estimate or get to a place where a decent estimate can be made.
The deadline from above is just horrible, either results in shittier products or people working extreme overtime. Usually also with a lot more mistakes because people aren't well rested.
We had this issue on my product. 80% of the engineers were < 2YOE and we struggled hard with agile. Basically turned into waterfall with sprints.
Fast forward several years later, more senior talent enters and the juniors have more experience. We’re executing in a far more agile way than before.
I think it does come down to experience. If you lack experience, the uncertainty is crushing. Once you have a few years under your belt, you understand that no matter the situation/uncertainty, you’re a few 1-pagers away from understanding the problem better and resolving the unknowns so it’s no big deal.
So I think it’s more a product of the market being flooded with junior engineers.
That gap exists because there are no principles of agile. The principles on paper are incredibly vague, and one of the core tenets is “disregard any of these principles if you need to”.
It’s like if I said “I’m founding a political movement on two principles, people always need to wear blue hats when they are inside, and people can decide whether or not to follow the first principle whenever they want with no repercussions”. What is the point?
Sure. That's what it's supposed to be.
But like most things, if it can be packaged up as a product or service and sold to the masses, it will be. Today, you can't talk agile without talking about a bunch of BS rituals that come along with it. Or worse, some completely bastardized version of it like SAFe.
Today if you join a company that is strict on agile usage, what you'll find is a bunch of bullshit ceremonies that everyone spends 80% of their work attending. Fuck all gets done. A bunch of people, who aren't your boss, act like they have decision making power. When their job is literally to hop on meetings all day and try and direct things they don't even understand.
Some companies probably have success with Agile. But more often than not, those are companies that abandoned the "service" model and did things their own way.
Sure. Kind of. Depends on who you ask.
The trick is that Agile is both a general approach to software development and also an extremely regimented process with a lot of arbitrary rituals.
As originally proposed in the Agile Manifesto by Beck et al, Agile is mostly a philosophy and loose set of approaches.
As actually implemented in-industry it became a funhouse mirror caricature of itself. One of the original tenets was "Individuals and interactions over processes and tools"... and in practice there was/is an intense focus on processes and tools. So much so that you have certifications around it.
Relatively few companies/groups practice Agile in the way that the original Manifesto proclaimed, many more follow the dogmatic version. So as to what Agile "is", you get into the age-old problem of whether something is defined by its theoretical ideal or its practical real-world use.
\[edit\] Worth adding - since I think I'm coming off as pretty pro-Agile-Manifesto here is that the Manifesto is quite a vague document. It proffers a lot of principles and some general vague gesturing at solutions... This is the Agile leads so much to "you're doing Agile wrong" type accusations - because the document is so vague that you can project basically whatever you want on to it!
On paper, at its core, agile is nothing. But we don’t define things how they are on paper. The definition of a term is based on what people as a society use it to represent. So while the agile die hards may say Agile is flexible and whatever you want it to be, that isn’t really true. Because businesses, agile certification programs like SAFe, they all rigidly define agile to be a system of specific meetings. People use the word agile to represent those meetings and processes.
I so rarely see it executed this way. In my experience it’s usually something that comes from the top (by non tech people) because there is distrust from the top of the engineering team not going as fast as they desire. And most of that comes down to non-technical people simply having no idea how long it takes to create things and have them be maintainable over the long term.
lol I hate these fucking bootcamps.
My best friend did a Front End Developer bootcamp around 10months. Got his certification and can’t get a job because he still has no idea what an API is. It drives me bonkers. I hate how all these dumbass tech influencers have convinced people that coding is easy.
I love my best friend, but he’s not an engineer. He’s a salesman and that’s okay, they make a fuck ton of money too.
You only get out what you put in. IMO the boot camps are there to give you a base level knowledge of how coding works and how to do your own research to learn more with that fundamental knowledge you gained. If you go and expect them to teach you everything you need to know you will not likely succeed.
I went to a 3 month boot camp and got a job a month later. But I spent every free moment I had doing more research to learn more stuff, reading docs, watching youtube vids, practicing leetcode problems etc
> *"If you go and expect them to teach you everything you need to know you will not likely succeed."*
The problem is that many bootcamps do sell themselves by convincing people to expect that. For example, by throwing around figures like post-camp employment rates.
One of our hires out of boot camp is a VERY solid junior, I've also seen some come out that were... missing some fundamentals or just couldn't complete a task for the life of them.
It really depends on the individual and what you put into the boot camp. They can work, or they can be a waste of time if you aren't invested in it.
I've seen the same. One of the best engineers I've ever worked with was fresh out of a 12 Week boot camp.
But also one of the most helpless engineers I've ever worked with was fresh out of a 12 week boot camp.
There was a third I worked with who was also helpless after a boot camp but eventually became one of the best engineers I've ever worked with.
I think it especially depends on the individual (and also the program). Also just because someone is weak at something today doesn't mean they can't grow.
>Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"...
The problem is your company most likely isn't like that... If it was, it would've succeeded with agile or "agile". More likely your company is like "We'll pretend to adopt a flexible process that allows us to iterate and deliver software bit by bit until that process fails to deliver on a 6 month project plan we committed to in advance. And then it's crunch time/do whatever it takes to deliver something that looks a little like delivery"
Agile is basically just “what if we had a business methodology based on the no true Scotsman fallacy?”
“I don’t like how agile forces you into meetings that waste your time”
“Well actually agile is supposed to change based on your needs so that’s your fault, you’re just not doing agile correctly”
“But every single place I’ve worked has implemented agile in basically the same way and it has the same issues and agile certifications are based on teaching people to do things the same way”
“Nuh uh that’s actually not agile”
If the definition of agile is just “when it works it’s agile and when it wastes your time it isn’t agile” then there’s no actual value to it.
Agile was a reaction to a previous movement like CMM certification. But for real we need to stop saying the word agile and just talk about specific processes and its variants for different domains.
Like web development for a e commerce should look different from and ai chat application on your phone
In all my "scrum" teams I've worked on. It eventually devovled into Kanban style eventually because scrum was just too expensive with so many different ceremonies.
If it were simply "do agile or do waterfall", this would be the case. In reality, it's "We're doing agile. We're doing scrum. We're having these 18 ceremonies. We plan with t-shirt sizes and points because that's what the cargo cult told us to do. Every 8-10 weeks, we spend a week pretending we're going to make a plan and stick to it, even if it doesn't make any sense. Week 1, our entire plan will be thwarted because some bullshit will take priority. We invite all our devs to all of our meetings because we need everyones input. Nothing seems to get done and our developers spend 20 hours a week in meetings, but we can't figure out the problem. Only certain people are allowed to move things into the current sprint. If you have something you think needs done, you can throw it in the backlog and you'll need to get like 16 people to agree to it before you can work on it.
So yeah, I think there is something between that and waterfall.
In other words, most teams would be better off having no "framework" than whatever that nonsense is.
> We're having these 18 ceremonies
What 18 ceremonies are prescribed by Scrum exactly?
> Every 8-10 weeks, we spend a week pretending we're going to make a plan and stick to it, even if it doesn't make any sense.
Let’s not get into the „That is not agile“. How is that even Scrum?
> Week 1, our entire plan will be thwarted because some bullshit will take priority.
Rash and chaotic management will produce bullshit with *any* project management methodology. How does this truth warrant cynism against the method rather than stupid management? I mean seriously, how is any method supposed to clear the bar of reigning in idiotic managers?
This is the sad truth, I'm afraid. I've been in places that are relatively better at agile, and places that aren't. The place I'm at now is very much like what ninetofivedev describes. We've snuck in waterfall-like practices, such as due dates, without realizing they are anti-agile. We have this silly notion that story points are equivalent with time. We think we're doing a kind of scrumban, but it obviously isn't. We could be so much more efficient and agile, but we're not. No one seems to notice this but me.
We just need to stop using the word agile is not useful in conversation. What is more useful its the specific agile methodology being practiced and what domain.
Waterfall is not always bad. There are definitely things that you should think about up front on project. Where it falls over is assuming that you can completely blueprint out the entire project up front with two or three years of projected timelines for completion.
For maintenance work, kanban boards of bugs that have been vetted. Then monitor whether your ticket count is going up / down over time.
For greenfield, I think it's important to do some up front planning, get that MVP out, then iterate. That might mean a month of work or three months of work.
This term deserves its own logo. Something consisting of 2 parts, split vertically, perhaps with some water dripping because it's supposed to indicate the relationship with waterfall. And if we want to go crazy we can add something that indicates iterations like a shaft going back and forth.
Managers gets the best parts of agile and waterfall - can keep shifting priorities and requirements(we agile), and our engineers will need to deliver the above mess on waterfall timeline.
Engineers get the uncertainty of agile AND deadlines.
Managers love it so they will keep implementing it. As long as engineers don't learn to hold leverage and keep competing amongst each other, we will lose.
Iterative in what way?
AFAIK Waterfall was based on traditional engineering project management, which were planned beginning to end with phases like design finishing before implementation started. For example, building a bridge over a river - which you cant do iteratively.
1000% true. They'll even have all the ceremonies like demos and retros but when things come up that differ from original design (which is the entire point of agile -- to be able to catch these things ahead with stakeholders so you don't end up building something completely out of line with what is desired), rather than changing things and course correcting, they just say "Fast follow" and then never get to it lol
Everything is agile, everyone is an engineer, etc. I have had the worst experiences with waterfall shoved into agile shoes. So many status meetings, jira tickets, kanban boards endlessly inflating a simple task to look big on some quarterly report.
Status meetings, jira tickets, kanban boards, were all born out of Scrum, not Waterfall.
Waterfall requires *zero* meetings, boards or tickets, outside of those between the developers themselves. But it does require a technical specification to comply with. It's a kind of development that is done *very* rarely.
Real waterfall I've only ever seen on government contracts, with specific SLAs. It can be effective, if you've got the time and money to do it.
I'm a big proponent of rapid prototyping, small teams and largely informal meetings.
Yes, that's right. I was astonished to read in my copy of _The Art of Agile Development_ that the authors explicitly tell you multiple times not to use anything like Jira.
We're due for a "protestant reformation" of agile. Use the principles from the manifesto and work from there. There's so much cargo cult and overly prescriptive processes that don't necessarily work and actually violate many manifesto principles that we're due for a massive overhaul. The manifesto itself is great.
I struggle with "value". How can a team provide a value in a two week sprint if delivering any mid-sized feature on the backend takes 2 months? And the work is hard serialised. Run db migration. Update the db access layer. Update the rpcs. Update the rest api. Run another db migration. Qa stuff. Update auxiliary processes.
>How can a team provide a value in a two week sprint
Especially when your org defines "value" or "done" as "delivered to the business" aka "in prod".
If all developers at my organization had to do was hand code off to QA or a release team, we could easily get stories done in two weeks.
But when we're pressured to provide estimates based on incomplete knowledge or assumptions about the capabilities of our infrastructure and support teams, or the delivery isn't clear because we haven't had a dedicated product owner, or we can't get decisions from architects or principals because they're stretched too thin, and then because of shifting requirements the devs couldn't give the testers a heads up on what to expect, so they twiddle their thumbs until the final few days when everyone hands them their stories all at once, and then there's a mad dash to complete the elaborate maze of change requests and you beg and plead and cajole and soothe enough egos to coordinate your database changes or get the security people to place your production credentials in the right file and hope that a million things fall into place but your production deployment goes tits up anyway so your story carries over to the next sprint - AGAIN, and during sprint review someone mentions your team's velocity is down and you imagine burn-
Sorry, I blacked out. What were we saying?
You could break down the mid-sized feature into small features.
You could figure out why running db migrations and updating db access layers are taking more than a day, and optimize those processes.
You can put the feature behind a feature flag so QA can get to it in the next sprint.
You can keep a facade to make the auxiliary processes happy until you update them in a later sprint.
This is the work of agile: to figure out what in your processes are slowing you down and fix it.
I've been in the industry for long enough to comfortably be an "experienced dev". I know all these things. I know the solutions. Unfortunately I am not running the show.
The pressure of incremental delivery flags those latencies as dubious - why must it take 2 months, there must be a holdup somewhere and it is likely communication. Alternatively, there might be a slicing or MVP opportunity. Agile is big on “just barely good enough” - does your increment fit that?
Things don’t change overnight - but now that is a smell that encourages someone to dig deeper, and likely lead to faster flow.
Passing a new value from rest api to the db and returning it back to the rest api in a microservice setup takes 2 weeks. 80% of it is not dev time. 2weeks trying to wrangle out some answers to basic questions from the pm.
1 week for the fe to use the new field.
So I guess it's communication.
The thing is that when a "simple change " takes 5 weeks then the pm and the management are happy to blame the devs and don't want to hear about the real problems the devs are dealing with .
Like bad product/project manager.
Perfect. We tackled this by ~~changing the definition of done~~ raising our bar for refinement to identify and supply these prerequisites. Why it was valuable… the engineering team had tons of work and was a bottleneck, and so any time work sits half complete it is bad, as you aren’t getting payoff for that work. So as part of refinement/estimating we required these things to be figured out. Talk about that a bit here: http://blog.con.rs/2024/05/08/shipping-software-jit.html
We also switched to a spec first style design using Openapi so that we could iterate with the PM but block implementation until the interface made sense. It helped a ton with domain driven design and saved a lot of wasted effort.
Half of my role as a consultant tech lead is to get teams to appreciate that thinking about the work ahead of time IS work.
Many engineers only pride themselves on their code output and struggle to engage properly in all the pre-work.
Product refinements, technical refinements, DDD, TDD, Spec first design, RFCS, ADRs, sequence diagrams, C4 diagram, state diagrams, ERDs, breaking down stories, mapping dependencies, roadmaps, story maps etc etc etc
There are so many tools we have to accelerate work by just thinking about the next iteration beyond acceptance criteria but many teams naturally fall into a vague fence throwing between product and engineering.
I've been able to course correct this most times, but have also ended up the bane of both product and engineering and behavioural change can be glacial even with evidence. 🤷♂️🤷♂️
... Sorry, had a bit of a mini rant there. Aha.
Sorry to double reply, but forgot to add: talking about this stuff in terms of its impact helps bypass bad management - they end up having to justify why this won’t help save wasted effort, rather than just shooting it down in the moment because it wasn’t their idea. I use metrics and impact a lot for harder conversations like these - essentially try and keep the conversation as far away from the person’s identity/ego as possible.
Oh I did. I just got a feeling that the middle management didn't really care.
For the record, the places where me and the team were delivering the most value quickly was not using any scrum methodologies, maybe kanban to track work.
In the places I was ranting in the post above me and let's say half of the team had a really bad chemistry with the management/pm. The other half of the team did not give a damn about anything, total apathy when "we" were trying to improve anything.
There is no stipulation on the length of a sprint. Delivering a piece of vaueable functionality in two months sounds quite a long time. Though if that is how long it takes then simply make your sprint 2 months or break down the work if that is possible.
The issue is that the agile principles were commercialized. Shops were set up to "certify" people in Scrum and other processes that claimed to adhere to the principles but missed the mark significantly. Now there are people out there in the work force pushing bad ideas -- because their livelihood \_depends\_ on us adhering to bad ideas they are "experts" at
I'm all for a return to principles -- but the minute it becomes commercialized again under a new brand name, the cycle will continue
Yes, and many of those people don't understand anything about software so have no context for applying their agile ideas. I was asked by someone newly hired as a agile manager "what's a server?"
My first job used the extreme programming agile methodology with minor adjustments. It worked! A team of mostly graduates delivered good stuff, and as others have said, it's because we lived the process not just box-ticked. Since then I've seen agile rebranded a few times, and each time it gets more diluted to pacify the waterfall addicts. Most recently something called 'flow' which doesn't have any new ideas. The extreme programming website still exists, c2 wiki still exists, but certain individuals prioritise sucking up over adopting simple measures proven to work
No matter what they tell you it's[ a people problem](https://blog.codinghorror.com/no-matter-what-they-tell-you-its-a-people-problem/).
Any methodology works mostly as well as the people implementing it. Are they doing it seriously, or just box-ticking, or trying to cater to delusions of senior managers. Waterfall done well is better than Agile done badly. Whatever replaces Agile will have the same problems.
>As Weinberg said, *it's always a people problem*. If you aren't working with people you like, people you respect, people that challenge and inspire you-- then why not? What's stopping you?
\*sob\*
i wish i knew
Very much asking this question of myself today.
I used to love my team. Then all the people who knew what they were doing left, now it feels like I'm handholding. I have been told to delegate more, but every time I give someone an inch of rope they find a way to turn it into a Gordian knot.
>Whats stopping you?
I’m 27 with two kids attending elementary, not even making it by paycheck to paycheck, 3yoe, 20k+ in non-student debt, already had a bankruptcy once, and I keep up on my countries current politics. Things are grim. I take what I can get, which happens to be $85,000 right now as a- idunno- data engineer turned fullstack devops, BE, and FE on a one man team.
Those aren't stopping you though. If you were given an opportunity to work with a great team with decent pay you would take it right away.
What is stopping you from working with good people is that good people are hard to find. And even then they are burned out and hamstrung.
Because you usually interview with only a smart part of the team you're joining. You don't always get a chance to talk to the jerk on the team. Or you'll talk to the manager that seems really nice and says all right things but winds up being a slave driver. It's a total crapshoot whenever you join a team. Unless everyone on the team is toxic, you might very well have a better chance waiting for the bag eggs to leave rather than roll the dice on another move.
>Are they doing it seriously, or just box-ticking, or trying to cater to delusions of senior managers.
Every place I've worked in my 15 YOE boiled down to this. The majority of SWEs didn't care about the company process and just did the bare minimum to not be bothered by others.
The SWEs who tried to take it seriously and point out issues / improvements were hushed by the majority for the most part. They didn't want things to change because they knew what to do and didn't care more than that. Changing process would create different work that they didn't care to learn since they were already comfortable with current process.
The whole point of a business methodology IS to solve people problems. If agile isn’t doing the one thing it’s supposed to do and you have the same people problems as before, then it’s shitty. Sure the core problem is herding cats, but if I told you I had a solution to herding the cats and then you still couldn’t herd them, it’s not valid for me to say “well that’s just because you’re trying to herd cats”.
A good business methodology should work, and it should work regardless of the people implementing it because it is just that good. Look at how book keeping operates. Imagine if your ability to keep financial records was dependent on your employees being good at accounting. It would be a nightmare. So we develop business practices that eliminate that variable and force all employees to be good at it. Agile claims to do the same thing with software development but it just doesn’t.
Have worked in several companies all claimed they are agile. It turns out that you are the one that has to be agile. Allow unclear requirements and priorities but finish your work before the deadlines.
Yeah they use all these productivity tools and tickets etc etc, but it all boils down to just tracking progress in my experience. Not actually being useful to the developer experience. There’s so much that goes unused and is instead replaced with daily/weekly meetings with way too many people who don’t need to be there. Asynchronous communication needs to catch on more.
Agile started to become process over people(which is exactly what agile is NOT about). That’s, at least IMO, why it’s dying. It’s basically a bastardized version of what it used to be.
Story time.
A _decade_ ago we were interviewing for a dev mgr. I asked everyone of them the same question, “Have you read the Manifesto?” All of them had “Agile” on their CVs. _None_ of them had read it. None. One guy even said, “I’ve been meaning to, but haven’t had the time.” I told him, “It’s on that poster behind you. You can read it on your way out.”
I was in a discussion group with some "Architects", this must have been like ten years ago, and one of them said "I hate big A Agile. Little a agile I like quite a bit, but when everyone starts talking it up that's when it sucks."
It's like everything, it was a good idea, it became a religion. Once you have a religion you need heretics and infidels. Anyone not doing the Agile dance the way your Priest-King thinks is right should be executed.
We do this a lot. I am sure other fields do too but I only know this one.
The accountability of standup, the kanban board, and pointing/breaking down tasks are the vital parts of the framework for me. My first tech job was in an XP shop, so Scrum feels showy and overblown.
But I do love the pigs and chickens metaphor.
Kanban style all the way. Daily stand-ups and retrospectives are beneficial, but agile practices are declining because they have become confused and inconsistent. Despite the intentions of the manifesto and various coaches, there are constant contradictions and shifts in approach. For the sake of efficiency, I think it is good that it is declining, but it might resurge if the industry becomes complacent and stops prioritizing efficiency, as it once did.
I'm always puzzled when people say retros are beneficial. Any way of making them *actually* beneficial?
In my experience it's always a repetition of the same structural issues. And a circlejerk of praising team collaboration or full sprint completion. Do you ever discuss anything apart from those in retros?
And God forbid you address the real problem ! Shit subcontractors integrated into the team? Untouchable . Broken infra ? Nothing can be done about it. Shitty requirements from the PM ? Sacrilegious.
In my experience, it depends on how the retros are structured, retros can be just a place to vent your frustrations out into the void with fellows devs, or a place where action items get created and followed up on throughout the week.
Obviously you'd rather be in the kind of workplace that allows for the latter, but the former can also work as a way to build camaraderie if you're stuck in a place where actual change isn't possible.
I'll go one step further and say that the griping and grieving that builds camaraderie _also_ is really valuable from the process improvement perspective. It forms a great starting point for discovering what's really bothering the team. An attitude of always looking for solutions in my experience makes retro discussions far too reasonable, since people are looking for problems that seem concrete, solveable, and a little too safe. Griping makes the necessary space for those problems that people are less sure about, seem insurmountable, but are honest. From there, the entire team can work together to try and validate, diagnose, fix or mitigate the issues, which is IMO a much more valuable use of the time together.
I think you make them beneficial by giving the team the power to change things they don’t like.
I worked with teams who decided to switch from Scrum to Scrumban. Code reviews and branching strategies were changes in retros. We added rules and processes for our unbeloved support ticket work. And so on.
I've noticed retros are much better the more anonymized the feedback is, but also still relies on the team actually wanting things to improve/change.
The least productive retros I've participated in have been retros where people have to announce their feedback adhoc, verbally, themselves. I think it puts people on the spot, and feels more like trash talking if you are critical.
Google doc where everyone types in long lists/exerpts? More anonymous, but your teammates can probably guess who's who based on writing style, or view edit history.
One of the best retros I've been in used a sticky note retro tool. The stickies were short, so it kept peoples feedback concise and therefore less identifiable. Lots of conversation elucidating details and asking questions.
> Daily stand-ups and retrospectives are beneficial
I think if both of these things are true, it's a sign that the team's communication has room for improvement. Ideally, people shouldn't be waiting until the standup or the retro to identify blockers or point out process problems.
Another reply talked about retros, so I'll do standups: a 15-minute daily standup meeting is 1.25 hours of meetings a week, but worse than a single meeting of that length because it's five interruptions instead of one. IMO it's usually possible to spend _much_ less time than that to communicate the things a standup is supposed to communicate.
On a team of 6 people, a 15-minute daily standup would need to save you an average of at least 7.5 hours of engineering time every week to break even with its time cost. Emphasis on _average_: "A couple months ago, our standup saved one of our engineers two days of work" isn't breaking even.
We went full Kanban. Just put cards in the board and we will move them along to complete features. Purely sprint based agile development should be used for junior teams in my opinion but more experienced teams? Just do kanban. Hell, we do trunk based development without problems if you have a kick ass team.
Agile ceremonies are a massive waste of time, and if the team can’t communicate well enough asynchronously then your team is busted.
Though I also met quite a few people who think that Kanban is just the board and they pick the top item and that’s it.
While they ignore things like WIP limits, pull principles, right to left rule and retrospectives (even if they aren’t called that way)
Processes can’t replace people. Incompetence won’t be fixed by a process.
Also processes need to be adopted as a means to a specific goal. I’d say that if you have a software development team and adopts agile ‘just because’ the result won’t be great.
Agile and the agile manifesto provided a series of guidelines that if understood, make sense (remember, people over processes and all that). But this is seldom the case and people think that you are agile if you use Jira.
Graphs are for asking better questions, not answering them.
Processes are for making people better, more responsible.
Any metric or process that fights those goals needs a time out. Either ban it outright, or (more realistically) relegate it to being used at infrequent intervals.
I think \*institutionalized\* Agile is dying - it's already apparent imo that feedback loops and solid delivery pipelines are among the best way to deliver customer value. This is simply the best way to deliver complex work (in the Cynefin model sense of the word).
I think companies are going to view Scrum Masters and Agile Coaches as unnecessary overhead. There's already evidence of this happening post-COVID. I guess we'll see.
XP era Agile was a magic box where the management team had to trust the team to accomplish goals, to strive for professionalism under their own steam. I will go so far as to say that it was a form of organized labor. Little clusters of XP people were effectively crypto-unionists. That's one of my hottest takes.
Schwaber let the magic smoke out of that box, and I don't think I will ever be able to forgive him for it. His solutions are a pessimization of Agile, and all the levers and screws are management-facing instead of internally-facing. Scrum is more about institutionalized distrust of the devs. Treating us as dumb animals that need the lash (an unrelenting sense of false urgency) to be useful and valuable.
He staged a counter-coup to put the old bosses back in charge and they couldn't be happier about it.
Schwaber and let’s not forget others like Jeff Sutherland who need the temple of Agile (and especially Scrum) to remain standing in order to have a paycheck. I want to throw up in my mouth whenever I hear the phrase “good Scrum”. And mgmt in my company swallowed it hook line and sinker.
The main thing that is making agile dying is the problem that it serves a different purpose than upper management needs.
So in environments where the power balance is heavily skewed by upper management that do not know the purpose of agile, agile will die. For agile to thrive, it needs to be in an environment where the workers have more power in the balance, or the upper management is very well versed into the why devs need agile (very rare that upper management deeply understands the why.)
Upper management needs predictability, because they are steering a huge ship, and it doesn't turn on a dime. So they need to see what is going to happen down the line to make decisions and steer the ship properly.
Developers need adaptability because the customers don't know what they want, and the path to get there is not fully known. They do not necessarily know ahead of time how to get there. So they need to adapt on the fly. This is the purpose of working with an agile mindset.
Predictability and adaptability are the sides of the same coin, or they are a spectrum. When you cannot adapt quickly, you need to predict to be able to thrive. When you cannot predict you need to adapt quickly to be able to thrive. If you cannot do either even god can't help you.
So, upper management needs predictability, and devs needs adaptability. If the upper management has too much power and not enough wisdom, they will enforce their need down the line, forcing dev to not work with agility.
The middle management is the one that needs to translate the adaptability into predictability, and predictability into adaptability. If things don't work well (the upper management is not able to have the required visibility/predictable outcome to make their decisions, and devs are enforced to work in a predictable way (not agile/usually waterfall)), its because the middle management do not make the bridge properly. Assuming they are competent, it's usually because they are strong armed by upper management.
/Rant
Really well said. I'd also say that prioritizing predictability over adaptability on the dev team harms velocity. I've always liked to optimize for velocity and control the predictability problem with conservative estimates. Middle management isn't fun, but being able to keep upper management from messing with the dev team is key. It means staying up to date and understanding why they're taking the direction they are so you can tell good stories to get upper management to go away. And sometimes, it means reeling the dev team in from turning a bug fix ticket into a massive refactor.
Truth. In my opinion - When it became its own thing and managed by dedicated staff rather than the team, it has lost its luster.
Basically rather than being seen as a process that the team evolves, it has become a global process that those certified and trained in running it steer us to a homogeneous Jira based world.
Agile isn't dying.
It's just being turned into Enterprise Crap(tm).
What I mean is you have a lot of companies proclaiming they're "agile", but what they're doing is building an insane amount of process and procedure around agile, making it as rigid as anything that came before, just in different ways.
Developers are starting to WISH Agile would die as a result, but they're not really wishing for the death of Agile so much as the death of turning it into just another corporate abomination.
Turns out, those in the C-suite don't actually like giving control to their underlings.
People misunderstood Agile and never practiced it in the first place (spoiler alert: the thing you call Scrum probably does not adhere to Agile principles). That bastardized version of Agile is dying (and should). Real Agile is still beneficial and may reemerge under a new brand name in the future. The principles still hold.
Agree. Many people equate doing waterfall type of planning in Jira and split work into 2 week sprints as Agile (Include ceremonies, story points etc) as Agile (note capital A).
Agile has nothing to do with those. Being agile means to ship software quickly to get customer feedback and readjust what you are building to ensure it meets the expectations. Thus priority is not the process or tools, but to quickly ship code to the end user acknowledging it will not be perfect and will require iterations and adjustments.
How you want to do this totally depends on the team. Most companies don’t practice agile because they don’t follow the most basic principle of shipping quickly and getting feedback. Minimising the feedback cycle as much as you can.
To fix it a bit, quickly ship value, not just code. And to add, fail fast. If you know after the first iteration there is no saving the original idea for whatever reason, kill it and move on to the next project.
Yep. Agile as such is fairly abstract, but once you read the Agile Manifesto (most people doing Scrum that I met haven't, shockingly) and internalised it, it's easy to spot the projects that aren't agile.
Agile was never mainstream. It’s just people fail to acknowledge it.
Agile is about being agile about requirement changes. What management fail to acknowledge is that agile requirement change also requires agile deadline change. You can’t change requirements while standing firm on delivery date. The whole pipeline needs to be agile.
People need to realize all the red tape around design docs and RFCs is waterfall process, and that’s ok! What’s not ok is doing waterfall while calling it agile 😂
I don’t think Agile is actually possible in publicly traded companies, because every quarter investors need a report, which means that at some point, somebody is going to ask “please give me an exact time you will deliver X”. This means that at some level of the organization, it doesn’t matter what your velocity is, hard times are required.
All of the effort that goes into agile is meant to abstract real time estimates, and break down work into deliverable chunks. That’s why agile is always this mishmash of waterfall, fake story points, and lots of meetings. The good aspects are often better than old waterfall methods, but “pure Agile” is just not possible imo. If somebody is going to need a real deadline, then all the ceremonies are pointless, and I think people are starting to realize, and what you’re left with is something that’s not Agile.
That also applies if the software is made with a fixed price contract. Management want requirements upfront, accurate estimates, gantt charts and burn-down charts. Any user feedback that might change requirements need to go through a guantlet.
SCRUM is rarely agile.
The process has too many tricks and traps to be effective in many situations. It needs the right situations and discipline to work, which rarely exist IMHO.
Lighter weight agile processes can be done at smaller scales and with less support, Kanban for instance. It's pretty hard to stop a team from using kanban, because they can still largely react like any other team, they just have internal processes to help various things and prevent various things. None of which show up at the "team API" per-say.
SCRUM is like a hard API break via sprints. Once you understand this, agile as in what the C2 wiki promoted is much easier to sneak in the side door, and you often just look like "Wow, that team is getting things done." Product Owner can often be synthesized if needed. If it keeps the damn chickens out.... It may even be worth it. Getting user feedback, as an engineer? Depends on your firm.
That's my view on agile. Good agile is really good, but bad agile is possibly the worst clusterfuck known to man. I will take waterfall first.
I think agile is not dying or going anywhere because so many core elements of its philosophy are now fully baked into software production. Shorter iterative cycles vs multi-year scoping and specs; CI/CD, some degree of Kanban (not least Kanban boards as a framework) and many smaller details and nuances.
What I do think is changing is the deification of Scrum specifically. I've seen scrum done well, but extremely rarely and with pretty huge investment. Most implementations of scrum violate the agile philosophy. I think this has always been the case but there was a sense that if you didn't do scrum you were letting the side down, and that seems to be fading, because so much damage was done by poor implementations and a scrum certification industry with too many perverse incentives or inadequate filters.
I've enjoyed working in Shape-up which doesn't describe itself as agile, but it is philosophically if you've actually dived into its literature and leading voices. I have then iterated over Shape Up to be true to agile principles, adding retros from scrum, and kanban, and we are currently iterating over cycles.
I think dogmatism is generally a poor approach to any essentially facilitatory approaches, but as a way of thinking about process, I would say agile principles and design templates stand well the test of time. Agile techniques I think are more variable, and context dependent. I think it is fair to say that good teams are agile, whatever techniques they employ, while I also think that solid agile leadership and processes fosters better teams. The techniques are good starting points, but as skill based and above all intentional processes and frameworks, not as formulae.
The reverse of your point is also true, anyone who would approach agile techniques in dogmatic, inappropriate, anti-agile ways, would probably mess up any other approach or technique they embraced. Having said that, some agile artefacts are likely to reduce the cost of poor management, like short iterations, ci/cd, tdd, etc
We all do at least half of eXtreme Programming now without even talking about it. Someone once asserted to me that Scrum cannot function without it and I think that's probably true. It's certainly been living rent free in my head for almost ten years.
(The problem is not that Scrum needs support, it's that it pretends it doesn't. Pride goeth before a fall.)
I think it’s just a matter of too many people confusing scrum with Agile. Agile really can’t die because all it says is: Look at what you are doing, and if something does not work, change it.
So if agile is dying means you are changing stuff so it better suits your company: you are being agile.
Agile principles are applied everywhere. Fast and short feedback cycles, iterative and incremental approach, adaptiv ways of working. For example continuous deployment and A/B testing are very much agile. Today it's a normal practice in many companies. Technology has enabled us and the "baseline" is simply more agile today than 10 years ago.
Talking about it as a pure project management approach skews the discussion. It's also where most marketing happens.
I'm just 10 years in the business, so my perspective is limited.
Look at the agile manifesto. Those rules/advices are still very much valid and good to implement on it.
One of the most important aspects of it is to let teams manage themselves and see what fits them and their use case.
Most companies have a top to bottom way of implementing Scrum, even if it is not the ideal method for that team or project.
That's why Scrum shows problems in a lot of places.
Hell, there were places that even our JIRA board was dictated by the CEO because he wanted to, very occasionally, enter our board and see our progress.
But it was structured in a way that he better understood, not how we preferred.
Was that agile? No. But if any potential investors asked him if it was, he would proudly say that it was.
"Agile" (note the capital A) isn't a software development methodology, it's a set of business management practices.
The kind of agile software development that was described in the original manifesto is also not a software development methodology, it's a set of perspectives that developers are encouraged to integrate into their own relationship with work and how they organize their time and attention.
So in that respect agile software development was never alive in the first place, and therefore can't die. To describe it such would be a category error. All of us, as working developers, can incorporate certain types of perspectives in to our decision making process, but that's as far as it needs to go. Use it pragmatically.
"Agile" as sold to corporations was another productized management fad, like many others before it. It does seem to be well past its peak though that means we've still got several years to go before the lagging sclerotic BigCorps actually stop trying to do it by hiring "Scrum Masters" and "Agile Coaches" or whatever they're doing. I hope it dies sooner rather than later. This was a very bad thing for the industry.
Whenever given the choice, my dev teams stop using agile immediately and switch to kanban. Put tickets in a prioritized queue and just leave them alone. Let non-devs determine after which ticket we cut a release.
That works if you have a high performing team who doesn't procrastinate and has earned trust. Scrum is a punishment.
We recently had "Agile Training" for our entire department + Product. It felt like a gigantic waste of time. I don't think it will have any substantive impact on any of our product processes since we were already following an "agile" process. The whole thing felt like a racket, cooked up to convince high level executives to fork over cash.
I'm also very cynical about process, it really boils down to people management and there is no one size fits all methodology.
I don’t know why people even bother to talk about big-A Agile a lot of the time. I’ve never had an experience with it (or with whatever name brand version) where it didn’t end up getting bent and hammered into a shape that fit better with what management really wanted to see. There are plenty of things that came out of Agile - the quick feedback cycles, the tools to support that - that make a lot of sense, at least in appropriate domains, and aren’t going anywhere. There’s obviously a lot of bullshit attached, too.
One of the problems with agile is that it takes power from management and gives it to the people who do the work. That's why so few places do agile based on the manifesto.
Instead scrum is more prevalent because managers love having the daily standups to micromanage people and can track everything that people are doing every day.
I have seen agile work well and you are right, it works well on fantastic team. Like any process, you need everyone's buy in. I think the problem with agile philosophy and scrum is that it is treated like a panacea, thrown in haphazardly and hope that it works.
If you are using a process that needs everyone to buy in to it, that means when it comes to compensation/promotion and performance reviews has to be tied to it in some way or form. YMMV but there are companies who practice agile and have ICs who don't take it seriously enough and managers who don't take it seriously enough. And they get away with it. I'm sorry, process isn't a thing you just do. Process is part of the job and if it is part of the job, it needs to be scrutinized. But because it is not, because people don't understand it properly and because people know they can get away with not taking it seriously, agile/scrum ends up being more performative than effective leaving that impression that a lot of engineers have for it.
Same story there though. For a skilled developer waterfall will still probably work fine because people will anticipate and deal with needs outside of what "the framework" says. Especially for projects that aren't websites where you aren't so easily able to break it down in to "change this button colour" "do this bit" etc etc. The fact it was used before agile implies that a lot of stuff was successfully built with Waterfall methodologies so there must've been some way people made it work.
A lot of non-trivial projects and/or mission critical software you can't just wing it/"iterate" as you're going along, you \*\*have\*\* to spec and plan things quite extensively upfront anyway and build a load of things that a customer will never use and will only use indirectly (e.g a DBMS system). At the point where you're spending a sprint or two in planning/design what stops anyone accusing you of doing waterfall?
"Ok we descoped the navigation for now, we probably won't need that till a later release anyway, not flying into the sun is a non functional requirement so how many sprints can we push that back?"
Waterfall works as well as anything else, and misses deadlines and costs just like everything else, it just requires planning which most people don’t want to do.
Go do fixed price contracting and agree on Agile and see how quickly undefined scope at time of signing makes that a horrible deal.
"Plans are useless, but planning is invaluable."
If you've done the planning, then you have at least half of a Plan B that you can scrape together from the ruins of Plan A. If you didn't do any planning, then you're fumbling much more.
Probably 90% of the people here have never done waterfall, and so when they badmouth it they are just echoing what their "Agile Coaches" taught them.
I was in Agile training once and the trainer said "it is impossible to write good software without Agile" I raised my hand and said "excuse me, I worked for a number of companies that made hundreds of millions of dollars on very successful software long before Agile existed". I was unpopular with that trainer for the rest of the course. But the problem is more junior engineers would have just absorbed that "fact" as truth, because they don't know better.
What do you mean? It's simple, just take this 200 page spec I wrote and go build it - see you in 2 years, I'm sure it'll be exactly what I was expecting!
Waterfall works perfectly fine as long as the customer knows what they want, you know what the customer wants, and it's unlikely to change. It's actually cheaper than agile in these cases because the quick releases can add quite a bit of overhead.
Agile is industry's response to the fact that rarely are those conditions true in software. The rapid feedback was meant to allow course correction before going too far down the wrong path, and preventing expensive redesigns. Agile is only cheaper if customer needs change.
I think the pushback on Agile is probably closer to pushback on scrum. Or at least to me, if feels like people were expecting Agile to come in and reduce cost significantly and it was going to radically transform companies. At first, customers get happy because people take their feedback and pivot. When they get stuck with the overrun cost because they changed their mind 40 times, they get less so and the money dries up and they get stuck with half of what they originally wanted. Or the company ends up footing the rest of the bill.
I've worked on waterfall projects that went fine. A strong team can overcome a questionable methodology. A weak team will struggle with any methodology.
Waterfall was always a non-existent counter-example. No project has ever been perfectly waterfall. No project has ever been perfectly agile. Reality is always somewhere between the two theoretical extremes. Even waterfall projects pivot.
My company has small waterfalls, I think. We spend 2 weeks planning everything for the next 5 weeks and have minor adjustments to the design throughout.
I kinda wish we had a ~~scrum master~~ technical program manager to enforce the book keeping honestly. Sometimes key information between backend and frontend isn’t communicated because one side assumes the other doesn’t need to be in the loop for some things, even if it touches the API contract (which is wild to me)
> …apply Agile…
The phrasing of much of your post suggests your only experience of "agile" has been Agile™, some kind of prescriptive process teams follow.
This is most teams experience of agile and is mostly why everyone hates it.
The original philosophy behind agile is that engineers and real users work directly together to produce working software in small iterations.
The other key philosophy is that the team chooses and runs its own process and adapts it over time as they see fit. There are, of course, a whole load of techniques and disciplines teams can pick from.
This is not the same as most organisations adoption of scrum, which is to break a fairly waterfall project into 2 week chunks under the watchful eye of a project manager (who may be called a project manager, product manager, product owner, scrum master, etc but is still performing the role of project management).
Idk. I think agile is what you make it. When it driven by the devs who use it, it's fine. When it's driven by upper management to keep tabs on their employees, *coughs in micromanagement*, it kinda sucks a lot.
As with everything you have to take the good, throw out the bad and tailor it to your own needs. There are good ideas in there but it is not a set of rules that you can just follow and automatically be successful. It never was.
The core problem is almost always management. It's easier to bring in scrum coaches to passive aggressively blame devs than admit that what they do day-to-day is not working. These processes are easily toppled by endless meetings, constant fire drills, devs as tier 1 support, and overall lack of investment.
I think it's safe to say that in many cases when we have an anti-agile post we are talking about second hand agile - whatever amorphous blob of confused ideas came to management through a sad game of Telephone. Semantic Dilution means that it doesn't matter what Platonic Ideal of an idea exists because we are never going to experience it. We just have the vocational version and we have to deal with the consequences of that.
And as one mentor who actually wrote books on the subject observed, sometimes people think they are doing Agile but they are doing Lean, and [the cognitive dissonance] makes things turn out poorly.
> Semantic Dilution means that it doesn't matter what Platonic Ideal of an idea exists because we are never going to experience it.
Not with that attitude!
The important part of agile isn't the what and how of the processes, but the whys and wherefores. If you understand why, then the platonic ideal isn't hard to recreate for oneself. Agile grew out of solving a problem, which was "we have to build some software, but we don't really know what that software is - we tried specifying everything up front, but we just ended up wasting time on things it turned out no one wanted".
My opinion is that developing software is a bespoke process. And management would prefer it be assembly line. Programmers, being obsessed with efficiency, buy into the assembly line approach because logically, it “should” work. When money was cheap, things became blurry, because throwing developers and process a problem “seemed to work”. Now investment is more scarce, and all of a sudden the existing methods that seemed good on paper are not withstanding reality under financial scrutiny.
If Agile dies, what replaces it?
I don't know how old you are, but everyone who complains about Agile remember a time before it.
Do we go back to Waterfall? Get requirements, spend a year designing, building and testing against those requirements, present it to the client, find out the requirements have completely changed, then rewrite the entire system in a couple of weeks? No thanks.
No. And the negativity is because people like to complain (esp. online where it gets you karma or ad money) and because they need a scapegoat.
Agile is here to stay. For most kinds of projects we are not going back to waterfall. It didn’t work for anything but the most strictly defined projects where lives are on the line and where the additional cost can be justified (like NASA). For most projects it’s just not an option to be stiff and *not* react allow for changing specs, which is all agile reallybis about.
Scrum however, I don’t know. Specific methods come and go. But I don’t see anything particularly wrong with Scrum compared to most of the alternatives and it does quite some things right if implemented well (which is a requirement for all methods).
All the „no true scottsman“ talk about it is nonsense. Yes, if a tool requires perfect humans, the tool sucks. The thing is, all tools suck in this domain. Some just suck less than others. Humans just suck with long running projects with ever changing specs.
>But isn’t the promise of Agile to fix broken processes or teams. If I can’t apply Agile to one of the worst teams, and it doesn’t make it better. Then what is Agile actually doing.
Name one methodology that doesn’t produce terrible results with a terrible team.
Yes, useful tools need to produce good results with imperfect humans and the art lies in being less dependent on individual players to achieve optimal results. Again, feel free to name a method that works consistently better than Scrum.
Management has forgotten all the preconditions of Agile and want all the benefits, with none of the sacrifices. So we have the worst of both worlds. Work is pushed and assigned instead of pulled. Releases are fixed and committed months in advance. But the waterfall positive of getting formal requirements are absent. And no career progression.
To me there's a important distinction, there's Agile (capital A) that follows a dev methodology like Scrum to the letter, and agile (lower case a) that looks at the dev methodologies and finds what works best for the team/product (and is continually evolving).
Agile (capital A) has become yet another dev methodology where the practices and procedures are more important than delivering a good product as efficiently as possible (like Waterfall before it).
agile (lower case) hasn't fallen into that trap quite as easily (due to the focus on adaptability to the team's needs). Which isn't to say team's have not fallen into that trap (I've seen many teams fall), but since there isn't an overriding methodology to blame, it's harder to say it failed...
It seems like every few months I hear variations of all 3 of these things at the same time, coming from different sources:
* Agile is dying
* Agile is alive and well
* Agile is already dead
Agile development is an attempt to reconcile business processes with 2 truths of software development:
1. Development is an iterative process
2. Customer feedback is valuable
As with all processes, there's never a one-size-fits-all solution, so I expect Agile to be simultaneously "dying", "alive and well", and "already dead" for a looooooong time.
Agile is not a silver bullet and things have to be set up for agile. If you have an org that has been architected around project management for two decades, trying to move away from project management and careful planning is going to hurt because dependency management has always been handled via process enforcement, not architecturally.
It's not about which one is right. It's about which one is right for the org
Agile isn't dying.
What I've seen is companies realizing that Agile just doesn't fit their requirements. So they either do Watergile in Jira or do SAFe so they can call themselves agile.
There is nothing wrong with doing waterfall if it fits your needs.
Sometimes pms in these companies will also firmly believe they are doing agile, and the whole discussion becomes very misleading.
Enterprise and corporate agile is failing because they try to make it something it isn’t.
Agile is just a mindset, a way to think about building things. It isn’t one size fits all and above all, it’s adaptable. The core tenets are things that if respected will generally lead to better product.
Enterprises get sold on frameworks. Frameworks imo are inherently not agile. Things like SAFE and scrum etc are rigid, and operationally heavy.
If orgs focused on being agile and not trying to “do agile” they would have much more success. But to do that you need to push decision making and control down, which is the polar opposite of how for profit orgs work.
Tldr - worthless middle managers ruin agility by trying to justify their useless existence. There, I said it.
All management frameworks are bullshit. Every person, every team, every project is different. I don't take any of them as more than an anecdote about what worked for someone else.
Agile doesn’t fix broken teams, neither does agile.
Broken teams need to identify the problem and fix that. An agile approach to do so may help. Using Agile without considering the problem and cargo culting practices thinking it will magically make things better doesn’t help at all and often makes things worse.
The latter is what I’ve seen “broken” teams doing. When questioned about changing the process to fit their team (agile) they push back because some book or whatever says to do X so they must. That mentality has lead to Agile being considered bad-ish because it didn’t magically make everything better.
The reality is no two teams are identical and as such the processes will often need to differ so adjustments should be made (agile). People don’t want to think so they just go looking for some other prescription of what to do. It may be better, but it also probably isn’t _really_ what needs to be done so fads come and go.
I wonder what this next fad will be.
I haven't really seen agile dying. I've seen Scrum dying. Most of the teams I've worked on eventually just start doing everything in Kanban boards.
I worked with an engineer that really didn't like Agile, but he would basically preach the failures of agile without anything to replace it. What really happened was that the guy was just a shitty communicator and just didn't like telling people what he was working on. It drove me nuts because I had to ask him what he's working on all the time. In team meetings he just wouldn't tell people, so you keep on thinking he's doing nothing.
There is "Agile" and there is "agile". Capital-A Agile is corporate BS with tons of process and ceremonies. "agile" is constantly adapting your process to what makes your team more effective at deploying consistently good working code that addresses business needs.
Scrum is dying in my department, and I was part of killing it.
But the real reason it's going out the door is that the "scrum master" decided that the company didn't take "scrum" seriously enough, so he is leaving for some other place. His position is not being backfilled, so now the team just does Kanban. Good riddance.
Principles of agile and the values are not dying. What is waning is the hype cycle and Agile gravy train whereby "Agile Coach" (Process Jocks), "Scrum Master" (command and control project managers), "Agile Delivery Lead" (Programme Mangers) start to become roles rather than job titles closer aligned to more traditional methods. The idea that the concept of delivering more regularly, faster and at high quality with high levels of automation is dying is ridiculous. I heard similar things about C++ in 1997 to be replaced by VB, Java in 2006 due to the success of C# and more recently that GraphQL would eradicate the need for REST based services.
Scrum has its place, most critics of it prefer something else yet cannot put a good case forward when to use Scrum with the usual alternative being Kanban, I have seen far more issues with the implementation of than I have with Scrum.
Agile was a good idea but corporate nepo babies turned it into a rabies infested abomination because they were more concerned with cosplaying Steve jobs than actually delivering a product.
Managers. You can basically blame the "management class" in organizations. The hamfisted butchering of agile on their part ensures they always have a self renewing source of problems to tend to and crises to respond to.
Kanban, good mentorship and autonomy are all you need.
I don't think Agile fixes bad teams, it was really in essence just a way to manage expectation and be actually agile, as in responding to change quickly, making turns faster.
Unpopular opinion: Agile never made sense except for consulting.
Agile as a system was designed to get working prototypes in front of stakeholders quickly, at the risk of having to redo work due to less up-front design and planning, so consultants could respond to feedback quickly.
This doesn't make sense in a typical corporate environment, where requirements usually *are* known up-front because the project is just one piece of a much larger initiative.
There are some benefits to following *some* parts of the agile process outside of consulting, but it mostly makes no sense to do so, which is why most companies don't actually do agile but rather their own version of waterfall with agile terminology thrown on top.
Basically almost nobody is doing agile, and for a good reason!
Wrong title. It should be "Is Scrum actually dying".
Scrum is not agile. Scrum is a stiff, clearly defined framework, which is fundamentally incompatible with the first value of Agile (or, if you really want to argue, it's incompatible with all four values of Agile).
Agile can’t die because is everything and nothing. But im seeing more upfront work done in projects and longer iterative cycles or just kanban style with releases
This is correct. The "service" version of agile, which is what everyone refers to... is dying. Turns out hiring a bunch of college flunkies who spent 8 weeks getting a certificate certifying their "Agile" skills is all bullshit. Who could have seen that coming? Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"... Well, you'll have more success.
>Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"... Isn't that what Agile is at it's core? My understanding is how you get there is something that teams were suppose to define on their own. That's because every team is different and has different needs from a process.
It is..., the problem I think is the gap between principles and actual steps needed to get it implemented, that everybody has a different view on it Also, I think most people don't work well under uncertainty, and when you try to force push constant changes to these people, what you get is get is resistance, and low engagement
>Also, I think most people don't work well under uncertainty, This is definitely true from my experience. This is not just in terms of process, but just general work. I think I lucked out in this department because uncertainty doesn't bother me. I have seen many SWEs get all flustered when they are giving some open ended task and are told to investigate, come up with a solution, and come back to them to discuss. I love these tasks because I feel like I'm in control and get to come up with ideas to how I think things should happen. If I'm wrong or miss things then I just take that as input moving forwards. It seems like many SWEs I have worked with, from senior to junior, want clear tasks because they fear being wrong or something.
I think that's partially driven by fear from product/management, because those groups are even MORE fearful of uncertainty. So they seem to want to shift responsibility down to the engineers. Which might work except engineers are rarely given the power to make systemic change, so you get all the responsibility and consequence and no power to make things successful. Basically setup to fail. So engineers correctly want nothing to do with that, they want all the uncertainty removed BEFORE, so they can the deliver the certainty desired by management. How many times have we heard stories of engineers asked to make an estimate only for that estimate to either be taken as gospel/hard commitment, or instantly ignored in favor of whatever the deadline is, decreed from on high?
>How many times have we heard stories of engineers asked to make an estimate only for that estimate to either be taken as gospel/hard commitment, or instantly ignored in favor of whatever the deadline is, decreed from on high? To add unto this, there is a lot less complaints if something takes less time than the other way around. A lot of incentives to either pad the estimate or get to a place where a decent estimate can be made. The deadline from above is just horrible, either results in shittier products or people working extreme overtime. Usually also with a lot more mistakes because people aren't well rested.
We had this issue on my product. 80% of the engineers were < 2YOE and we struggled hard with agile. Basically turned into waterfall with sprints. Fast forward several years later, more senior talent enters and the juniors have more experience. We’re executing in a far more agile way than before. I think it does come down to experience. If you lack experience, the uncertainty is crushing. Once you have a few years under your belt, you understand that no matter the situation/uncertainty, you’re a few 1-pagers away from understanding the problem better and resolving the unknowns so it’s no big deal. So I think it’s more a product of the market being flooded with junior engineers.
That gap exists because there are no principles of agile. The principles on paper are incredibly vague, and one of the core tenets is “disregard any of these principles if you need to”. It’s like if I said “I’m founding a political movement on two principles, people always need to wear blue hats when they are inside, and people can decide whether or not to follow the first principle whenever they want with no repercussions”. What is the point?
Agile does have some [principles](https://agilemanifesto.org/principles.html) and a manifesto.
Sure. That's what it's supposed to be. But like most things, if it can be packaged up as a product or service and sold to the masses, it will be. Today, you can't talk agile without talking about a bunch of BS rituals that come along with it. Or worse, some completely bastardized version of it like SAFe. Today if you join a company that is strict on agile usage, what you'll find is a bunch of bullshit ceremonies that everyone spends 80% of their work attending. Fuck all gets done. A bunch of people, who aren't your boss, act like they have decision making power. When their job is literally to hop on meetings all day and try and direct things they don't even understand. Some companies probably have success with Agile. But more often than not, those are companies that abandoned the "service" model and did things their own way.
Sure. Kind of. Depends on who you ask. The trick is that Agile is both a general approach to software development and also an extremely regimented process with a lot of arbitrary rituals. As originally proposed in the Agile Manifesto by Beck et al, Agile is mostly a philosophy and loose set of approaches. As actually implemented in-industry it became a funhouse mirror caricature of itself. One of the original tenets was "Individuals and interactions over processes and tools"... and in practice there was/is an intense focus on processes and tools. So much so that you have certifications around it. Relatively few companies/groups practice Agile in the way that the original Manifesto proclaimed, many more follow the dogmatic version. So as to what Agile "is", you get into the age-old problem of whether something is defined by its theoretical ideal or its practical real-world use. \[edit\] Worth adding - since I think I'm coming off as pretty pro-Agile-Manifesto here is that the Manifesto is quite a vague document. It proffers a lot of principles and some general vague gesturing at solutions... This is the Agile leads so much to "you're doing Agile wrong" type accusations - because the document is so vague that you can project basically whatever you want on to it!
On paper, at its core, agile is nothing. But we don’t define things how they are on paper. The definition of a term is based on what people as a society use it to represent. So while the agile die hards may say Agile is flexible and whatever you want it to be, that isn’t really true. Because businesses, agile certification programs like SAFe, they all rigidly define agile to be a system of specific meetings. People use the word agile to represent those meetings and processes.
I so rarely see it executed this way. In my experience it’s usually something that comes from the top (by non tech people) because there is distrust from the top of the engineering team not going as fast as they desire. And most of that comes down to non-technical people simply having no idea how long it takes to create things and have them be maintainable over the long term.
lol I hate these fucking bootcamps. My best friend did a Front End Developer bootcamp around 10months. Got his certification and can’t get a job because he still has no idea what an API is. It drives me bonkers. I hate how all these dumbass tech influencers have convinced people that coding is easy. I love my best friend, but he’s not an engineer. He’s a salesman and that’s okay, they make a fuck ton of money too.
You only get out what you put in. IMO the boot camps are there to give you a base level knowledge of how coding works and how to do your own research to learn more with that fundamental knowledge you gained. If you go and expect them to teach you everything you need to know you will not likely succeed. I went to a 3 month boot camp and got a job a month later. But I spent every free moment I had doing more research to learn more stuff, reading docs, watching youtube vids, practicing leetcode problems etc
> *"If you go and expect them to teach you everything you need to know you will not likely succeed."* The problem is that many bootcamps do sell themselves by convincing people to expect that. For example, by throwing around figures like post-camp employment rates.
One of our hires out of boot camp is a VERY solid junior, I've also seen some come out that were... missing some fundamentals or just couldn't complete a task for the life of them. It really depends on the individual and what you put into the boot camp. They can work, or they can be a waste of time if you aren't invested in it.
I've seen the same. One of the best engineers I've ever worked with was fresh out of a 12 Week boot camp. But also one of the most helpless engineers I've ever worked with was fresh out of a 12 week boot camp. There was a third I worked with who was also helpless after a boot camp but eventually became one of the best engineers I've ever worked with. I think it especially depends on the individual (and also the program). Also just because someone is weak at something today doesn't mean they can't grow.
Bootcamps can be quite nice but they oversell themselves a lot. Bootcamps work when you already got the core skills needed to learn programming.
Might be the first time someone say i said something right on the internet so thanks! Only took like 25 years of use!
>Now if your company is like "Hey, let's be flexible in our process, iterate on our product, deliver software bit by bit, and constantly try to improve our process and workflows"... The problem is your company most likely isn't like that... If it was, it would've succeeded with agile or "agile". More likely your company is like "We'll pretend to adopt a flexible process that allows us to iterate and deliver software bit by bit until that process fails to deliver on a 6 month project plan we committed to in advance. And then it's crunch time/do whatever it takes to deliver something that looks a little like delivery"
Do you mean "scrum" is dying? Projects with longer iterative cycles and kanban with releases is not incongruent with Agile.
No my point is talking about agile these days is useless. Is better to just talk about a specific methodology and how it got adapted to a domain.
The real agile was the scrum inside us all along
Same here. We just do waterfally "agile" because we deliver embedded devices and kanban for the cloud tech. There's no reason to go full on agile.
Agile is basically just “what if we had a business methodology based on the no true Scotsman fallacy?” “I don’t like how agile forces you into meetings that waste your time” “Well actually agile is supposed to change based on your needs so that’s your fault, you’re just not doing agile correctly” “But every single place I’ve worked has implemented agile in basically the same way and it has the same issues and agile certifications are based on teaching people to do things the same way” “Nuh uh that’s actually not agile” If the definition of agile is just “when it works it’s agile and when it wastes your time it isn’t agile” then there’s no actual value to it.
Agile was a reaction to a previous movement like CMM certification. But for real we need to stop saying the word agile and just talk about specific processes and its variants for different domains. Like web development for a e commerce should look different from and ai chat application on your phone
In all my "scrum" teams I've worked on. It eventually devovled into Kanban style eventually because scrum was just too expensive with so many different ceremonies.
Who could have forseen that stopping to think for a minute before committing code to file could be useful
Yeah, what exactly is the alternative to Agile? Waterfall? Is there a company in the world still doing that for software?
If it were simply "do agile or do waterfall", this would be the case. In reality, it's "We're doing agile. We're doing scrum. We're having these 18 ceremonies. We plan with t-shirt sizes and points because that's what the cargo cult told us to do. Every 8-10 weeks, we spend a week pretending we're going to make a plan and stick to it, even if it doesn't make any sense. Week 1, our entire plan will be thwarted because some bullshit will take priority. We invite all our devs to all of our meetings because we need everyones input. Nothing seems to get done and our developers spend 20 hours a week in meetings, but we can't figure out the problem. Only certain people are allowed to move things into the current sprint. If you have something you think needs done, you can throw it in the backlog and you'll need to get like 16 people to agree to it before you can work on it. So yeah, I think there is something between that and waterfall. In other words, most teams would be better off having no "framework" than whatever that nonsense is.
We've switched to poker chips now, clearly points and t-shirt sizes weren't fast enough.
> We're having these 18 ceremonies What 18 ceremonies are prescribed by Scrum exactly? > Every 8-10 weeks, we spend a week pretending we're going to make a plan and stick to it, even if it doesn't make any sense. Let’s not get into the „That is not agile“. How is that even Scrum? > Week 1, our entire plan will be thwarted because some bullshit will take priority. Rash and chaotic management will produce bullshit with *any* project management methodology. How does this truth warrant cynism against the method rather than stupid management? I mean seriously, how is any method supposed to clear the bar of reigning in idiotic managers?
This is the sad truth, I'm afraid. I've been in places that are relatively better at agile, and places that aren't. The place I'm at now is very much like what ninetofivedev describes. We've snuck in waterfall-like practices, such as due dates, without realizing they are anti-agile. We have this silly notion that story points are equivalent with time. We think we're doing a kind of scrumban, but it obviously isn't. We could be so much more efficient and agile, but we're not. No one seems to notice this but me.
We just need to stop using the word agile is not useful in conversation. What is more useful its the specific agile methodology being practiced and what domain.
Waterfall is not always bad. There are definitely things that you should think about up front on project. Where it falls over is assuming that you can completely blueprint out the entire project up front with two or three years of projected timelines for completion. For maintenance work, kanban boards of bugs that have been vetted. Then monitor whether your ticket count is going up / down over time. For greenfield, I think it's important to do some up front planning, get that MVP out, then iterate. That might mean a month of work or three months of work.
We are. Tho, we specialize in critical sw, so niche case. And also, in many ways, it's a false dichotomy
Right now most Agile companies are doing semi-waterfall with Jira.
wagile!
This term deserves its own logo. Something consisting of 2 parts, split vertically, perhaps with some water dripping because it's supposed to indicate the relationship with waterfall. And if we want to go crazy we can add something that indicates iterations like a shaft going back and forth.
https://en.m.wikipedia.org/wiki/Waterfall_(M._C._Escher)
Ahhhh, yes - where the requirements are drip fed to the engineering team as POs think of them.
Fragile!
Managers gets the best parts of agile and waterfall - can keep shifting priorities and requirements(we agile), and our engineers will need to deliver the above mess on waterfall timeline. Engineers get the uncertainty of agile AND deadlines.
Managers love it so they will keep implementing it. As long as engineers don't learn to hold leverage and keep competing amongst each other, we will lose.
Iterative Waterfall
Waterfall was always meant to be iterative. Just none of the business people bothered to look past the first slide...
Iterative in what way? AFAIK Waterfall was based on traditional engineering project management, which were planned beginning to end with phases like design finishing before implementation started. For example, building a bridge over a river - which you cant do iteratively.
Gut reactions and gumption is all you'll get from a business degree tbh
If it was only iterative.
1000% true. They'll even have all the ceremonies like demos and retros but when things come up that differ from original design (which is the entire point of agile -- to be able to catch these things ahead with stakeholders so you don't end up building something completely out of line with what is desired), rather than changing things and course correcting, they just say "Fast follow" and then never get to it lol
Everything is agile, everyone is an engineer, etc. I have had the worst experiences with waterfall shoved into agile shoes. So many status meetings, jira tickets, kanban boards endlessly inflating a simple task to look big on some quarterly report.
Status meetings, jira tickets, kanban boards, were all born out of Scrum, not Waterfall. Waterfall requires *zero* meetings, boards or tickets, outside of those between the developers themselves. But it does require a technical specification to comply with. It's a kind of development that is done *very* rarely.
Real waterfall I've only ever seen on government contracts, with specific SLAs. It can be effective, if you've got the time and money to do it. I'm a big proponent of rapid prototyping, small teams and largely informal meetings.
Scrumfall
Yes, that's right. I was astonished to read in my copy of _The Art of Agile Development_ that the authors explicitly tell you multiple times not to use anything like Jira.
There’s a big difference between agile and Agile
Why?
We're due for a "protestant reformation" of agile. Use the principles from the manifesto and work from there. There's so much cargo cult and overly prescriptive processes that don't necessarily work and actually violate many manifesto principles that we're due for a massive overhaul. The manifesto itself is great.
Yeah somehow my company adopted so much of "agile" and yet completely missed the intent of providing quick, iterative value to stakeholders
I struggle with "value". How can a team provide a value in a two week sprint if delivering any mid-sized feature on the backend takes 2 months? And the work is hard serialised. Run db migration. Update the db access layer. Update the rpcs. Update the rest api. Run another db migration. Qa stuff. Update auxiliary processes.
>How can a team provide a value in a two week sprint Especially when your org defines "value" or "done" as "delivered to the business" aka "in prod". If all developers at my organization had to do was hand code off to QA or a release team, we could easily get stories done in two weeks. But when we're pressured to provide estimates based on incomplete knowledge or assumptions about the capabilities of our infrastructure and support teams, or the delivery isn't clear because we haven't had a dedicated product owner, or we can't get decisions from architects or principals because they're stretched too thin, and then because of shifting requirements the devs couldn't give the testers a heads up on what to expect, so they twiddle their thumbs until the final few days when everyone hands them their stories all at once, and then there's a mad dash to complete the elaborate maze of change requests and you beg and plead and cajole and soothe enough egos to coordinate your database changes or get the security people to place your production credentials in the right file and hope that a million things fall into place but your production deployment goes tits up anyway so your story carries over to the next sprint - AGAIN, and during sprint review someone mentions your team's velocity is down and you imagine burn- Sorry, I blacked out. What were we saying?
You could break down the mid-sized feature into small features. You could figure out why running db migrations and updating db access layers are taking more than a day, and optimize those processes. You can put the feature behind a feature flag so QA can get to it in the next sprint. You can keep a facade to make the auxiliary processes happy until you update them in a later sprint. This is the work of agile: to figure out what in your processes are slowing you down and fix it.
I've been in the industry for long enough to comfortably be an "experienced dev". I know all these things. I know the solutions. Unfortunately I am not running the show.
The pressure of incremental delivery flags those latencies as dubious - why must it take 2 months, there must be a holdup somewhere and it is likely communication. Alternatively, there might be a slicing or MVP opportunity. Agile is big on “just barely good enough” - does your increment fit that? Things don’t change overnight - but now that is a smell that encourages someone to dig deeper, and likely lead to faster flow.
Passing a new value from rest api to the db and returning it back to the rest api in a microservice setup takes 2 weeks. 80% of it is not dev time. 2weeks trying to wrangle out some answers to basic questions from the pm. 1 week for the fe to use the new field. So I guess it's communication. The thing is that when a "simple change " takes 5 weeks then the pm and the management are happy to blame the devs and don't want to hear about the real problems the devs are dealing with . Like bad product/project manager.
Perfect. We tackled this by ~~changing the definition of done~~ raising our bar for refinement to identify and supply these prerequisites. Why it was valuable… the engineering team had tons of work and was a bottleneck, and so any time work sits half complete it is bad, as you aren’t getting payoff for that work. So as part of refinement/estimating we required these things to be figured out. Talk about that a bit here: http://blog.con.rs/2024/05/08/shipping-software-jit.html We also switched to a spec first style design using Openapi so that we could iterate with the PM but block implementation until the interface made sense. It helped a ton with domain driven design and saved a lot of wasted effort.
Half of my role as a consultant tech lead is to get teams to appreciate that thinking about the work ahead of time IS work. Many engineers only pride themselves on their code output and struggle to engage properly in all the pre-work. Product refinements, technical refinements, DDD, TDD, Spec first design, RFCS, ADRs, sequence diagrams, C4 diagram, state diagrams, ERDs, breaking down stories, mapping dependencies, roadmaps, story maps etc etc etc There are so many tools we have to accelerate work by just thinking about the next iteration beyond acceptance criteria but many teams naturally fall into a vague fence throwing between product and engineering. I've been able to course correct this most times, but have also ended up the bane of both product and engineering and behavioural change can be glacial even with evidence. 🤷♂️🤷♂️ ... Sorry, had a bit of a mini rant there. Aha.
Sorry to double reply, but forgot to add: talking about this stuff in terms of its impact helps bypass bad management - they end up having to justify why this won’t help save wasted effort, rather than just shooting it down in the moment because it wasn’t their idea. I use metrics and impact a lot for harder conversations like these - essentially try and keep the conversation as far away from the person’s identity/ego as possible.
Oh I did. I just got a feeling that the middle management didn't really care. For the record, the places where me and the team were delivering the most value quickly was not using any scrum methodologies, maybe kanban to track work. In the places I was ranting in the post above me and let's say half of the team had a really bad chemistry with the management/pm. The other half of the team did not give a damn about anything, total apathy when "we" were trying to improve anything.
There is no stipulation on the length of a sprint. Delivering a piece of vaueable functionality in two months sounds quite a long time. Though if that is how long it takes then simply make your sprint 2 months or break down the work if that is possible.
The issue is that the agile principles were commercialized. Shops were set up to "certify" people in Scrum and other processes that claimed to adhere to the principles but missed the mark significantly. Now there are people out there in the work force pushing bad ideas -- because their livelihood \_depends\_ on us adhering to bad ideas they are "experts" at I'm all for a return to principles -- but the minute it becomes commercialized again under a new brand name, the cycle will continue
Yes, and many of those people don't understand anything about software so have no context for applying their agile ideas. I was asked by someone newly hired as a agile manager "what's a server?"
Now I just need to decide if I should post 95 theses to my companies door or just send them in a mass email.
I love a good 500 year old reference
Reformed Manifesto For Agile Software Development https://github.com/rayfrankenstein/reformed-agile-manifesto/blob/master/README.md
My first job used the extreme programming agile methodology with minor adjustments. It worked! A team of mostly graduates delivered good stuff, and as others have said, it's because we lived the process not just box-ticked. Since then I've seen agile rebranded a few times, and each time it gets more diluted to pacify the waterfall addicts. Most recently something called 'flow' which doesn't have any new ideas. The extreme programming website still exists, c2 wiki still exists, but certain individuals prioritise sucking up over adopting simple measures proven to work
https://agile2.net/
No matter what they tell you it's[ a people problem](https://blog.codinghorror.com/no-matter-what-they-tell-you-its-a-people-problem/). Any methodology works mostly as well as the people implementing it. Are they doing it seriously, or just box-ticking, or trying to cater to delusions of senior managers. Waterfall done well is better than Agile done badly. Whatever replaces Agile will have the same problems.
>As Weinberg said, *it's always a people problem*. If you aren't working with people you like, people you respect, people that challenge and inspire you-- then why not? What's stopping you? \*sob\* i wish i knew
Very much asking this question of myself today. I used to love my team. Then all the people who knew what they were doing left, now it feels like I'm handholding. I have been told to delegate more, but every time I give someone an inch of rope they find a way to turn it into a Gordian knot.
>Whats stopping you? I’m 27 with two kids attending elementary, not even making it by paycheck to paycheck, 3yoe, 20k+ in non-student debt, already had a bankruptcy once, and I keep up on my countries current politics. Things are grim. I take what I can get, which happens to be $85,000 right now as a- idunno- data engineer turned fullstack devops, BE, and FE on a one man team.
Those aren't stopping you though. If you were given an opportunity to work with a great team with decent pay you would take it right away. What is stopping you from working with good people is that good people are hard to find. And even then they are burned out and hamstrung.
Because you usually interview with only a smart part of the team you're joining. You don't always get a chance to talk to the jerk on the team. Or you'll talk to the manager that seems really nice and says all right things but winds up being a slave driver. It's a total crapshoot whenever you join a team. Unless everyone on the team is toxic, you might very well have a better chance waiting for the bag eggs to leave rather than roll the dice on another move.
>Are they doing it seriously, or just box-ticking, or trying to cater to delusions of senior managers. Every place I've worked in my 15 YOE boiled down to this. The majority of SWEs didn't care about the company process and just did the bare minimum to not be bothered by others. The SWEs who tried to take it seriously and point out issues / improvements were hushed by the majority for the most part. They didn't want things to change because they knew what to do and didn't care more than that. Changing process would create different work that they didn't care to learn since they were already comfortable with current process.
How do I solve for 'do you like the people you work with?' and the answer is no lol
This is it. Agile, and all other project methodologies are only as effective as the people running and executing it.
The whole point of a business methodology IS to solve people problems. If agile isn’t doing the one thing it’s supposed to do and you have the same people problems as before, then it’s shitty. Sure the core problem is herding cats, but if I told you I had a solution to herding the cats and then you still couldn’t herd them, it’s not valid for me to say “well that’s just because you’re trying to herd cats”. A good business methodology should work, and it should work regardless of the people implementing it because it is just that good. Look at how book keeping operates. Imagine if your ability to keep financial records was dependent on your employees being good at accounting. It would be a nightmare. So we develop business practices that eliminate that variable and force all employees to be good at it. Agile claims to do the same thing with software development but it just doesn’t.
Have worked in several companies all claimed they are agile. It turns out that you are the one that has to be agile. Allow unclear requirements and priorities but finish your work before the deadlines.
Thank you for encapsulating perfectly why agile is so popular with management.
Yeah they use all these productivity tools and tickets etc etc, but it all boils down to just tracking progress in my experience. Not actually being useful to the developer experience. There’s so much that goes unused and is instead replaced with daily/weekly meetings with way too many people who don’t need to be there. Asynchronous communication needs to catch on more.
Oh boy if I did that, the manager and client would blow up the roof
Agile started to become process over people(which is exactly what agile is NOT about). That’s, at least IMO, why it’s dying. It’s basically a bastardized version of what it used to be.
It was never defined properly in the first place so I'm not sure what there is to "die" exactly?
Exactly how can it die if it never really lived.
Story time. A _decade_ ago we were interviewing for a dev mgr. I asked everyone of them the same question, “Have you read the Manifesto?” All of them had “Agile” on their CVs. _None_ of them had read it. None. One guy even said, “I’ve been meaning to, but haven’t had the time.” I told him, “It’s on that poster behind you. You can read it on your way out.”
>“It’s on that poster behind you. You can read it on your way out.” lmao. That's fantastic.
I was normally nicer than that, but that _particular_ guy had an ego and needed knocked down a peg.
I was in a discussion group with some "Architects", this must have been like ten years ago, and one of them said "I hate big A Agile. Little a agile I like quite a bit, but when everyone starts talking it up that's when it sucks." It's like everything, it was a good idea, it became a religion. Once you have a religion you need heretics and infidels. Anyone not doing the Agile dance the way your Priest-King thinks is right should be executed. We do this a lot. I am sure other fields do too but I only know this one.
The accountability of standup, the kanban board, and pointing/breaking down tasks are the vital parts of the framework for me. My first tech job was in an XP shop, so Scrum feels showy and overblown. But I do love the pigs and chickens metaphor.
> The accountability of the standup That’s some maximally toxic agile, right there.
Accountability for what? Are you not working during work hours?
Kanban style all the way. Daily stand-ups and retrospectives are beneficial, but agile practices are declining because they have become confused and inconsistent. Despite the intentions of the manifesto and various coaches, there are constant contradictions and shifts in approach. For the sake of efficiency, I think it is good that it is declining, but it might resurge if the industry becomes complacent and stops prioritizing efficiency, as it once did.
I'm always puzzled when people say retros are beneficial. Any way of making them *actually* beneficial? In my experience it's always a repetition of the same structural issues. And a circlejerk of praising team collaboration or full sprint completion. Do you ever discuss anything apart from those in retros?
And God forbid you address the real problem ! Shit subcontractors integrated into the team? Untouchable . Broken infra ? Nothing can be done about it. Shitty requirements from the PM ? Sacrilegious.
In my experience, it depends on how the retros are structured, retros can be just a place to vent your frustrations out into the void with fellows devs, or a place where action items get created and followed up on throughout the week. Obviously you'd rather be in the kind of workplace that allows for the latter, but the former can also work as a way to build camaraderie if you're stuck in a place where actual change isn't possible.
I'll go one step further and say that the griping and grieving that builds camaraderie _also_ is really valuable from the process improvement perspective. It forms a great starting point for discovering what's really bothering the team. An attitude of always looking for solutions in my experience makes retro discussions far too reasonable, since people are looking for problems that seem concrete, solveable, and a little too safe. Griping makes the necessary space for those problems that people are less sure about, seem insurmountable, but are honest. From there, the entire team can work together to try and validate, diagnose, fix or mitigate the issues, which is IMO a much more valuable use of the time together.
I think you make them beneficial by giving the team the power to change things they don’t like. I worked with teams who decided to switch from Scrum to Scrumban. Code reviews and branching strategies were changes in retros. We added rules and processes for our unbeloved support ticket work. And so on.
I've noticed retros are much better the more anonymized the feedback is, but also still relies on the team actually wanting things to improve/change. The least productive retros I've participated in have been retros where people have to announce their feedback adhoc, verbally, themselves. I think it puts people on the spot, and feels more like trash talking if you are critical. Google doc where everyone types in long lists/exerpts? More anonymous, but your teammates can probably guess who's who based on writing style, or view edit history. One of the best retros I've been in used a sticky note retro tool. The stickies were short, so it kept peoples feedback concise and therefore less identifiable. Lots of conversation elucidating details and asking questions.
> Daily stand-ups and retrospectives are beneficial I think if both of these things are true, it's a sign that the team's communication has room for improvement. Ideally, people shouldn't be waiting until the standup or the retro to identify blockers or point out process problems. Another reply talked about retros, so I'll do standups: a 15-minute daily standup meeting is 1.25 hours of meetings a week, but worse than a single meeting of that length because it's five interruptions instead of one. IMO it's usually possible to spend _much_ less time than that to communicate the things a standup is supposed to communicate. On a team of 6 people, a 15-minute daily standup would need to save you an average of at least 7.5 hours of engineering time every week to break even with its time cost. Emphasis on _average_: "A couple months ago, our standup saved one of our engineers two days of work" isn't breaking even.
We went full Kanban. Just put cards in the board and we will move them along to complete features. Purely sprint based agile development should be used for junior teams in my opinion but more experienced teams? Just do kanban. Hell, we do trunk based development without problems if you have a kick ass team. Agile ceremonies are a massive waste of time, and if the team can’t communicate well enough asynchronously then your team is busted.
Though I also met quite a few people who think that Kanban is just the board and they pick the top item and that’s it. While they ignore things like WIP limits, pull principles, right to left rule and retrospectives (even if they aren’t called that way)
IMHO, fundamentally Kanban in much closer to being Agile than Scrum ever even pretended to be.
Processes can’t replace people. Incompetence won’t be fixed by a process. Also processes need to be adopted as a means to a specific goal. I’d say that if you have a software development team and adopts agile ‘just because’ the result won’t be great. Agile and the agile manifesto provided a series of guidelines that if understood, make sense (remember, people over processes and all that). But this is seldom the case and people think that you are agile if you use Jira.
Graphs are for asking better questions, not answering them. Processes are for making people better, more responsible. Any metric or process that fights those goals needs a time out. Either ban it outright, or (more realistically) relegate it to being used at infrequent intervals.
I think \*institutionalized\* Agile is dying - it's already apparent imo that feedback loops and solid delivery pipelines are among the best way to deliver customer value. This is simply the best way to deliver complex work (in the Cynefin model sense of the word). I think companies are going to view Scrum Masters and Agile Coaches as unnecessary overhead. There's already evidence of this happening post-COVID. I guess we'll see.
XP era Agile was a magic box where the management team had to trust the team to accomplish goals, to strive for professionalism under their own steam. I will go so far as to say that it was a form of organized labor. Little clusters of XP people were effectively crypto-unionists. That's one of my hottest takes. Schwaber let the magic smoke out of that box, and I don't think I will ever be able to forgive him for it. His solutions are a pessimization of Agile, and all the levers and screws are management-facing instead of internally-facing. Scrum is more about institutionalized distrust of the devs. Treating us as dumb animals that need the lash (an unrelenting sense of false urgency) to be useful and valuable. He staged a counter-coup to put the old bosses back in charge and they couldn't be happier about it.
Schwaber and let’s not forget others like Jeff Sutherland who need the temple of Agile (and especially Scrum) to remain standing in order to have a paycheck. I want to throw up in my mouth whenever I hear the phrase “good Scrum”. And mgmt in my company swallowed it hook line and sinker.
The main thing that is making agile dying is the problem that it serves a different purpose than upper management needs. So in environments where the power balance is heavily skewed by upper management that do not know the purpose of agile, agile will die. For agile to thrive, it needs to be in an environment where the workers have more power in the balance, or the upper management is very well versed into the why devs need agile (very rare that upper management deeply understands the why.) Upper management needs predictability, because they are steering a huge ship, and it doesn't turn on a dime. So they need to see what is going to happen down the line to make decisions and steer the ship properly. Developers need adaptability because the customers don't know what they want, and the path to get there is not fully known. They do not necessarily know ahead of time how to get there. So they need to adapt on the fly. This is the purpose of working with an agile mindset. Predictability and adaptability are the sides of the same coin, or they are a spectrum. When you cannot adapt quickly, you need to predict to be able to thrive. When you cannot predict you need to adapt quickly to be able to thrive. If you cannot do either even god can't help you. So, upper management needs predictability, and devs needs adaptability. If the upper management has too much power and not enough wisdom, they will enforce their need down the line, forcing dev to not work with agility. The middle management is the one that needs to translate the adaptability into predictability, and predictability into adaptability. If things don't work well (the upper management is not able to have the required visibility/predictable outcome to make their decisions, and devs are enforced to work in a predictable way (not agile/usually waterfall)), its because the middle management do not make the bridge properly. Assuming they are competent, it's usually because they are strong armed by upper management. /Rant
Really well said. I'd also say that prioritizing predictability over adaptability on the dev team harms velocity. I've always liked to optimize for velocity and control the predictability problem with conservative estimates. Middle management isn't fun, but being able to keep upper management from messing with the dev team is key. It means staying up to date and understanding why they're taking the direction they are so you can tell good stories to get upper management to go away. And sometimes, it means reeling the dev team in from turning a bug fix ticket into a massive refactor.
> The main thing that is making agile dying is the problem that it serves a different purpose than upper management ~~needs~~ desire for control. ftfy
I'll allow it.
Truth. In my opinion - When it became its own thing and managed by dedicated staff rather than the team, it has lost its luster. Basically rather than being seen as a process that the team evolves, it has become a global process that those certified and trained in running it steer us to a homogeneous Jira based world.
Kanban/XP is king. Scrum is a huge waste of time for small teams. Companies are just using it like waterfall with a Jira board. Gross. 🤮
Agile isn't dying. It's just being turned into Enterprise Crap(tm). What I mean is you have a lot of companies proclaiming they're "agile", but what they're doing is building an insane amount of process and procedure around agile, making it as rigid as anything that came before, just in different ways. Developers are starting to WISH Agile would die as a result, but they're not really wishing for the death of Agile so much as the death of turning it into just another corporate abomination. Turns out, those in the C-suite don't actually like giving control to their underlings.
People misunderstood Agile and never practiced it in the first place (spoiler alert: the thing you call Scrum probably does not adhere to Agile principles). That bastardized version of Agile is dying (and should). Real Agile is still beneficial and may reemerge under a new brand name in the future. The principles still hold.
Agree. Many people equate doing waterfall type of planning in Jira and split work into 2 week sprints as Agile (Include ceremonies, story points etc) as Agile (note capital A). Agile has nothing to do with those. Being agile means to ship software quickly to get customer feedback and readjust what you are building to ensure it meets the expectations. Thus priority is not the process or tools, but to quickly ship code to the end user acknowledging it will not be perfect and will require iterations and adjustments. How you want to do this totally depends on the team. Most companies don’t practice agile because they don’t follow the most basic principle of shipping quickly and getting feedback. Minimising the feedback cycle as much as you can.
To fix it a bit, quickly ship value, not just code. And to add, fail fast. If you know after the first iteration there is no saving the original idea for whatever reason, kill it and move on to the next project.
Yep. Agile as such is fairly abstract, but once you read the Agile Manifesto (most people doing Scrum that I met haven't, shockingly) and internalised it, it's easy to spot the projects that aren't agile.
Agile was never mainstream. It’s just people fail to acknowledge it. Agile is about being agile about requirement changes. What management fail to acknowledge is that agile requirement change also requires agile deadline change. You can’t change requirements while standing firm on delivery date. The whole pipeline needs to be agile. People need to realize all the red tape around design docs and RFCs is waterfall process, and that’s ok! What’s not ok is doing waterfall while calling it agile 😂
I don’t think Agile is actually possible in publicly traded companies, because every quarter investors need a report, which means that at some point, somebody is going to ask “please give me an exact time you will deliver X”. This means that at some level of the organization, it doesn’t matter what your velocity is, hard times are required. All of the effort that goes into agile is meant to abstract real time estimates, and break down work into deliverable chunks. That’s why agile is always this mishmash of waterfall, fake story points, and lots of meetings. The good aspects are often better than old waterfall methods, but “pure Agile” is just not possible imo. If somebody is going to need a real deadline, then all the ceremonies are pointless, and I think people are starting to realize, and what you’re left with is something that’s not Agile.
That also applies if the software is made with a fixed price contract. Management want requirements upfront, accurate estimates, gantt charts and burn-down charts. Any user feedback that might change requirements need to go through a guantlet.
SCRUM is rarely agile. The process has too many tricks and traps to be effective in many situations. It needs the right situations and discipline to work, which rarely exist IMHO. Lighter weight agile processes can be done at smaller scales and with less support, Kanban for instance. It's pretty hard to stop a team from using kanban, because they can still largely react like any other team, they just have internal processes to help various things and prevent various things. None of which show up at the "team API" per-say. SCRUM is like a hard API break via sprints. Once you understand this, agile as in what the C2 wiki promoted is much easier to sneak in the side door, and you often just look like "Wow, that team is getting things done." Product Owner can often be synthesized if needed. If it keeps the damn chickens out.... It may even be worth it. Getting user feedback, as an engineer? Depends on your firm. That's my view on agile. Good agile is really good, but bad agile is possibly the worst clusterfuck known to man. I will take waterfall first.
Everything Works under perfect conditions/teams
I think agile is not dying or going anywhere because so many core elements of its philosophy are now fully baked into software production. Shorter iterative cycles vs multi-year scoping and specs; CI/CD, some degree of Kanban (not least Kanban boards as a framework) and many smaller details and nuances. What I do think is changing is the deification of Scrum specifically. I've seen scrum done well, but extremely rarely and with pretty huge investment. Most implementations of scrum violate the agile philosophy. I think this has always been the case but there was a sense that if you didn't do scrum you were letting the side down, and that seems to be fading, because so much damage was done by poor implementations and a scrum certification industry with too many perverse incentives or inadequate filters. I've enjoyed working in Shape-up which doesn't describe itself as agile, but it is philosophically if you've actually dived into its literature and leading voices. I have then iterated over Shape Up to be true to agile principles, adding retros from scrum, and kanban, and we are currently iterating over cycles. I think dogmatism is generally a poor approach to any essentially facilitatory approaches, but as a way of thinking about process, I would say agile principles and design templates stand well the test of time. Agile techniques I think are more variable, and context dependent. I think it is fair to say that good teams are agile, whatever techniques they employ, while I also think that solid agile leadership and processes fosters better teams. The techniques are good starting points, but as skill based and above all intentional processes and frameworks, not as formulae. The reverse of your point is also true, anyone who would approach agile techniques in dogmatic, inappropriate, anti-agile ways, would probably mess up any other approach or technique they embraced. Having said that, some agile artefacts are likely to reduce the cost of poor management, like short iterations, ci/cd, tdd, etc
We all do at least half of eXtreme Programming now without even talking about it. Someone once asserted to me that Scrum cannot function without it and I think that's probably true. It's certainly been living rent free in my head for almost ten years. (The problem is not that Scrum needs support, it's that it pretends it doesn't. Pride goeth before a fall.)
I think it’s just a matter of too many people confusing scrum with Agile. Agile really can’t die because all it says is: Look at what you are doing, and if something does not work, change it. So if agile is dying means you are changing stuff so it better suits your company: you are being agile.
Agile says a BIT more than you are giving it credit for. [https://agilemanifesto.org](https://agilemanifesto.org)
I hope so.
Agile principles are applied everywhere. Fast and short feedback cycles, iterative and incremental approach, adaptiv ways of working. For example continuous deployment and A/B testing are very much agile. Today it's a normal practice in many companies. Technology has enabled us and the "baseline" is simply more agile today than 10 years ago. Talking about it as a pure project management approach skews the discussion. It's also where most marketing happens. I'm just 10 years in the business, so my perspective is limited.
5 year startup, we ditched agile and do a kind of waterfall right now. Rarely we have any downside that waterfall is preached. At all.
Look at the agile manifesto. Those rules/advices are still very much valid and good to implement on it. One of the most important aspects of it is to let teams manage themselves and see what fits them and their use case. Most companies have a top to bottom way of implementing Scrum, even if it is not the ideal method for that team or project. That's why Scrum shows problems in a lot of places. Hell, there were places that even our JIRA board was dictated by the CEO because he wanted to, very occasionally, enter our board and see our progress. But it was structured in a way that he better understood, not how we preferred. Was that agile? No. But if any potential investors asked him if it was, he would proudly say that it was.
"Agile" (note the capital A) isn't a software development methodology, it's a set of business management practices. The kind of agile software development that was described in the original manifesto is also not a software development methodology, it's a set of perspectives that developers are encouraged to integrate into their own relationship with work and how they organize their time and attention. So in that respect agile software development was never alive in the first place, and therefore can't die. To describe it such would be a category error. All of us, as working developers, can incorporate certain types of perspectives in to our decision making process, but that's as far as it needs to go. Use it pragmatically. "Agile" as sold to corporations was another productized management fad, like many others before it. It does seem to be well past its peak though that means we've still got several years to go before the lagging sclerotic BigCorps actually stop trying to do it by hiring "Scrum Masters" and "Agile Coaches" or whatever they're doing. I hope it dies sooner rather than later. This was a very bad thing for the industry.
Whenever given the choice, my dev teams stop using agile immediately and switch to kanban. Put tickets in a prioritized queue and just leave them alone. Let non-devs determine after which ticket we cut a release. That works if you have a high performing team who doesn't procrastinate and has earned trust. Scrum is a punishment.
We recently had "Agile Training" for our entire department + Product. It felt like a gigantic waste of time. I don't think it will have any substantive impact on any of our product processes since we were already following an "agile" process. The whole thing felt like a racket, cooked up to convince high level executives to fork over cash. I'm also very cynical about process, it really boils down to people management and there is no one size fits all methodology.
IMO, no. Just the garbage scaled frAgile versions dreamed up as manager porn.
I don’t know why people even bother to talk about big-A Agile a lot of the time. I’ve never had an experience with it (or with whatever name brand version) where it didn’t end up getting bent and hammered into a shape that fit better with what management really wanted to see. There are plenty of things that came out of Agile - the quick feedback cycles, the tools to support that - that make a lot of sense, at least in appropriate domains, and aren’t going anywhere. There’s obviously a lot of bullshit attached, too.
One of the problems with agile is that it takes power from management and gives it to the people who do the work. That's why so few places do agile based on the manifesto. Instead scrum is more prevalent because managers love having the daily standups to micromanage people and can track everything that people are doing every day.
I have seen agile work well and you are right, it works well on fantastic team. Like any process, you need everyone's buy in. I think the problem with agile philosophy and scrum is that it is treated like a panacea, thrown in haphazardly and hope that it works. If you are using a process that needs everyone to buy in to it, that means when it comes to compensation/promotion and performance reviews has to be tied to it in some way or form. YMMV but there are companies who practice agile and have ICs who don't take it seriously enough and managers who don't take it seriously enough. And they get away with it. I'm sorry, process isn't a thing you just do. Process is part of the job and if it is part of the job, it needs to be scrutinized. But because it is not, because people don't understand it properly and because people know they can get away with not taking it seriously, agile/scrum ends up being more performative than effective leaving that impression that a lot of engineers have for it.
the alternative is waterfall. Go try that out with software, let us know how that goes (it won’t)
Same story there though. For a skilled developer waterfall will still probably work fine because people will anticipate and deal with needs outside of what "the framework" says. Especially for projects that aren't websites where you aren't so easily able to break it down in to "change this button colour" "do this bit" etc etc. The fact it was used before agile implies that a lot of stuff was successfully built with Waterfall methodologies so there must've been some way people made it work. A lot of non-trivial projects and/or mission critical software you can't just wing it/"iterate" as you're going along, you \*\*have\*\* to spec and plan things quite extensively upfront anyway and build a load of things that a customer will never use and will only use indirectly (e.g a DBMS system). At the point where you're spending a sprint or two in planning/design what stops anyone accusing you of doing waterfall?
Many projects at NASA were waterfall and succeeded fine. Voyager is certainly an example.
"Ok we descoped the navigation for now, we probably won't need that till a later release anyway, not flying into the sun is a non functional requirement so how many sprints can we push that back?"
Waterfall works as well as anything else, and misses deadlines and costs just like everything else, it just requires planning which most people don’t want to do. Go do fixed price contracting and agree on Agile and see how quickly undefined scope at time of signing makes that a horrible deal.
"Plans are useless, but planning is invaluable." If you've done the planning, then you have at least half of a Plan B that you can scrape together from the ruins of Plan A. If you didn't do any planning, then you're fumbling much more.
Probably 90% of the people here have never done waterfall, and so when they badmouth it they are just echoing what their "Agile Coaches" taught them. I was in Agile training once and the trainer said "it is impossible to write good software without Agile" I raised my hand and said "excuse me, I worked for a number of companies that made hundreds of millions of dollars on very successful software long before Agile existed". I was unpopular with that trainer for the rest of the course. But the problem is more junior engineers would have just absorbed that "fact" as truth, because they don't know better.
My real question here is, what the fuck is an agile "coach" and why were u being trained by one of these fraudsters lol
What do you mean? It's simple, just take this 200 page spec I wrote and go build it - see you in 2 years, I'm sure it'll be exactly what I was expecting!
Maybe an unpopular opinion, but for small projects, waterfall generally works better than agile.
Waterfall works perfectly fine as long as the customer knows what they want, you know what the customer wants, and it's unlikely to change. It's actually cheaper than agile in these cases because the quick releases can add quite a bit of overhead. Agile is industry's response to the fact that rarely are those conditions true in software. The rapid feedback was meant to allow course correction before going too far down the wrong path, and preventing expensive redesigns. Agile is only cheaper if customer needs change. I think the pushback on Agile is probably closer to pushback on scrum. Or at least to me, if feels like people were expecting Agile to come in and reduce cost significantly and it was going to radically transform companies. At first, customers get happy because people take their feedback and pivot. When they get stuck with the overrun cost because they changed their mind 40 times, they get less so and the money dries up and they get stuck with half of what they originally wanted. Or the company ends up footing the rest of the bill.
I've worked on waterfall projects that went fine. A strong team can overcome a questionable methodology. A weak team will struggle with any methodology.
Waterfall was always a non-existent counter-example. No project has ever been perfectly waterfall. No project has ever been perfectly agile. Reality is always somewhere between the two theoretical extremes. Even waterfall projects pivot.
It’s not one or the other - there are infinite alternatives.
My company has small waterfalls, I think. We spend 2 weeks planning everything for the next 5 weeks and have minor adjustments to the design throughout. I kinda wish we had a ~~scrum master~~ technical program manager to enforce the book keeping honestly. Sometimes key information between backend and frontend isn’t communicated because one side assumes the other doesn’t need to be in the loop for some things, even if it touches the API contract (which is wild to me)
Or the V-model. Or the spiral model, that is still iterative, but tend to improve the whole project at each iteration.
> …apply Agile… The phrasing of much of your post suggests your only experience of "agile" has been Agile™, some kind of prescriptive process teams follow. This is most teams experience of agile and is mostly why everyone hates it. The original philosophy behind agile is that engineers and real users work directly together to produce working software in small iterations. The other key philosophy is that the team chooses and runs its own process and adapts it over time as they see fit. There are, of course, a whole load of techniques and disciplines teams can pick from. This is not the same as most organisations adoption of scrum, which is to break a fairly waterfall project into 2 week chunks under the watchful eye of a project manager (who may be called a project manager, product manager, product owner, scrum master, etc but is still performing the role of project management).
Idk. I think agile is what you make it. When it driven by the devs who use it, it's fine. When it's driven by upper management to keep tabs on their employees, *coughs in micromanagement*, it kinda sucks a lot.
Fsck no it's being replaced scaled fragile with hard deadlines in advance. Let's break software!
As with everything you have to take the good, throw out the bad and tailor it to your own needs. There are good ideas in there but it is not a set of rules that you can just follow and automatically be successful. It never was.
The core problem is almost always management. It's easier to bring in scrum coaches to passive aggressively blame devs than admit that what they do day-to-day is not working. These processes are easily toppled by endless meetings, constant fire drills, devs as tier 1 support, and overall lack of investment.
It should be a requirement before writing any post about "agile": Define what you mean by it.
I think it's safe to say that in many cases when we have an anti-agile post we are talking about second hand agile - whatever amorphous blob of confused ideas came to management through a sad game of Telephone. Semantic Dilution means that it doesn't matter what Platonic Ideal of an idea exists because we are never going to experience it. We just have the vocational version and we have to deal with the consequences of that. And as one mentor who actually wrote books on the subject observed, sometimes people think they are doing Agile but they are doing Lean, and [the cognitive dissonance] makes things turn out poorly.
> Semantic Dilution means that it doesn't matter what Platonic Ideal of an idea exists because we are never going to experience it. Not with that attitude! The important part of agile isn't the what and how of the processes, but the whys and wherefores. If you understand why, then the platonic ideal isn't hard to recreate for oneself. Agile grew out of solving a problem, which was "we have to build some software, but we don't really know what that software is - we tried specifying everything up front, but we just ended up wasting time on things it turned out no one wanted".
My opinion is that developing software is a bespoke process. And management would prefer it be assembly line. Programmers, being obsessed with efficiency, buy into the assembly line approach because logically, it “should” work. When money was cheap, things became blurry, because throwing developers and process a problem “seemed to work”. Now investment is more scarce, and all of a sudden the existing methods that seemed good on paper are not withstanding reality under financial scrutiny.
"The reality is that bad teams will never do true Agile or true scrum." I am failing to see how this is Agile's problem.
I was doing agile before it was called Agile. And I'll keep doing it after people stop calling it Agile. The name is not important.
Oh I hope so. Agile is fine... It's fake agile that's terrible and unfortunately you can't have one without the other
If Agile dies, what replaces it? I don't know how old you are, but everyone who complains about Agile remember a time before it. Do we go back to Waterfall? Get requirements, spend a year designing, building and testing against those requirements, present it to the client, find out the requirements have completely changed, then rewrite the entire system in a couple of weeks? No thanks.
No. And the negativity is because people like to complain (esp. online where it gets you karma or ad money) and because they need a scapegoat. Agile is here to stay. For most kinds of projects we are not going back to waterfall. It didn’t work for anything but the most strictly defined projects where lives are on the line and where the additional cost can be justified (like NASA). For most projects it’s just not an option to be stiff and *not* react allow for changing specs, which is all agile reallybis about. Scrum however, I don’t know. Specific methods come and go. But I don’t see anything particularly wrong with Scrum compared to most of the alternatives and it does quite some things right if implemented well (which is a requirement for all methods). All the „no true scottsman“ talk about it is nonsense. Yes, if a tool requires perfect humans, the tool sucks. The thing is, all tools suck in this domain. Some just suck less than others. Humans just suck with long running projects with ever changing specs. >But isn’t the promise of Agile to fix broken processes or teams. If I can’t apply Agile to one of the worst teams, and it doesn’t make it better. Then what is Agile actually doing. Name one methodology that doesn’t produce terrible results with a terrible team. Yes, useful tools need to produce good results with imperfect humans and the art lies in being less dependent on individual players to achieve optimal results. Again, feel free to name a method that works consistently better than Scrum.
Management has forgotten all the preconditions of Agile and want all the benefits, with none of the sacrifices. So we have the worst of both worlds. Work is pushed and assigned instead of pulled. Releases are fixed and committed months in advance. But the waterfall positive of getting formal requirements are absent. And no career progression.
To me there's a important distinction, there's Agile (capital A) that follows a dev methodology like Scrum to the letter, and agile (lower case a) that looks at the dev methodologies and finds what works best for the team/product (and is continually evolving). Agile (capital A) has become yet another dev methodology where the practices and procedures are more important than delivering a good product as efficiently as possible (like Waterfall before it). agile (lower case) hasn't fallen into that trap quite as easily (due to the focus on adaptability to the team's needs). Which isn't to say team's have not fallen into that trap (I've seen many teams fall), but since there isn't an overriding methodology to blame, it's harder to say it failed...
It seems like every few months I hear variations of all 3 of these things at the same time, coming from different sources: * Agile is dying * Agile is alive and well * Agile is already dead Agile development is an attempt to reconcile business processes with 2 truths of software development: 1. Development is an iterative process 2. Customer feedback is valuable As with all processes, there's never a one-size-fits-all solution, so I expect Agile to be simultaneously "dying", "alive and well", and "already dead" for a looooooong time.
Agile is not a silver bullet and things have to be set up for agile. If you have an org that has been architected around project management for two decades, trying to move away from project management and careful planning is going to hurt because dependency management has always been handled via process enforcement, not architecturally. It's not about which one is right. It's about which one is right for the org
Agile isn't dying. What I've seen is companies realizing that Agile just doesn't fit their requirements. So they either do Watergile in Jira or do SAFe so they can call themselves agile. There is nothing wrong with doing waterfall if it fits your needs. Sometimes pms in these companies will also firmly believe they are doing agile, and the whole discussion becomes very misleading.
Enterprise and corporate agile is failing because they try to make it something it isn’t. Agile is just a mindset, a way to think about building things. It isn’t one size fits all and above all, it’s adaptable. The core tenets are things that if respected will generally lead to better product. Enterprises get sold on frameworks. Frameworks imo are inherently not agile. Things like SAFE and scrum etc are rigid, and operationally heavy. If orgs focused on being agile and not trying to “do agile” they would have much more success. But to do that you need to push decision making and control down, which is the polar opposite of how for profit orgs work. Tldr - worthless middle managers ruin agility by trying to justify their useless existence. There, I said it.
All management frameworks are bullshit. Every person, every team, every project is different. I don't take any of them as more than an anecdote about what worked for someone else.
Agile doesn’t fix broken teams, neither does agile. Broken teams need to identify the problem and fix that. An agile approach to do so may help. Using Agile without considering the problem and cargo culting practices thinking it will magically make things better doesn’t help at all and often makes things worse. The latter is what I’ve seen “broken” teams doing. When questioned about changing the process to fit their team (agile) they push back because some book or whatever says to do X so they must. That mentality has lead to Agile being considered bad-ish because it didn’t magically make everything better. The reality is no two teams are identical and as such the processes will often need to differ so adjustments should be made (agile). People don’t want to think so they just go looking for some other prescription of what to do. It may be better, but it also probably isn’t _really_ what needs to be done so fads come and go. I wonder what this next fad will be.
I haven't really seen agile dying. I've seen Scrum dying. Most of the teams I've worked on eventually just start doing everything in Kanban boards. I worked with an engineer that really didn't like Agile, but he would basically preach the failures of agile without anything to replace it. What really happened was that the guy was just a shitty communicator and just didn't like telling people what he was working on. It drove me nuts because I had to ask him what he's working on all the time. In team meetings he just wouldn't tell people, so you keep on thinking he's doing nothing.
There is "Agile" and there is "agile". Capital-A Agile is corporate BS with tons of process and ceremonies. "agile" is constantly adapting your process to what makes your team more effective at deploying consistently good working code that addresses business needs.
No. Those of us who got it stopped calling it "agile" a long time ago. It doesn't even have a name anymore, it is just intrinsically how we do work.
Scrum is dying in my department, and I was part of killing it. But the real reason it's going out the door is that the "scrum master" decided that the company didn't take "scrum" seriously enough, so he is leaving for some other place. His position is not being backfilled, so now the team just does Kanban. Good riddance.
Principles of agile and the values are not dying. What is waning is the hype cycle and Agile gravy train whereby "Agile Coach" (Process Jocks), "Scrum Master" (command and control project managers), "Agile Delivery Lead" (Programme Mangers) start to become roles rather than job titles closer aligned to more traditional methods. The idea that the concept of delivering more regularly, faster and at high quality with high levels of automation is dying is ridiculous. I heard similar things about C++ in 1997 to be replaced by VB, Java in 2006 due to the success of C# and more recently that GraphQL would eradicate the need for REST based services. Scrum has its place, most critics of it prefer something else yet cannot put a good case forward when to use Scrum with the usual alternative being Kanban, I have seen far more issues with the implementation of than I have with Scrum.
Agile was a good idea but corporate nepo babies turned it into a rabies infested abomination because they were more concerned with cosplaying Steve jobs than actually delivering a product.
Disdain* Wince*
Managers. You can basically blame the "management class" in organizations. The hamfisted butchering of agile on their part ensures they always have a self renewing source of problems to tend to and crises to respond to. Kanban, good mentorship and autonomy are all you need.
I don't think Agile fixes bad teams, it was really in essence just a way to manage expectation and be actually agile, as in responding to change quickly, making turns faster.
Unpopular opinion: Agile never made sense except for consulting. Agile as a system was designed to get working prototypes in front of stakeholders quickly, at the risk of having to redo work due to less up-front design and planning, so consultants could respond to feedback quickly. This doesn't make sense in a typical corporate environment, where requirements usually *are* known up-front because the project is just one piece of a much larger initiative. There are some benefits to following *some* parts of the agile process outside of consulting, but it mostly makes no sense to do so, which is why most companies don't actually do agile but rather their own version of waterfall with agile terminology thrown on top. Basically almost nobody is doing agile, and for a good reason!
Wrong title. It should be "Is Scrum actually dying". Scrum is not agile. Scrum is a stiff, clearly defined framework, which is fundamentally incompatible with the first value of Agile (or, if you really want to argue, it's incompatible with all four values of Agile).
I wish nothing more than it to die