Dumb shits misapplying Agile because "we do standups" are dead. The entire point is and always has been to get the right people working on the right stuff in such a way that they can validate their assumptions and get customer feedback as soon as possible. Not how well you "do Scrum," "increase your velocity," or any of that trash. But actually applying these concepts breaks some managers' brains, and then we get the toxic crap people rant about.
The fundamental assumptions behind Agile are as valid as they were 25 years ago. The problem(s) are control freak managers who are incapable of coaching their teams into taking charge at the local level, devs "who just want to code" and not think for themselves about the larger context of the work, and bullshit "life coaches" using Agile coaching as a way to "break into tech" with no tech skills.
This is fundamentally a crisis of incompetence, where people are failing to implement what at its roots is a better way of working, in certain contexts anyway, because they fear giving power and control to the rank and file.
Not really in this case, because the manifesto was put out there from the beginning. People's incompetence to actually look at a website and read 4 phrases and doing fake agile is one thing. Agile is another.
Well, yes, but - it clearly doesn't work well to only come up with a good idea like that. After initial momentum, people often took it elsewhere, or abandoned.
Which tells you a lot about people out there. Maybe one can't force a shiny cool shoe on a feet incapable of using it well, even if it would be great in many aspects. Maybe we need something that is easier adaptable by real people making up real teams and organizations out there, not just cool books and trainings.
> The problem is not the lack of a good manifesto, is that people don't get it.
I think that is the problem though. It's still a system for human beings, if the majority of human beings aren't getting it, not sure it works.
I can etch my commandments on stone tablets and show some people, but unless they both understand what I'm trying to say AND actually believe it, I don't think my stone tablets are really doing anything.
This is somewhat ironic, considering the first point. If the process is not intelligible to most humans, maybe we should focus on refining/clarifying the process a bit?
Agile was introduced as a way for coders to empower themselves, and make changes to the software process for themselves.
But management came in and started mucking it up. They added more bureaucracy, added silly requirements such as mandatory velocity increases every sprint (numbers go up!). And added even more ceremony than was required with things like "Big Room Planning."
At one F500 company we were mandated to do retrospectives at the end of every sprint. The problems hampering the team's development were all external. 50% of the work was coding. The other 50% was chasing signatures, chasing information and requirements from other teams, dealing with security and inter-management politics, while stand-ups became hour long gab fests as coders tried on a daily basis to impress the attending management. We had no control over it the externals, and management didn't give a fuck.
Velocity was supposed to reach an equilibrium and then remain constant. Not over taxing the team is essential. If the meetings are a drag, there's something wrong. If people are burning out, there's something wrong. Those are very old lessons.
If you go to the customer and the customer doesn't answer your questions, that is obviously a huge problem. Then that customer is not ready to work agile. Maybe the situation can be salvaged, maybe not. If not, then apparently it is not the customer you would want as an agile team.
The manifesto intended that your customer can (and often will) be a proxy. You need a PM who gets out of the office, empathizes and understands clients, talks to customers. A big part of what's wrong with "agile" today is BS product managers.
> Individuals and interactions -- over processes and tools
That's why I proposed having a "build team" where you ask an individual to run your compiles for you, rather than dealing with an impersonal CI system. More Agile.
The old Manifesto sounds nice, but it's more a reaction (overreaction?) to some pathologies of the time than something that will get you very far without otherwise knowing what you should be doing.
Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere, and everywhere that it turns into a train wreck consisting of 45 minute daily stand-ups and 3 hour meetings arguing about T-shirt sizes or whether points are equivalent to time or not, the only explanation anyone ever proffers is, "well, you weren't doing Agile right".
No fucking shit. Nobody can do Agile right. I would argue that if something is so hard to get right, then it is effectively worthless.
The people who “do agile right” are out there. Just, like the agile manifesto says, they’re authoring their own processes. And because of that, they don’t have to call it agile - or really call it anything. They just go into work, figure out what needs doing, and take responsibility and do it.
I’ve worked in plenty of teams that did this sort of thing. All different. And at different scales - startups to big tech to game jams.
Agile works very well for small projects. When you have less than 10 developers it gets rid of a lot of overhead. However those are situations where project management isn't really hard and so they didn't need it. Companies doing projects with hundreds of thousands of developers are hurting because nobody can do project management. Agile seemed to help and so they jumped in. However painful experience with agile has shown there really was a good reason for all those processes agile go rid of! They are back to waterfall because at the end of the day they have real problems and all solutions end up pushing them to do a lot of pre-work planning to have a chance. Not that waterfall is good - it isn't - but everything else is worse as painful experience keeps showing.
Note that while we call what they are doing waterfall, in fact it isn't. All (nearly all?) projects are doing releases. They do go back and change things made in the past, just that the timeline is very long. They do discover things are not working and stop - sometimes they don't realize this in time to stop early, but they do stop.
What the world needs is a process for large numbers of people to develop software without stepping on each other. I do not have an answer to this problem - I'm not even sure if it exists.
Nobody can do Agile right because there's no one-size fits-all process. There are Agile approaches you can use and see if they work for your team.
The motto is "individuals and interactions over processes and tools" because if a process or tool isn't working for you, you're not supposed to use it.
It's like communism in the sense that it's defined with all the good quantities you'd want in a society or workforce and has several conflicting methods to get there. It's a set of principles that invites people to argue about how their approaches fit into them. Maybe that's the point.
My team spends half an hour per week on standups and about 2 hours every 3 weeks pointing stories. Any interaction beyond that is on an as-needed basis and mostly I'm just trusted to figure out what needs doing and do it. Agile is like communism - problematic, but mostly maligned by people who don't understand it using examples that are either made up whole-cloth or cherry-picked and then badly distorted in the retelling.
Yeah, kind of disagree with this. Compared to waterfall, agile is definitely an improvement.
And most teams get the core ideas right in my opinion: small, tight knit teams working closely together, with a "reduced amount" of process (yeah, think the number of meetings in agile is bad, in waterfall, meetings seem like crush you like a tsunami).
it's a lot less like communism and much more like a co-op or member-owned/lead organization - which can and totally do work. Think a bunch of farmers banding together to start a credit union vs. a big centrally planned org.
No, and Jeffries' analogy suffers the same strawman fallacy.
The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.
Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.
It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.
I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.
In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.
The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?
Agile is like communism. Lots of people like to hang external ideas to it. Some valid, some not.
Points, t-shirt sizes, figmas, etc... these are _tools_ and _processes_. Why the hell are you complaining about it when it says very clearly that you should focus on people and interactions?
Because I have real problems. People and interactions as a focus shows me where those problems are, and now I need solutions to solve them. Those tools and processes that agile often uses are the type of things I need to make my people and interactions work. (or at least that is their promise) I should not be developing my own tools when someone else already has some that works.
it's more than a vibe, the challenge is it's "Here's a bunch of things that can help; pick and use what works but don't be dogmatic about it". This is impossible to scale, as by definition it's anti-scale, which is why companies run into massive problems and pervert agile into whatever they have now.
Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way.
Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions.
In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people.
C'mon, it's not that hard. Doesn't need to have strict rules.
> Think about small improvements that can move the team
Which team? My team of 5 people or the entire project of several hundred? Focusing on the small teams finds a lot of local maximums that are very bad for the entire project. Many of the small changes small teams want to make are not possible because they would impact some of those several hundred other developers. Often small pain for us is much better than the pain our change would force on those others.
> It's for those who believe that skilled engineers are the true drivers of innovation and creators of meaningful products.
Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I do think developers have a major role to play, I don't think a company past a certain size would benefit from only devs making all decisions. A little specialization is OK when there is actually a useful task at hand.
There's innovation to be made on design or business side stuff as well. Maybe sort of lame to you, but it's helped me make stuff in the past.
Nothing to do with Agile btw, hopefully this doesn't sound like I'm pitching the tech world's private definition of capital A "Agile" with a different lens. Just a plea to appreciate that engineers aren't multitasking super gods.
I think we need to reverse the roles or how they play out in companies in day to day life. We need other people than engineers to _ask_ for certain changes or _make suggestions_. Not a product manager, who takes ideas from other departments as law and _makes demands_ out of that for the engineers, and then by the might of their management position push the changes through.
We could be better off with for example a designer talking directly to the engineers and asking them "Can you achieve XYZ?" then the engineers thinks for a bit and then reply "We can do XY, but Z would be way more effort and not worth it at this time.". Then they decide, whether to do XY even without Z. I don't see why designers or engineers should not be capable of sitting together to come to a decision, and I don't see, how there necessarily someone needs to be involved trying to force something down the throat of engineers.
Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.", instead of sales and marketing running off selling things that don't even exist yet. Then there needs to be acceptance and trust in the engineering team's competence. If that trust does not exist, we need to ask ourselves what the company is doing with such a team.
How I have come to loath the view, that engineers are like a band of little children, who will run off and go all crazy, if there is no manager ordering them around.
Some kind of overarching goals will need to be known or thought of. Those we can extract from having contact with the actual users, and from having great ideas, that we test out and get user feedback for.
In reality most engineers never have contact with the actual user in their daily job and as such, it is of course very far removed from being agile.
Just make the Designer the Product Manager, or get rid of the PM title entirely. After all, the process of navigating features and fixes to move the product forward is really a design job, not a management function. Also, the more the technical and design people understand the business side, including Marketing and Sales, the better. Ideally, technical and business sides work together, with design as the cartilage that holds them together.
I think every good experience I've had as part of a team, was because the business people, the designers, and the engineers were all respectful of each other, and had no power over one another. So I totally agree! Nothing stops that.
People always imagine every team has to be some little internal war, and I think the whole methodology-mill industry is built around that belief. People CAN'T compromise or work together, or at least we can't bet on that, so here's some process. That rubs me the wrong way. It's pretty patronizing, you're right that it's like treating engineers like children.
> Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.",
This is a totally respectful conversation with understanding on both sides. I might want to just make sure that the engineer in this scenario would be open to:
Marketer: "Feature XYZ is going to make a massive impact if we could get it with some clients this year before competitor X. Even feature XY without Z would beat their offering. What do you think?"
Engineer: "Ah yeah, I can see how that would be a really good advantage to have. I think XY might still be a bit hard to hit for EoY with the quality requirements we have, do you know precisely what they're planning?"
Marketer: "They are really only shipping feature X for the first month I think. No screenshots of Y in their announcement. Being the first mover would be good, even without Y."
Engineer: "We can make X happen, easy."
That conversation is also very respectful and everyone is adding valuable knowledge. It feels more realistic to me as well. Sometimes "no" isn't a great answer when "could we try for something at least?" means we could solve a lot of problems/make a lot of money. That's sort of my ideal way of working now. I'll hold everyone to the expectation that they're good at what they do, and they respect that I'm good at what I do.
That works when there is 1 engineer and one marketer. When there are hundreds of engineers and many marketers you risk the marketer unknowingly asks an engineer who isn't the right one and that person over promises not realized the full scope of the problem and how it will affect others who are also making their own promises.
I'd rather have a (high!) chance of that happening as a mistake low down on the hierarchy tree, where it's just the marketer (or maybe a region's marketing team) and two engineering teams involved that have unfuck their situation, than high up at the top where the C-suite only talks about the roadmap with the marketers and the bad decisions just wash over the whole company.
Don't think there's any solution that fits all scales of head counts in all fields of work. Middle management exists because employing 1000 people to each do something specific is inherently a hard task. Are they doing the thing, are they stopping other people from doing their thing, have they signed this form, have they got their benefits for this, are they getting paid the right amount, etc.
You actually save a lot of hassle with hierarchy, in the people-wrangling group of tasks.
But I still think some inefficiency at the lower level between motivated product teams with a few mandates each, is a better long term bet than assuming the same reasoning for middle management to exist applies to other fields. Engineering/design/marketing isn't people-wrangling so we shouldn't assume the same solutions that work for wrangling more people work for shipping more products.
That is why we have processes - so people know what promises they can make.
Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.
If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance.
If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process.
I've been on teams that transformed every little mistake into a lesson, burdening the whole team with cargo cult processes. Things we did because "once upon a time....". That's not healthy. I'm not implying that's your case, just showing another perspective.
"The 5 Laws of Holistic Development" at the bottom reeks of being written by someone who is bitter and falling into the "us vs them" trap.
I get it, I used to get really upset when business "overruled" engineering advise and decided to adopt a subpar solution, such as reaching for a 3rd party vendor or telling me what library they want me to use.
Then I realized that the job of a really good senior engineer is to offer options, be able to discuss the tradeoffs of each and to empower the business to make informed decisions that take ALL of the context into account: budgets, timelines, market pressures, planned shelf-life of the application, what "quality" means to end users etc.
It is the business' role to do cost benefit analysis. Engineers tend to get into the mindset of "there is one, 'right', way to do something." The reality is that there are many possible solutions to a given problem, each with their own tradeoffs. The business hired you to be able to provide solutions that align with business goals, objectives and budgets.
If a manager is telling you that they like a particular tool and would like you to consider it, that's a sign that you have failed at communicating. You have not communicated the fact that you have already explored various options, you have not communicated the fact that you understand that there are tradeoffs to be found among various options, you have not communicated that there are options at all. Most likely you did what engineers are inclined to do: you told them what you think is the 'right' way to do it, and they don't like that because it is too expensive and you didn't give them a single "out" so they are looking for them themselves (even though that was your job).
"Synergy: Value genuine, purpose-driven communication over forced meetings and rigid processes."
That's no different than "people over processes" from the original Agile manifesto.
"Adaptability"
What do you think 'agile' means?
"Courage: Foster an environment where taking risks and learning from failures lead to breakthrough solutions."
Courage is a value that companies either hold or they don't. At my current employer we embody this as "Normal sucks" in our core values. This tends to be a culture problem when companies don't value courage. I don't object to this one, but it suggests that the author is bitter having worked at companies that don't value this and want to maintain status-quo.
"Mastery: Cultivate engineers who combine deep technical proficiency with a clear understanding of the product vision."
Here's the catch-22 when it comes to business:
You want to hire a team of super experienced and talented engineers who can develop your application to an incredibly high standard in a very fast time.
Your first problem is that the labour pool for software is already tiny. That's why wages are high. So you have a hard time just finding these engineers in the first place. Once you've invested weeks into trying to recruit them, some Fintech company with a bigger budget snatches them up from under you.
Now say you did manage to hire a few. These are middle-aged individuals with families who cost a small fortune and have very low tolerances for bullshit. They will not work weekends. They may be willing to work the occasional overtime but only if that's a rare occurrence, they participated in getting the team into the weeds and the overtime is guaranteed to get the team back on track.
This senior engineer isn't looking to get promoted, they are already earning enough comp that more money no longer motivates them. Some of them are approaching retirement while others are looking to move into leadership positions.
Whereas you have less difficulty hiring someone with 5 years experience. This is a young person in their mid-twenties who has something to prove. They want to get promoted so they want to impress you. They are not married with children and so they are way more willing to give up weekends and churn out mediocre pull requests like it's no ones' business.
What the younger engineer needs is guidance and mentorship. They need the people that you want writing the code teaching them how to write the code that you want.
That's another culture issue. But hiring is difficult especially if the person doing the hiring is not an expert in the domain they're hiring for. This will be the case for virtually ALL tech startups that aren't being co-founded by an engineer ... you need to trust that the top engineering talent you are hiring is competent to do the tech hiring for you.
When I hear about Agile these days, it's almost always an excuse not to do the right thing. The last time it came up was someone resisting defining our company's product delivery process, which has always suffered from a lack of clarity. The time before that, it was someone saying "Let's be Agile about this", but meaning "let's do a shitty version of this, and pretend we'll come back to it later, rather than just moving on to the shitty version of the next feature."
The response that "you're not practicing Real Agile" may be true, but is unhelpful, as this is the norm rather than the exception. A consistent failure of any plan to succeed in its purpose after 25 years is a failure of that plan, not of the world, at least when the plan promises improvement on a shorter-than-generational timeline.
The only time I've ever seen Agile work is when the technical lead who practiced it was incredibly charismatic and forceful, and the team wanted to do what he said. Like magic. It worked great, and then the guy left, and the whole thing fell apart within months. But, I don't think what worked about that team was Agile per se, I think it was a unique individual leader that made it work, and it would have been just as successful without Agile.
I'm skeptical about methodologies. The force of the team and the company they're embedded in is so strong, it will overcome a generic system in most cases. I think you probably have to make an ad hoc solution that continually evolves, and have someone with rare abilities prune it and champion it. That is so harder. In all likelihood, muddling along is probably the realistic solution for most companies.
To a lot of folk, that's a feature! Capital A "Agile" is just sort of a pointer to "ayyy you've heard of other companies doing this" in a lot of people's minds.
I think we'd end up doing this no matter what. If it wasn't "agile" it would be "brisk methodology" or "go-minded development" or something. The reality is people sort of just like having hand-wavy terms that they definitely know other people have heard before, but have been given an ever shifting definition for.
To that point, I've started hearing people say "kanban" or "iterative planning", explicitly as opposition to agile. Yet, there are no actual changes to the process. All the people are still here, doing the same jobs with newly renamed meetings of the same length. But we are "fighting the agile lie" because we don't say agile!
IMO, teams figure out what works for them. Totally agree that methodologies are worth being skeptical about. If you hire sharp smart folks, they figure out a stable way of working. Muddling along isn't that bad if you have smart people muddling!
From the enterprise perspective, the purpose of Agile was to fail while giving the appearance of the greatest and most conscientious possible effort. "If it can't be done this way, it can't be done at all": time to gift more tens of millions of dollars to IBM and Oracle and Microsoft.
Not all that counts can be counted.
Not all that can be counted counts.
I hate Agile and I'm not going to try and sugar coat that. "We're drowning under the weight of clueless product leads, managers, and owners who've never written a line of code" That's why this still exists though not performant, because it some peoples entire entire careers now.
We don't care about productivity. We care about controlling labor. The more control you have over your labor the more you feel like you're doing things. Zero trust. Zero verification. That's just how it works.
I wish you the best of luck in fighting one buzzword with your new one. If it gains traction I'm sure it won't be used by the champions of your buzzword to sneak in their own desires instead of rigid adhereance to your definition.
I recently stumbled across a blog post from 2006 explaining all the problems commonly heard today about capital-A agile. That means we've spent at least 18 years faffing about letting conmen steamroll us that it can't be a con because there's a nugget of a good idea burred somewhere in there. Good ideas don't need branding. Branding is never a good idea.
We should just accept the euphemism treadmill is an iron law of the universe and every 10 years, we come up with a new term for insiders as the old term gets degraded.
The problem now is people use "agile" to mean anything from the 2001 agile manifesto meaning of the term to the 2024 F500 meaning and that's too long a span of time so the word has lost all communicative value. You can either engage in a fool's errand trying to drag the word back to the original meaning or accepting reality and letting people have it and come up with some new term like "katana development" or some bullshit that means essentially the same thing.
The "Observability" crew are good at this, I feel like every 10 years, there's a new coat of paint on essentially the same basic SRE concepts. Like how we went from Oriental to Asian American to AAPI, the mental burden of keeping up with these language changes serves as a basic shibboleth to who is paying attention enough to developments in the field.
I don't really see a real proposal on this site for something better, besides basically "just let the engineers do it" -- which sort of ignores the fact that lots of software is boring business line software where engineers are not SMEs on the usage, and lots of engineers don't want to spend their time becoming SMEs on the business rules of an ERP or a CRM.
(But really, small-a agile has been ascendant, better, and preferred in many places for at least a decade. That or related takes on agility like Shape Up.)
“We're drowning under the weight of clueless product leads, managers, and owners who've never written a line of code, yet they somehow dictate how software should be built.”
We’ve been through that, you leave coders alone without management and the create a new game engine with custom scripting language and state-of-the-art rendering pipeline and no games to go with it and then they get sad
(I’m only half joking to illustrate the point that extreme points of view are often silly)
I had a manager that secretly but obviously asked chatgpt how long a task should take and how to do it, then assign it to engineers. Can you imagine the state of their code?
I’ve never been a fan of Agile, but I find this rant superficial and crude.
My first thought was: I would never want to work with someone who writes a rant like this. Because to me it shows a lack of empathy and self-awareness, I miss any sense or the slightest hint of humility.
Maybe the same can be said of this remark, that’s for you to decide.
I happen to believe you get "quality software" by giving devs "ownership" of a piece of the software.
And by ownership I mean they come back to it on every revision of the software. They add the new features, they fix its bugs ... they can burn it to the ground if they like for reasons of technical debt (or because they feel like it).
"But what if that engineer leaves and no one else understands the code?" I hear you ask.
So what. We're smart. Put someone smart on it and they'll have it figured out soon enough. Chesterton’s Fence be damned, if the new dev wants to burn it down, let them.
You have to accept some risk in this field. But also you have to allow other's the responsibility. And in my experience, they'll rise to the occasion.
The groups I was in that claimed to be Agile rotated devs around the project like, um, cogs.
I mean, that works if you give them ownership of the budget and revenue targets.
That means if the product does not meet the revenue targets, the development team decreases and the development team has to decide which of their developers are losing their jobs.
That way, when the dev wants to burn it down, they are playing with their own consequences. Autonomy comes with consequences.
What actually works are the development models proposed by Royce, the spiral model, DSDM, XP, and something like kanban (pull based) with the manifesto -- all based on the same core essentials: build to the outcome, prioritize learning, build through the unknowns, and deliver what you learned, all in a long term risk and long term RoE weighted way.*
Scaled Agile for Enterprise (SAFE), SCRUM, etc., generally don't accomplish this. Any methods that take waterfall and relabel it and add roles until executives are bamboozled into thinking it's Agile™, don't.
While it's where "waterfall" came from, seems to be because someone stopped reading when they saw Figure 2.
Figure 2 is what not to do, he says it doesn't work. By contrast, he already understands principles such as prototype what works then document it, then build it again (Fig 7 Step 3 says make one to throw away) or ski with your customer (Fig. 9 Step 5 says keep tight with the customer), etc. Myth has it the DOD got excited about Figure 2 and ran with it. Most damagingly misunderstood software development paper ever?
the purpose of agile was to align the most requested feature work to the most expensive pay cycles. the purpose of devops was to get two for the price of one. everything else has been content marketing or people parroting whatever they thought would get them a raise.
Poe's Law is hitting me in the face right now. This is satire, right? I can't quite tell (seriously! please tell me)
If it is satire, it's quite subtle and well done. It references the old reasons why "Agile" was invented (current software development processes being bureaucratic and meeting-intensive, the new one will be lightweight and engineer-led).
If it is not satire, the juxtaposition is striking.
Dumb shits misapplying Agile because "we do standups" are dead. The entire point is and always has been to get the right people working on the right stuff in such a way that they can validate their assumptions and get customer feedback as soon as possible. Not how well you "do Scrum," "increase your velocity," or any of that trash. But actually applying these concepts breaks some managers' brains, and then we get the toxic crap people rant about.
The fundamental assumptions behind Agile are as valid as they were 25 years ago. The problem(s) are control freak managers who are incapable of coaching their teams into taking charge at the local level, devs "who just want to code" and not think for themselves about the larger context of the work, and bullshit "life coaches" using Agile coaching as a way to "break into tech" with no tech skills.
This is fundamentally a crisis of incompetence, where people are failing to implement what at its roots is a better way of working, in certain contexts anyway, because they fear giving power and control to the rank and file.
So true. 90% of Agile practitioners give the rest a bad reputation.
Um....
Isn't there some rule of thumb where some substantial threshold of popular regard defined it?
I mean I get if there is first principles derivation of a concept, but agilation is not that.
Agile is really a communal/socialist mechanism that is ruined the second management more than one later up injects themselves.
... Which is 100% of the time
Not really in this case, because the manifesto was put out there from the beginning. People's incompetence to actually look at a website and read 4 phrases and doing fake agile is one thing. Agile is another.
Mostly agree, but process is a way to tame the incompetence, if incompetence wins process has failed
Well, yes, but - it clearly doesn't work well to only come up with a good idea like that. After initial momentum, people often took it elsewhere, or abandoned.
Which tells you a lot about people out there. Maybe one can't force a shiny cool shoe on a feet incapable of using it well, even if it would be great in many aspects. Maybe we need something that is easier adaptable by real people making up real teams and organizations out there, not just cool books and trainings.
The most adaptable, flexible, maleable methodology is and will always be XGH.
https://medium.com/@dekaah/22-axioms-of-the-extreme-go-horse...
The old manifesto is fine, isn't it?
---
Individuals and interactions -- over processes and tools
Working software -- over comprehensive documentation
Customer collaboration -- over contract negotiation
Responding to change -- over following a plan
---
I still like it. The problem is not the lack of a good manifesto, is that people don't get it.
Anyway, I like that someone else apart from me is thinking about these things! I don't know, maybe we do need a new manifesto to shake things up.
> The problem is not the lack of a good manifesto, is that people don't get it.
I think that is the problem though. It's still a system for human beings, if the majority of human beings aren't getting it, not sure it works.
I can etch my commandments on stone tablets and show some people, but unless they both understand what I'm trying to say AND actually believe it, I don't think my stone tablets are really doing anything.
This is somewhat ironic, considering the first point. If the process is not intelligible to most humans, maybe we should focus on refining/clarifying the process a bit?
Agile was introduced as a way for coders to empower themselves, and make changes to the software process for themselves.
But management came in and started mucking it up. They added more bureaucracy, added silly requirements such as mandatory velocity increases every sprint (numbers go up!). And added even more ceremony than was required with things like "Big Room Planning."
At one F500 company we were mandated to do retrospectives at the end of every sprint. The problems hampering the team's development were all external. 50% of the work was coding. The other 50% was chasing signatures, chasing information and requirements from other teams, dealing with security and inter-management politics, while stand-ups became hour long gab fests as coders tried on a daily basis to impress the attending management. We had no control over it the externals, and management didn't give a fuck.
Exactly.
Velocity was supposed to reach an equilibrium and then remain constant. Not over taxing the team is essential. If the meetings are a drag, there's something wrong. If people are burning out, there's something wrong. Those are very old lessons.
I like it too, but was always a problem for me:
> Customer collaboration -- over contract negotiation
Customer is often too busy with his own work to collaborate meaningfully.
If you go to the customer and the customer doesn't answer your questions, that is obviously a huge problem. Then that customer is not ready to work agile. Maybe the situation can be salvaged, maybe not. If not, then apparently it is not the customer you would want as an agile team.
If the customer doesn't think their project is important, why should I?
hence why a contract is still important.
The manifesto intended that your customer can (and often will) be a proxy. You need a PM who gets out of the office, empathizes and understands clients, talks to customers. A big part of what's wrong with "agile" today is BS product managers.
> Individuals and interactions -- over processes and tools
That's why I proposed having a "build team" where you ask an individual to run your compiles for you, rather than dealing with an impersonal CI system. More Agile.
The old Manifesto sounds nice, but it's more a reaction (overreaction?) to some pathologies of the time than something that will get you very far without otherwise knowing what you should be doing.
Fair enough.
The original reaction for that pathology is "The Mythical Man-Month", it's what started everything. From my point of view, we're still man-monthin'.
The Agile folks just translated a personal reflection from Fred Brooks into a culture (then some companies made it into a cult).
Anyway. In your opinion, what the pathologies for _this_ time would be?
Agile is like communism - it sounds like a great idea. Except it never seems to work anywhere, and everywhere that it turns into a train wreck consisting of 45 minute daily stand-ups and 3 hour meetings arguing about T-shirt sizes or whether points are equivalent to time or not, the only explanation anyone ever proffers is, "well, you weren't doing Agile right".
No fucking shit. Nobody can do Agile right. I would argue that if something is so hard to get right, then it is effectively worthless.
The people who “do agile right” are out there. Just, like the agile manifesto says, they’re authoring their own processes. And because of that, they don’t have to call it agile - or really call it anything. They just go into work, figure out what needs doing, and take responsibility and do it.
I’ve worked in plenty of teams that did this sort of thing. All different. And at different scales - startups to big tech to game jams.
Agile works very well for small projects. When you have less than 10 developers it gets rid of a lot of overhead. However those are situations where project management isn't really hard and so they didn't need it. Companies doing projects with hundreds of thousands of developers are hurting because nobody can do project management. Agile seemed to help and so they jumped in. However painful experience with agile has shown there really was a good reason for all those processes agile go rid of! They are back to waterfall because at the end of the day they have real problems and all solutions end up pushing them to do a lot of pre-work planning to have a chance. Not that waterfall is good - it isn't - but everything else is worse as painful experience keeps showing.
Note that while we call what they are doing waterfall, in fact it isn't. All (nearly all?) projects are doing releases. They do go back and change things made in the past, just that the timeline is very long. They do discover things are not working and stop - sometimes they don't realize this in time to stop early, but they do stop.
What the world needs is a process for large numbers of people to develop software without stepping on each other. I do not have an answer to this problem - I'm not even sure if it exists.
Nobody can do Agile right because there's no one-size fits-all process. There are Agile approaches you can use and see if they work for your team.
The motto is "individuals and interactions over processes and tools" because if a process or tool isn't working for you, you're not supposed to use it.
It's like communism in the sense that it's defined with all the good quantities you'd want in a society or workforce and has several conflicting methods to get there. It's a set of principles that invites people to argue about how their approaches fit into them. Maybe that's the point.
Sounds like you expected it to be a silver bullet. Is there something in the agile manifesto that implies that?
My team spends half an hour per week on standups and about 2 hours every 3 weeks pointing stories. Any interaction beyond that is on an as-needed basis and mostly I'm just trusted to figure out what needs doing and do it. Agile is like communism - problematic, but mostly maligned by people who don't understand it using examples that are either made up whole-cloth or cherry-picked and then badly distorted in the retelling.
Yeah, kind of disagree with this. Compared to waterfall, agile is definitely an improvement.
And most teams get the core ideas right in my opinion: small, tight knit teams working closely together, with a "reduced amount" of process (yeah, think the number of meetings in agile is bad, in waterfall, meetings seem like crush you like a tsunami).
it's a lot less like communism and much more like a co-op or member-owned/lead organization - which can and totally do work. Think a bunch of farmers banding together to start a credit union vs. a big centrally planned org.
Co-operatives and worker self-management can and have existed under communism.
Bullshit. That's like claiming no one can play good football because the Cleveland Browns suck.
https://ronjeffries.com/xprog/articles/jatbaseball/
No, and Jeffries' analogy suffers the same strawman fallacy.
The proper analogy would be if no one knew the rules of football/baseball and everyone ended up playing Calvinball instead, then you could say that football/baseball was broken. If following the rules of football produced a product of its own if the rules were followed, it shouldn't matter that other people can follow those rules better.
Or you can point at Monopoly and the fact that so many people destroy the game by playing the "Free Parking gets the kitty" rule and use that as an excuse that Monopoly is a terrible game. Well, Monopoly is a terrible game, even as designed, so that one works.
It's not about how well people follow the "rules" of agile. It's that most everyone who tries doesn't understand the intent of agile.
I would argue that most of the attempts at codifying agile, from Extreme Programming through whatever the latest fad is, are all also wrong. That if you codify agile at all, you're missing the point.
In my experience, the OP article is correct: You need good developers on the team. That's it. That's the secret to success. The methodology you use is nearly irrelevant, though some methodologies do more harm than good.
The fact that XP's flagship project (C3) was an abject failure should have been a clue that maybe it wasn't as good as people want to believe it is. Maybe Kent Beck wasn't "doing agile right" either?
You are likening American football to communism? So which regime is Cleveland Browns, and which are the functional ones?
Agile is like communism. Lots of people like to hang external ideas to it. Some valid, some not.
Points, t-shirt sizes, figmas, etc... these are _tools_ and _processes_. Why the hell are you complaining about it when it says very clearly that you should focus on people and interactions?
Because I have real problems. People and interactions as a focus shows me where those problems are, and now I need solutions to solve them. Those tools and processes that agile often uses are the type of things I need to make my people and interactions work. (or at least that is their promise) I should not be developing my own tools when someone else already has some that works.
Oh, well if Agile is just a vibe then count me in.
it's more than a vibe, the challenge is it's "Here's a bunch of things that can help; pick and use what works but don't be dogmatic about it". This is impossible to scale, as by definition it's anti-scale, which is why companies run into massive problems and pervert agile into whatever they have now.
If that's the problem, then it's easy.
Do not think about the tools. Think about small improvements that can move the team in a more productive and sustainable (agile) way.
Simple things. Like putting a timer on long meetings until people get used to not extending it. Or putting a limit on the work pipeline between the developer and the tester to avoid overwhelming testing sessions.
In my opinion, you are not supposed to start from scratch. The chaos often comes from this "let's blank slate everything and adopt all agile things we can find". Once again, the same mistake of focusing on tools instead of interactions between people.
C'mon, it's not that hard. Doesn't need to have strict rules.
> Think about small improvements that can move the team
Which team? My team of 5 people or the entire project of several hundred? Focusing on the small teams finds a lot of local maximums that are very bad for the entire project. Many of the small changes small teams want to make are not possible because they would impact some of those several hundred other developers. Often small pain for us is much better than the pain our change would force on those others.
By team I mean "the people you interact with [the most]". Those who impact your routine and are impacted by you most directly.
As I mentioned before, there is no one size fits all recipe. And there are no multiple recipes of different sizes.
There are infinite variables a group of people can express. There is no point in making recipes, agile is about ideals.
> It's for those who believe that skilled engineers are the true drivers of innovation and creators of meaningful products.
Maybe the only thing I feel iffy about here. Just feels a bit naïve, I've worked together with some really talented designers. Also worked with some really talented product owners. Can't say I've agreed with every marketer/PR person I've worked with but they've saved our ass a few times. While I do think developers have a major role to play, I don't think a company past a certain size would benefit from only devs making all decisions. A little specialization is OK when there is actually a useful task at hand.
There's innovation to be made on design or business side stuff as well. Maybe sort of lame to you, but it's helped me make stuff in the past.
Nothing to do with Agile btw, hopefully this doesn't sound like I'm pitching the tech world's private definition of capital A "Agile" with a different lens. Just a plea to appreciate that engineers aren't multitasking super gods.
I think we need to reverse the roles or how they play out in companies in day to day life. We need other people than engineers to _ask_ for certain changes or _make suggestions_. Not a product manager, who takes ideas from other departments as law and _makes demands_ out of that for the engineers, and then by the might of their management position push the changes through.
We could be better off with for example a designer talking directly to the engineers and asking them "Can you achieve XYZ?" then the engineers thinks for a bit and then reply "We can do XY, but Z would be way more effort and not worth it at this time.". Then they decide, whether to do XY even without Z. I don't see why designers or engineers should not be capable of sitting together to come to a decision, and I don't see, how there necessarily someone needs to be involved trying to force something down the throat of engineers.
Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.", instead of sales and marketing running off selling things that don't even exist yet. Then there needs to be acceptance and trust in the engineering team's competence. If that trust does not exist, we need to ask ourselves what the company is doing with such a team.
How I have come to loath the view, that engineers are like a band of little children, who will run off and go all crazy, if there is no manager ordering them around.
Some kind of overarching goals will need to be known or thought of. Those we can extract from having contact with the actual users, and from having great ideas, that we test out and get user feedback for.
In reality most engineers never have contact with the actual user in their daily job and as such, it is of course very far removed from being agile.
Just make the Designer the Product Manager, or get rid of the PM title entirely. After all, the process of navigating features and fixes to move the product forward is really a design job, not a management function. Also, the more the technical and design people understand the business side, including Marketing and Sales, the better. Ideally, technical and business sides work together, with design as the cartilage that holds them together.
I think every good experience I've had as part of a team, was because the business people, the designers, and the engineers were all respectful of each other, and had no power over one another. So I totally agree! Nothing stops that.
People always imagine every team has to be some little internal war, and I think the whole methodology-mill industry is built around that belief. People CAN'T compromise or work together, or at least we can't bet on that, so here's some process. That rubs me the wrong way. It's pretty patronizing, you're right that it's like treating engineers like children.
> Similar for sales or marketing. They can come to the engineers, asking them: "We would like to sell feature XYZ. Are we ready for that?" then the engineers might say: "Nope, ask again next year.",
This is a totally respectful conversation with understanding on both sides. I might want to just make sure that the engineer in this scenario would be open to:
That conversation is also very respectful and everyone is adding valuable knowledge. It feels more realistic to me as well. Sometimes "no" isn't a great answer when "could we try for something at least?" means we could solve a lot of problems/make a lot of money. That's sort of my ideal way of working now. I'll hold everyone to the expectation that they're good at what they do, and they respect that I'm good at what I do.That works when there is 1 engineer and one marketer. When there are hundreds of engineers and many marketers you risk the marketer unknowingly asks an engineer who isn't the right one and that person over promises not realized the full scope of the problem and how it will affect others who are also making their own promises.
I'd rather have a (high!) chance of that happening as a mistake low down on the hierarchy tree, where it's just the marketer (or maybe a region's marketing team) and two engineering teams involved that have unfuck their situation, than high up at the top where the C-suite only talks about the roadmap with the marketers and the bad decisions just wash over the whole company.
Don't think there's any solution that fits all scales of head counts in all fields of work. Middle management exists because employing 1000 people to each do something specific is inherently a hard task. Are they doing the thing, are they stopping other people from doing their thing, have they signed this form, have they got their benefits for this, are they getting paid the right amount, etc.
You actually save a lot of hassle with hierarchy, in the people-wrangling group of tasks.
But I still think some inefficiency at the lower level between motivated product teams with a few mandates each, is a better long term bet than assuming the same reasoning for middle management to exist applies to other fields. Engineering/design/marketing isn't people-wrangling so we shouldn't assume the same solutions that work for wrangling more people work for shipping more products.
A company with hundreds of engineers and anyone of them can overpromise on some random feature?
Sounds like a widespread communication issue.
That is why we have processes - so people know what promises they can make.
Communication is hard - you can spend all day, every day in meetings and get nothing done and still fall behind in communication needed to make this large project work.
I've been there.
If it happens too much, then the process is not working. Do you agree? If it happens occasionally, then it's just variance.
If it is important to a team to know about this variance, then I could imagine someone would think of measuring it, temporarily, to understand the situation. But not turn the whole thing into a process.
I've been on teams that transformed every little mistake into a lesson, burdening the whole team with cargo cult processes. Things we did because "once upon a time....". That's not healthy. I'm not implying that's your case, just showing another perspective.
Absolutely, I love working with great designers / markets / etc.
"The 5 Laws of Holistic Development" at the bottom reeks of being written by someone who is bitter and falling into the "us vs them" trap.
I get it, I used to get really upset when business "overruled" engineering advise and decided to adopt a subpar solution, such as reaching for a 3rd party vendor or telling me what library they want me to use.
Then I realized that the job of a really good senior engineer is to offer options, be able to discuss the tradeoffs of each and to empower the business to make informed decisions that take ALL of the context into account: budgets, timelines, market pressures, planned shelf-life of the application, what "quality" means to end users etc.
It is the business' role to do cost benefit analysis. Engineers tend to get into the mindset of "there is one, 'right', way to do something." The reality is that there are many possible solutions to a given problem, each with their own tradeoffs. The business hired you to be able to provide solutions that align with business goals, objectives and budgets.
If a manager is telling you that they like a particular tool and would like you to consider it, that's a sign that you have failed at communicating. You have not communicated the fact that you have already explored various options, you have not communicated the fact that you understand that there are tradeoffs to be found among various options, you have not communicated that there are options at all. Most likely you did what engineers are inclined to do: you told them what you think is the 'right' way to do it, and they don't like that because it is too expensive and you didn't give them a single "out" so they are looking for them themselves (even though that was your job).
"Synergy: Value genuine, purpose-driven communication over forced meetings and rigid processes."
That's no different than "people over processes" from the original Agile manifesto.
"Adaptability"
What do you think 'agile' means?
"Courage: Foster an environment where taking risks and learning from failures lead to breakthrough solutions."
Courage is a value that companies either hold or they don't. At my current employer we embody this as "Normal sucks" in our core values. This tends to be a culture problem when companies don't value courage. I don't object to this one, but it suggests that the author is bitter having worked at companies that don't value this and want to maintain status-quo.
"Mastery: Cultivate engineers who combine deep technical proficiency with a clear understanding of the product vision."
Here's the catch-22 when it comes to business:
You want to hire a team of super experienced and talented engineers who can develop your application to an incredibly high standard in a very fast time.
Your first problem is that the labour pool for software is already tiny. That's why wages are high. So you have a hard time just finding these engineers in the first place. Once you've invested weeks into trying to recruit them, some Fintech company with a bigger budget snatches them up from under you.
Now say you did manage to hire a few. These are middle-aged individuals with families who cost a small fortune and have very low tolerances for bullshit. They will not work weekends. They may be willing to work the occasional overtime but only if that's a rare occurrence, they participated in getting the team into the weeds and the overtime is guaranteed to get the team back on track.
This senior engineer isn't looking to get promoted, they are already earning enough comp that more money no longer motivates them. Some of them are approaching retirement while others are looking to move into leadership positions.
Whereas you have less difficulty hiring someone with 5 years experience. This is a young person in their mid-twenties who has something to prove. They want to get promoted so they want to impress you. They are not married with children and so they are way more willing to give up weekends and churn out mediocre pull requests like it's no ones' business.
What the younger engineer needs is guidance and mentorship. They need the people that you want writing the code teaching them how to write the code that you want.
That's another culture issue. But hiring is difficult especially if the person doing the hiring is not an expert in the domain they're hiring for. This will be the case for virtually ALL tech startups that aren't being co-founded by an engineer ... you need to trust that the top engineering talent you are hiring is competent to do the tech hiring for you.
When I hear about Agile these days, it's almost always an excuse not to do the right thing. The last time it came up was someone resisting defining our company's product delivery process, which has always suffered from a lack of clarity. The time before that, it was someone saying "Let's be Agile about this", but meaning "let's do a shitty version of this, and pretend we'll come back to it later, rather than just moving on to the shitty version of the next feature."
The response that "you're not practicing Real Agile" may be true, but is unhelpful, as this is the norm rather than the exception. A consistent failure of any plan to succeed in its purpose after 25 years is a failure of that plan, not of the world, at least when the plan promises improvement on a shorter-than-generational timeline.
The only time I've ever seen Agile work is when the technical lead who practiced it was incredibly charismatic and forceful, and the team wanted to do what he said. Like magic. It worked great, and then the guy left, and the whole thing fell apart within months. But, I don't think what worked about that team was Agile per se, I think it was a unique individual leader that made it work, and it would have been just as successful without Agile.
I'm skeptical about methodologies. The force of the team and the company they're embedded in is so strong, it will overcome a generic system in most cases. I think you probably have to make an ad hoc solution that continually evolves, and have someone with rare abilities prune it and champion it. That is so harder. In all likelihood, muddling along is probably the realistic solution for most companies.
To a lot of folk, that's a feature! Capital A "Agile" is just sort of a pointer to "ayyy you've heard of other companies doing this" in a lot of people's minds.
I think we'd end up doing this no matter what. If it wasn't "agile" it would be "brisk methodology" or "go-minded development" or something. The reality is people sort of just like having hand-wavy terms that they definitely know other people have heard before, but have been given an ever shifting definition for.
To that point, I've started hearing people say "kanban" or "iterative planning", explicitly as opposition to agile. Yet, there are no actual changes to the process. All the people are still here, doing the same jobs with newly renamed meetings of the same length. But we are "fighting the agile lie" because we don't say agile!
IMO, teams figure out what works for them. Totally agree that methodologies are worth being skeptical about. If you hire sharp smart folks, they figure out a stable way of working. Muddling along isn't that bad if you have smart people muddling!
From the enterprise perspective, the purpose of Agile was to fail while giving the appearance of the greatest and most conscientious possible effort. "If it can't be done this way, it can't be done at all": time to gift more tens of millions of dollars to IBM and Oracle and Microsoft.
Not all that counts can be counted. Not all that can be counted counts.
I hate Agile and I'm not going to try and sugar coat that. "We're drowning under the weight of clueless product leads, managers, and owners who've never written a line of code" That's why this still exists though not performant, because it some peoples entire entire careers now.
We don't care about productivity. We care about controlling labor. The more control you have over your labor the more you feel like you're doing things. Zero trust. Zero verification. That's just how it works.
Agile is dead long live (fr)agile.
I wish you the best of luck in fighting one buzzword with your new one. If it gains traction I'm sure it won't be used by the champions of your buzzword to sneak in their own desires instead of rigid adhereance to your definition.
I recently stumbled across a blog post from 2006 explaining all the problems commonly heard today about capital-A agile. That means we've spent at least 18 years faffing about letting conmen steamroll us that it can't be a con because there's a nugget of a good idea burred somewhere in there. Good ideas don't need branding. Branding is never a good idea.
We should just accept the euphemism treadmill is an iron law of the universe and every 10 years, we come up with a new term for insiders as the old term gets degraded.
The problem now is people use "agile" to mean anything from the 2001 agile manifesto meaning of the term to the 2024 F500 meaning and that's too long a span of time so the word has lost all communicative value. You can either engage in a fool's errand trying to drag the word back to the original meaning or accepting reality and letting people have it and come up with some new term like "katana development" or some bullshit that means essentially the same thing.
The "Observability" crew are good at this, I feel like every 10 years, there's a new coat of paint on essentially the same basic SRE concepts. Like how we went from Oriental to Asian American to AAPI, the mental burden of keeping up with these language changes serves as a basic shibboleth to who is paying attention enough to developments in the field.
Ironically “Holistic Development” reads like it’s just the agile manifesto rephrased to remove any mention of the customer.
I don't really see a real proposal on this site for something better, besides basically "just let the engineers do it" -- which sort of ignores the fact that lots of software is boring business line software where engineers are not SMEs on the usage, and lots of engineers don't want to spend their time becoming SMEs on the business rules of an ERP or a CRM.
Bertrand Meyer wrote a very good book called Agile: the good, the bad and the ugly.
Which really, gives a good balanced view of the practices and the hype.
Reading, is what removed the veil in my eyes.
"Agile is dead. Long live agile!"
(But really, small-a agile has been ascendant, better, and preferred in many places for at least a decade. That or related takes on agility like Shape Up.)
“We're drowning under the weight of clueless product leads, managers, and owners who've never written a line of code, yet they somehow dictate how software should be built.”
We’ve been through that, you leave coders alone without management and the create a new game engine with custom scripting language and state-of-the-art rendering pipeline and no games to go with it and then they get sad
(I’m only half joking to illustrate the point that extreme points of view are often silly)
I had a manager that secretly but obviously asked chatgpt how long a task should take and how to do it, then assign it to engineers. Can you imagine the state of their code?
I’ve never been a fan of Agile, but I find this rant superficial and crude.
My first thought was: I would never want to work with someone who writes a rant like this. Because to me it shows a lack of empathy and self-awareness, I miss any sense or the slightest hint of humility.
Maybe the same can be said of this remark, that’s for you to decide.
Same. I agree with most of what is said, but this is terrible way to deliver it.
OP I feel like you should quit your job now and find a better place.
I happen to believe you get "quality software" by giving devs "ownership" of a piece of the software.
And by ownership I mean they come back to it on every revision of the software. They add the new features, they fix its bugs ... they can burn it to the ground if they like for reasons of technical debt (or because they feel like it).
"But what if that engineer leaves and no one else understands the code?" I hear you ask.
So what. We're smart. Put someone smart on it and they'll have it figured out soon enough. Chesterton’s Fence be damned, if the new dev wants to burn it down, let them.
You have to accept some risk in this field. But also you have to allow other's the responsibility. And in my experience, they'll rise to the occasion.
The groups I was in that claimed to be Agile rotated devs around the project like, um, cogs.
I mean, that works if you give them ownership of the budget and revenue targets.
That means if the product does not meet the revenue targets, the development team decreases and the development team has to decide which of their developers are losing their jobs.
That way, when the dev wants to burn it down, they are playing with their own consequences. Autonomy comes with consequences.
it was never alive to begin with. certainly not in the real world.
What actually works are the development models proposed by Royce, the spiral model, DSDM, XP, and something like kanban (pull based) with the manifesto -- all based on the same core essentials: build to the outcome, prioritize learning, build through the unknowns, and deliver what you learned, all in a long term risk and long term RoE weighted way.*
Scaled Agile for Enterprise (SAFE), SCRUM, etc., generally don't accomplish this. Any methods that take waterfall and relabel it and add roles until executives are bamboozled into thinking it's Agile™, don't.
This is where waterfall probably came from:
- Royce, 1970: https://www.praxisframework.org/files/royce1970.pdf
While it's where "waterfall" came from, seems to be because someone stopped reading when they saw Figure 2.
Figure 2 is what not to do, he says it doesn't work. By contrast, he already understands principles such as prototype what works then document it, then build it again (Fig 7 Step 3 says make one to throw away) or ski with your customer (Fig. 9 Step 5 says keep tight with the customer), etc. Myth has it the DOD got excited about Figure 2 and ran with it. Most damagingly misunderstood software development paper ever?
- Spiral model: https://en.wikipedia.org/wiki/Spiral_model
Prototypes with iterative scope and rigor until it's good enough. Sound familiar?
- DSDM: https://en.wikipedia.org/wiki/Dynamic_systems_development_me...
Look at the 8 principles and especially the core techniques...
- XP: https://en.wikipedia.org/wiki/Extreme_programming
"Pairing" is why LLM code copilots "work".
* Easy to say.
the purpose of agile was to align the most requested feature work to the most expensive pay cycles. the purpose of devops was to get two for the price of one. everything else has been content marketing or people parroting whatever they thought would get them a raise.
Poe's Law is hitting me in the face right now. This is satire, right? I can't quite tell (seriously! please tell me)
If it is satire, it's quite subtle and well done. It references the old reasons why "Agile" was invented (current software development processes being bureaucratic and meeting-intensive, the new one will be lightweight and engineer-led).
If it is not satire, the juxtaposition is striking.
No satire
The idea seems to be to replace a set of empty keywords with another.
> The "agile" development we're stuck with today is a joke
Are we really? The whole industry has moved on a good 10 years ago.
If you feel stuck with agile, you should probably change job.
Moved on to ... what?
[flagged]