There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere.
In that: if it fails, it is only considered evidence that you were not doing it enough.
The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
It's also true for Cloud providers; that they're not suited for certain tasks is no longer considered an engineering trade-off, it's that you architected your solution wrong, and the answer is to buy even more into how the platform works.
If your microservices become slow or difficult to debug, it's never that fatter services could have been preferable, it's that we didn't go hard-enough into microservices.
If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.
My favorite Agile-ism is when Agile is defined as “the process that works for the team”.
If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!
My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting.
"We're going to do agile by following this rigid process" is an oxymoron.
Wow I guess we were actually agile all along, by virtue of being a team that defines our own processes. Yet I don’t think we’ve ever used the word agile once in any of our meetings.
> My favorite Agile-ism is when Agile is defined as “the process that works for the team”.
What compels you to believe it isn't?
I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently".
What leads you to believe Agile implies a fixed set of precise, rigid rules?
The problem is a disconnect between management and those who build.
My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts".
As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).
This is the problem with 'Agile', and why people refer to it as "Capital-A Agile".
As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you. They want to stay in business, so they need to make sure they have something to sell.
That's the dysfunction - a company that is forcing this laborious process on you, rather than giving teams the autonomy to figure out how they best work.
Agile works best as a toolbox of practices you can adopt, mix, and match to solve whatever problems you have. Do you need to work to a fixed schedule, or provide delivery estimates? You should probably have a way to regularly estimate your work. Are you struggling to actually ship and do things? Maybe it would be useful to plan things on a smaller, more frequent cadence.
> As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you.
I would go as far as to claim the problem is middle management types, who feel pressured to adopt buzzwords and want to micromanage things to cultivate an image of control and progress to justify their role.
It's the same type that brags about scrum but don't even bother to show in standup meetings.
It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.
I actually think OP's criticisms apply mostly to Scrum. Scrum is well defined but its adherents' wont hear a critical word said about it. "You just werent doing it right" even when you were doing it precisely as described.
> It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.
I don't really agree. The set of principles are quite straight forward. It's things like delivering software frequently, accommodating new requirements, continuously looking into improving processes, business types and developers working together, etc.
Then you have concrete executions like scrum vs kanban. Agile doesn't specify one or the other. Retrospective meetings are popular, but aren't specified by Agile per se.
I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles(https://agilemanifesto.org/). Values are not right or wrong, they are just values you agree to or don't.
The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called process experts under pressure from management which does not know any better. The authors of Agile Manifesto have frequently said the concept of Agile has been badly twisted.
I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies.
The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”.
The manifesto has become a safe retreat that agile fans bring out whenever someone has criticisms about real-world agile; Whenever someone has a complaint about Agile as implemented in the real world, someone will show up and try to defend it by pointing out that The Agile Manifesto doesn’t contain the specific thing they dislike.
The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized. We can’t keep returning to it as some safe home base that shields Agile from any criticism.
"Industrial" cannot rely on any one individual. You have to be able to scale your process (or whatever), duplicate your process, have your process survive multiple people leaving, and so on.
Which means that any true agile cannot be industrial. And therefore any industrial agile cannot be true to the principles of the Agile Manifesto.
At this point I equate the Agile Manifesto to the Communist Manifesto. Sounds nice when you read it; in practice it is an absurd endless source of suffering.
>The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized.
Yeah, spending the amount of words in this thread trying to diagnose or complain about this simple problem in abstract strokes seems silly and frankly confounds me when considering the amount of time people wish to waste discussing the problem.
As with political parties, bad gentrification in cities, and all the rest, once money and consultants turn things into an industry you're pretty much fucked.
People should just immediately stop taking people with conflicting interests at face value when they talk. Stick to concrete details when you talk about stuff, avoid industry terms, don't let them turn things into abstract and general discussions. It only feeds the trolls (consultants) when you even complain generally about it.
Fight it with your day-to-day actions, not so much with your words. And then let it die in silence, it will die faster (I'm referring to any tech topic captured by consultants and monied interests).
I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.
I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing the blame, and blaming the system (or the god).
I suspect there a very abstract game theoretic conversation that could be had about this :)
> I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.
Yes, and that's because God, spirituality and religion make fuzzy truth claims and can be used to argue for and justify anything. God can be used as the excuse to start a genocide and the inspiration to stop it, spirituality can be the way for wounded people to work with their trauma and the vehicle for people without scruples to sell horoscopes or some shit, religion (the same religion) was used to justify and uphold slavery and to fight for its end.
They are containers for our politics, our lifestyle, for who we are and for who we hope to be.
The Agile manifesto is a series of statements in the form "we like X more than Y." It doesn't say anything. To make it mean anything you have to project onto it a framework of interpretation that exists independently of the "sacred text" itself.
So yeah, they are similar, and that's because Agile, sociologically, works like a religion.
when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and expect him/her to become as good as the pro. Programs and processes are very individual tailored.
I still doubt that your average person would see any real health benefits from eating only meat, even if they ate enough organ meats to actually get all their vitamins and minerals (the lack of fiber is a particular concern) but I guess you're right that there's a version of an "all meat died" that doesn't promptly kill you through malnutrition, you got me there.
A process that fails when you slightly diverge is process that fails. Because all human orgs diverge from stated process here or there. Including army which puts huge amounts of resources into making people comply with everything.
It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming.
If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug because there are not enough tests ... you write more tests don't you? Why would a method be forgiving when compilers and reality itself aren't?
But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.
My evidence is that I was on a team that was not overly controlled by management and had clever people in it without any instant attitudes of rejection so they adapted to it. We produced updates bi-weekly and we had a huge backlog of stupid features which we were never going to get round to - we were able to get the important things done and it was one of the best feelings I've ever had about work.
Since then I've been on teams with any number of pathologies. From developers it is sometimes the desired to be special - those ones who want to work on their bit of the code and not let anyone else touch it. From managers it's things like forcing the way stories are split so that they're always too large and can never fit into a sprint - because they think that everything must be a "user visible change". Management types also sit in retrospectives and use them to crap on everyone. Product managers demand features which they don't know will really interest customers and are inflexible about them - they want "everything" just in case and that delays the work and deletes any chance of a feedback loop.
The good agile feeling came from being able to have control and be successful. When it's messed up, you're out of control and cannot avert disasters. Whatever method you want to call it, I think we need to feel we're in control enough to succeed.
What is the chance that you've perfectly captured every aspect of the situation that led to success? Versus, what is the chance that you were lucky enough to be in situations where a multitude of factors, both appreciated and unappreciated, combined to lead to success?
There are a million possible reasons for failure, but here is a very easy one: It doesn't matter how good you feel about the development process, if the company has the wrong objective. You will still end up being frustrated, and failing. Of course this will have all sorts of pathological and uncomfortable ramifications.
So while it is easy to say, "just act this way and you'll have success". You're not actually appreciating all the hidden elements that allow any hope of acting that way. You've been lucky enough to be in situations where it happened to work (ie. the rain dance made rain), but that does not mean it's actually representative, or that the prescription actually captures the critical information needed to ensure success for other people. Instead, you've described a rain dance.
You're right - there isn't one way to do things or one way that always works. There are issues that are outside a team's control, for example, that make it an impossible struggle. If you're rigidly forced to do something and cannot adapt then you're ... not really agile. But you have to understand why you're doing what you're doing and keep adjusting to see what works for you.
#1 IMO is that if the company you're in is non-agile in its general attitude, which is influenced by its own customers, then everything is geared against you.
That isn't to say that something like Kanban might not be usable or better than no plan at all but certainly scrum is not some universal solution.
> It's usually because your company doesn't fundamentally want it.
BINGO. Managers and execs want (or get sold on) "agile" but only want it to affect the structure and processes for the very lowest-level workers. They don't want to change the organization or what they do, and odds are those are really bad and won't let most systems like this, agile or otherwise, function properly.
(The big secret is there's no framework like this that "works" for fixing broken organizations; there are [rare!] well-led well-managed organizations where damn near any halfway-reasonable system they choose will work, so if they decide to do Scrum or whatever in places like that it'll work just fine—and then there's everyone else)
Which also conveniently makes you spend more money on tokens.
With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you.
Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies.
Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again and again making you consume tokens. Still bad? Here’s a way to easily spin up multiple agents at once so you can delegate work. Still bad? Here’s a new service that will automatically review code. Still bad? Maybe a biggger more expensive model will help.
>> With agile, at least no one was charging you for it.
Depends. There are companies [1] making loads of money out of it. Charging for certification and imposing the idea that either you are certified, or you are going to fail. They are even eating the lunch of PMI, as PMI (PMBoK) is turning into an Agile manual.
Where I work is being expended literally millions per year in Agile.
> With agile, at least no one was charging you for it.
Charging people for Agile via his company ThoughtWorks (which sold for 785M) is how Neville Roy Singham made the money to fund far left groups in the US from his base in China.
If it's an internet-required smarthammer without a handle that instead hits out on voice prompt, sometimes without enough or with too much force, sometimes knocks the nail out of the way and punches a hole, and sometimes hits you in the face, then yeah
> If it's an internet-required smarthammer without a handle that (...)
A suitable comparison would be to be faced with a nailgun and proceeding to criticize it on the grounds it doesn't have a handle, it doesn't pull nails, and it requires electricity to run.
While you complain about those detailed those using nailguns are an order of magnitude more productive at the same task, and can still carry a hammer in their toolbelt.
Well, no, the examples are basically the same. A wifi nailgun that sometimes shoots a nail straight through the board, doesn't shoot one at all, shoots it randomly to the side, shoots you with it, etc.
You can use brick as hammer. Doesn't mean brick makes a good hammer or that person who tells that brick is a bad hammer and doesn't work from them is bad workman.
> if it fails, it is only considered evidence that you were not doing it enough.
Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever?
I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. So I can't really say if agile (or any of its particular variants) work or not. I have not seen honest experiments properly run.
> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed.
If that's true, wouldn't it point at the process being impossible to implement?
It is a myth. There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.
It signals to me that the process doesn't work in reality. You are better off doing something else.
It doesn't really fail any worse than other inflexible top-down process mandates from management.
That's where it becomes "impossible to implement"—you can't impose it as a cookie-cutter solution driven and controlled by management, and get much good out of it, yet that's the usual way it manifests in the wild. But that's not so different from anything else management might push in its place.
> There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.
"Agile" is a very vague and shapeless idea which is hard to design an experiment for; but I would settle for clean experiments with well-defined methodologies/frameworks/strategies/whatever. Specifically, for scrum or kanban. Whenever people talk about these two, they seem to misunderstand them more often than not.
>It signals to me that the process doesn't work in reality. You are better off doing something else.
Whatever you do instead, you will also cargo-cult to some degree and fail equally as badly at.
For all the "You're doing it wrong!" I've seen in industry with respect to agile, I've also felt that every team I've been part of that did some version of it, seemed to function OK. I always found the "Agile Manifesto" a completely silly nothing-burger, but always understood the core tenet of 'agile' to be "employ tighter feedback loops", which... is sort of mostly how it plays out in practice??
I've belonged to numerous teams that followed some form of agile, to varying degrees of success (or failure).
The shape of what Agile meant in each of those teams was very different from one another. It would be disingenuous to say "the ones that succeeded were truer to Agile".
If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless. A single sentence, as useful a tenet as it may be, does not a philosophy make. And this idea was not even new by the time the Agile manifesto came out (as explained in the linked blog post).
> If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless.
Not just that, Royce's original paper that coined the term "waterfall" in 1970[1] can be summarized as "employ tighter feedback loops" compared to top-down design (figures 2-4 in the paper).
> In that: if it fails, it is only considered evidence that you were not doing it enough.
I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.
Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".
This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.
> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?
If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?
Yes, but on the other hand, there's
https://www.reddit.com/r/ididnthaveeggs/, which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.
An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it.
Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? More revenue? Fewer bugs? This is never defined up front and they shift depending on the person being asked. This means you can never actually determine if someone "left out an essential ingredient".
The irony is that Agiles own favoured development practice (TDD) cannot be applied to Agile itself. There is no acceptance test for the process, you can't iterate on something that isn't measured and has no defined outcome.
/r/ididnthaveeggs works because everyone agrees on what the dish should have been.
> Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly".
That's not true for the way I understand agile. The way I understand it, the testable outcome is whether the principles of the agile manifesto are satisfied
For example, is your highest priority to satisfy the customer through early and continuous delivery of valuable software? If not then you're not agile.
I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter!
These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful experiences.
Apparently whatever it is they're doing involves a lot of meetings and little actual flexibility? The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Every team and every business is different and you have to iterate to arrive at whatever will work best for you. That's possibly the one most important point, IMO. Dropping the things that don't work is a key part of that!
Eric Brechner of Microsoft (of all possible places...) gives a great talk on his team's approach, and I've had good experiences using it as a starting point: https://www.youtube.com/watch?v=CD0y-aU1sXo
But again, every team is different. Even the greatest possible theoretical approach is only a starting point.
And like with Switzerland vs North Korea, I guess the key thing is how much ownership of the process those subjected to it have?
> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?
Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.
> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP
Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.
In many contexts "already tried" does not apply under "this and this conditions" though.
You can try the same thing under different contexts and it will probably yield different results (at least in any context that is organizational / social)
But is it wrong? If you're in a plane and it's on the ground and it starts moving but it doesn't take off, the answer really is to move faster. If you press a button and it doesn't activate, the answer might just be to press harder. If you're running away from a bear but it's catching up to you, the answer really is run faster. If you don't, you're dead.
So the problem with that is that it's an oversimplification in an attempt to sound smart and insightful and can't be used as a general principle to reason as to whether or not you need to double down to see results.
This reminds a lot of this: "I'm going to try this extremely difficult pastry recipe at home, but I'll use margarin insted of butter because <idiot reason> and a teasponn of stevia instead of the prescribed 200 g of sugar for <another idiot reason>."
> In that: if it fails, it is only considered evidence that you were not doing it enough.
> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
This isn't some religious premise, it's the lesson of bitter experience. It's like how when two trains crash into each other the inspectors start by looking for which one went through a danger signal, rather than questioning whether signalling systems work.
Sure. Occasionally there really is a problem in your signalling system. Even more rarely there's a fundamental design flaw.
If and when I see actually-doing-agile fail, I'll change my mind. But so far I've seen a direct correlation between the extent to which an organisation was actually-doing-agile and the effectiveness of that organisation, across a wide range of industries/environments/countries.
> In that: if it fails, it is only considered evidence that you were not doing it enough.
Seen this multiple times
The problem is agile as in the original manifesto was an ethos, not a process.
Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos.
High performing teams are already doing agile, following the ethos without attempting to be agile. High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.
> High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.
This is also my observation. I compare it to McDonalds vs a star restaurant. Put the top chef of a star restaurant in McDonalds and he will perform average. Put a McDonalds member in the star restaurant and he will perform badly.
The amount of process needs to be tweaked to your team. Ideally, you can give your star players more freedom.
I feel like Agile is just a tool. You adopt it, or parts of it and see if it works. If it does for your org awesome, if not for your org, try something else.
Organizations are all different IMO (even if slightly), and you gotta try things and move on.
Is it the fault of Agile if it doesn't work? I don't know, I'm more interested in finding what works.
"If you failed it is only evidence that you were not doing enough."
is the core principle the whole self-help, self-improvement and large parts of weight loss and health industries always have been based on.
> In that: if it fails, it is only considered evidence that you were not doing it enough.
In my experience, when it fails there's always someone to tell you that you were just doing Agile wrong and they've got a different brand of Agile and a training course to sell you
reminds me of the impossible fight for when someone forces themselves into a project and prescribes "industry standard" off-the-shelf solutions, to a problem that requires an engineered custom solution.
And when the final product isn't fit for purpose, what do they say when their decision becomes visible?
the off-the-shelf solution is never at fault. It's your execution. You architect your solution wrong. You didn't configure it right. You just didn't adopt it fully enough. The answer is always to dig deeper into the solution and leverage more of its features.
The problem is that the off-the-shelf solution doesn't even have the right feature set needed for the job in the first place.
Yup. Agile definitely suffers from the "nobody ever tried Communism correctly" argument. As far as I'm concerned Agile is: A) nearly impossible to get right, and B) not particularly helpful at unfucking poorly run projects.
It's definitely not a magic bullet and I suppose the only reason it's had the staying power it has had is because unlike other project management philosophies, it has an extremely profitable "Agile Seminary" ecosystem.
That’s because it’s a common trait in ideologies. It predates Agile by a couple of millennia. We could add to your examples things like "if it failed, it means you are not pious enough; make more sacrifices", or "if the offensive fails, it means that you are not committed enough; bring more men and more artillery", or "if <whatever totalitarian idea> fails, that’s because people don’t believe enough; purge them". There are many, many examples in History.
Isn’t Communism the original here? It’s often claimed that all historic attempts to establish Communism don’t work cause it wasn’t done in the right way.
In all seriousness, this pattern is probably hard to avoid in any reasonably complex entity/environment. If any such situation would be solved in a global solution (aka silver bullet), it would be used by everyone. As this seems not possible, any framework like Agile, Communism, … can only be a guidance to be applied locally, and broken internally and by external factors in many ways
Religion. Your life isn't better because of {not devout enough, didn't self-flagellate enough, didn't donate enough to the religious leaders/church/god, committed some other sins, belief is lacking}
Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.
Strategic Bombing - the idea wars can be won from the air alone - is the absolute worst of these. It's a religion that might well someday kill us all, or a great many of us. In the quest to dot it "enough" . . .
On a lighter note . .
The world of overly-complex CCS (component content systems) like DITA has made this "Agile flavor of treadmill[1]" into the entire business, greased with liberal squirts of FOMO and "Industry Standards".
It rhymes with capital A Agile in many ways, although in the case of DITA specifically I'd posit that the underlying assumption of the spec is a vast category error: that natural language has formal types.
[1] i.e., "you aren't doing it properly" . . . and with every change in technology the DITA / XML priesthood claimed to hold the keys to unlock it. SEO? Information Typing. Web Content? XML/XAL pipelines. Big Data? Content granularity. LLMs? Information typing and schema will "help" llms and not just be an unholy clog in the guts of vector embedding operations. And yet, the years go by, and all of it has worked and continues to work fine without switching the world to DITA (and a writing universe of strict validation based on speculative assumptions).
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
For reference, here's all the Agile you need, it's 4 sentences:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.
Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.
That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.
I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.
Yeah, managers adopt agile to try to un-fuck their organization but it doesn't actually do that. You need an un-fucked organization first.
It's not a system of management and it won't work if the way you're managing sucks. Nothing targeted at a similar "level" as the various "agile" systems will either, though.
I'm wondering how many production strategies strictly can't work with "excellent teams", small or otherwise, barring gross incompetence or intentional sabotage.
> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.
Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP, arguably the first agile methodology, very clearly and deliberately stated that this is nothing new, just a distillation of things that experience has shown to work well.
Anyway, at my next job I introduced agile (small-a-agile) to a team that was anything but skilled. In fact, that team was where the leftovers of that particular development organization had been shunted (public company, very difficult to get rid of people). When I arrived, the team was as non-functional as the software it was responsible for. Well...
We rocked.
And all the team member improved dramatically in skill during my tenure there. Including myself.
We did not do Agile. No scrum, no standups, no sprints, none of that BS. We were agile. We focused on the technical practices. Test first. Red-green-commit. To trunk, obviously. Because if it's green why on earth would you not? Do the simplest thing that could possibly work. We had a design for a database and then never found a need to put it in...so we didn't.
It took a while for the other parts of the org to adapt to this. The answer to the common question "well, when can you deploy?" was always "now". Well after a quick look that the tests were, in fact, green. So they stopped asking. The tests were rarely not green, and when it did happened there was usually a quick "Oops, I'm sorry" and they went green again a couple of minutes later. Our ops team got bored very quickly. Put jar on box. Start. Forget about it.
What made the experience scientifically interesting is that we had a control group: the main team, much larger, working on the "important" software with all the "good" engineers started with a new project about the same time we did.
They did Agile. Capital-A. Scrum, sprints, standups.
They did not deliver and in fact the project had to be completely reset about two years in. My team-lead (we were co-lead, I did mostly internal/technical, he external/managerial) then got to take over that team as I left for Apple.
TFA, incidentally, is just about as good summary of misunderstandings of agile as I've seen.
Not much to add just wanted to say I share the sentiment and it matches my experience :-) .
I'm not smart enough to NOT keep it simple; 90% of stuff I work on at $company is really a CRUDbox and I do NOT want to "astronaut-architect" the whole thing.
Comprehensive test-suite, push to prod multiple times a day, feedback, dev.
Yeah, sometimes I feel that most of my "amazing architecture skills" is not understanding what 90% of that stuff is supposed to do or why, and hey, maybe we can just do without it?
For reference: what we did was replace an existing system, which was running over a hundred processes on about a half dozen boxes. We replaced it with a jar.
The jar was around 1000x faster, 100x more reliable, 10x less code while handling around 10x more of the domain.
Yeah: as a result of doing small-a-agile for a while.
Not at the start.
I guess if the point is that agile doesn't work for incompetent teams because teams become much more competent through agile, then I'll concede the point.
They are conditions to be met. It's not enough to proclaim them as "your process" and expect results.
When playing piano, the condition you are measured by is acoustic harmonies in the air, not finger movements. The only reasonable advice is either practice more or give up. If you are tone-deaf, it's not reasonable to expect you will learn to play the piano.
It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.
If the org focuses on the customers one can work together to find a way.
What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.
When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
Right, that's deadly. We try to do small refactorings when we can, but for hard deadlines everyone is reminded to keep their focus on what's required for go-live. And if it starts to slip, one has to be dynamic and be ready to search alternate, perhaps temporary, solutions.
Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not.
Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.
Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings.
Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.
I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??
Not sure what the solution is. There might not be any.
> Working software over comprehensive documentation
this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.
Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.
I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about.
The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.
One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.
It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.
Agile, as implemented in every big company that I've worked for, was a lie.
It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once it's complete I'll know how to make sure things match the work that's already been done and that way its always a bullseye and on time - because the work is already done.". Agile at that company was a joke to the people who got things done, and was a weapon used against people who didn't realise it in time. It sure generated a lot of metrics and stats though. I used to joke amongst coworkers that the company produced metrics, not products.
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.
This only works though, if one is working in isolation and no one else checks out the work before the time one commits to the work. That would mean being some lone expert in that part of the product, which is not a good sign for the business, because bus factors of 1.
That's the neat part of agile / scrum / whatever at larger companies, they don't actually change priorities much from one sprint to the next unless there's a major external factor like an outage. Larger companies like to be able to look ahead, at least a quarter but ideally a year or more.
At my current contract we use "SAFe", "scaled agile framework" which basically revolves around quarterly plannings, but above that is a long term planning of course. (energy industry, scale of hundreds of engineers)
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults.
For every person burned by a subsequent maladaptive formalization of these principles, there was someone horribly scarred before the agile manifesto by being forced to go through a doomed waterfall process.
Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!
If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.
No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.
Ward Cunningham [edit: oops, it was Kent Beck] had it right, long ago, when he wrote in "Extreme Programming" [paraphrase]: You don't drive to Florida by carefully lining up your car in New York on I-95 South, locking the steering wheel, and then pressing the accelerator until you arrive.
This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands).
I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
This is just a confusing and confused article.
Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
We are still doing that and will be doing it in the foreseeable future. Agile is very much alive and here to stay.
Iterative development has existed since forever, since earlier than written history.
It is not something invented by the Agile proponents.
They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere.
Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners.
There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.
> Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
I agree, but what you describe is agile, not Agile (capital A).
Agile (capital A) is Scrum (capital S) where you have Backlog Grooming (patent pending) where the team clears any ambiguity to define a spec (ticket).
Deviating from said spec is seen as Scope Creep (gasp) and might lead to complaints during Sprint Review (trademark).
So yes, agile prefers working software over detailed spec. But typical manifestations of Agile (capital A) are exactly the opposite.
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
No, not quite. The specifications we use for agents make any ticket written before them pale in comparison. That enables a hybrid workflow that is both spec-driven and "agile", in the sense that you're doing very rapid development cycles.
> The Manifesto sayeth naught of Daily Standups, nor Agile Coaches
The manifesto says "Stop trying to micromanage your programmers."
It's written vaguely and politely but its spirit is the opposite of mandating daily meetings ("processes"), having trained coaches, or any metrics like story points ("tools").
As the explanation says:
> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
When Agile came about to company (large American corp) I work for, around 2015 (arguably quite late), I was quite skeptical. In my opinion, a decent waterfall (basically a sort of compromise) worked pretty well, and I didn't like fake "innovations" like Scrum or renaming everything in project management terminology.
Then I read Steve Yegge's Good Agile, Bad Agile. It basically says, Agile is just a Kanban queue. And I think I got it, and I think that's working very well. At least from the project management side.
There are IMHO three management angles to look at any engineering project - product, project and architecture. If you are building a house, you need a blueprint to tell where to put what concrete, you need a render (or paper model) that you show to a customer, and you need a BOM and a timeline to make the investors happy. The software is not different. But that's also where there are misunderstandings in what Agile is - the product management, project management and engineering all have different ideas what kind of "plan" is needed.
So in the case of software, specs are like the house's blueprint. In some cases, specs might be useful prototype, in some cases not. It's just not the type of plan that the project or product management cares about.
Regarding the project management angle, for me Agile today is clearly Kanban, and almost everything else is wrong or not required. I often make an analogy with computers. In the 50s and 60s, people tried to plan the work that the computer calculates by creating some scheduling algorithms that plan ahead the use of resources, avoid conflicts and such. Eventually, we found out that simple dispatch queues work the best, don't estimate at all how long the task will take. Just give it a priority, a time slice, and let it run. And I think the same applies for the SW development. And I think it's time that project management people take note from computer scientists - they already know.
Doesn't mean SW development time cannot be estimated if you need to, it's just not a very efficient to do so (it takes extra time, depending on how good estimate you want).
I watched a video a few years ago where one of Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, I don't remember who exactly, explained what they wanted to do with the Agile Manifesto, what screwed up. He explained that they wanted to give guidelines, not a strict rules. They wanted flexibility. But people started selling this as courses, business, rules. Some Agile practitioners become fanatics on the topic. And this created misunderstanding and chaos :D
For 20 years, I have seen it working and not working, and the reasons are a lot.
It can be affected of level of expertise, quality of documentation, pressure from management, engagement of the clients, etc.
Simple example of failing, and how one of my team overcome it. There is no specification. Option 1: team complains that the specification is bad, and this makes the code quality bad. Option 2: the team pro-actively prepared the specifications, gave them to the client for approval. Writing the specification was, a kind of, added flexibility, that was introduced in the sprints.
Another example, why should the sprints be fixed at 2 weeks. Sometimes, people try to finish for two weeks and they produce bad quality code, because they are time pressured. Be flexible and make them 3 weeks, if the sprint includes things like, preparing specifications, or if the sprint includes pauses for bug fixing. :)
So it is not the Agile that makes the project successful, it is the people. Agile just help for tracking where you are , and what you need to do ;)
Now with AI, you can use Agile again, there are agentic frameworks that support it and they give good results, in my opinion. If the people use it wisely, think what they do, and try to do things better, it will work. Of people are lazy, don't know what they are doing, don't have expertise on software development, it will fail :)
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
Oh that was it you're right. We have those documents but they are full of lies. Yet everyone can read it and believe it to be true in the way they want it to be.
> Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth.
That's not agile.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
Maybe this is why so many people can't even try to do agile. It sounds bad. But it works great.
In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing.
In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.
Ran into the same wall - ceremony eating the actual work. The Flight methodology cuts through it: a landing date, a single captain, no story points, no mandatory standups.
The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."
Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.
So one of the main points in this massive, 700 word Treatise (which I do hope you will find the time to read) was that nothing Agile practitioners slapped their label onto was actually novel.
Why re-invent agile, when agile itself was just a reinvention by "the kids" (your words, not mine) of things people in the 1970s already knew?
One might as well go straight to the 1970s directly.
Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?
All AI has shown us is that we should probably write specs before we code. That was true before AI, but LLMs have just shone a light on this, and it will remain true if agentic coding falls out of fashion again.
Never once did I advocate waterfall...
Read the Royce paper, seriously. It's short, he's a much better writer than I am, and if nothing else it's a fascinating looking at the old state of the art.
There's a problem with any formalisation of patterns like Agile and other things like SOLID, Design Patterns (GoF) etc.: if you never saw the world before them, you will never appreciate why they exist.
Is anyone actually doing true waterfall development any more? How would that even work with the amount of open source software in use? The world is fundamentally different now than it was 25 years ago.
Stuff like SOLID and Design Patterns etc. are such good ideas that they've been incorporated directly into the design of modern languages and frameworks. It's natural that someone would pick up Design Patterns today and think it's all pointless. That's because the book was written in 1994 and it wasn't pointless to say it back then.
I guess this is why history tends to repeat itself. Many people can't internalise why something is bad unless they've experienced it themselves. Many more don't even read about it in the first place. Scary to think.
I've found that Finance, and the Tax Office of any government, rarely care about your Agile processes. They have their yearly cycles, and C-Level will always want to follow _those_ cycles.
Then, for those that have schoolgoing kids or work with people that have schoolgoing kids (aka: everyone everywhere): there is the school vacations cycles.
These too rarely care about your scrum rituals or PI planning. This means that your calendar is not a reflection of reality: July/August barely exists. Same goes for November or December. And at the same time December is full of actual deadlines due to end-of-year financial cycles.
And finally: the complexity of the work itself rarely lends itself to the linear timelines people expect.
Rarely have I met a Product-person, or a SCRUM person, that actually understands this. And can account for it in their Agile way of working.
End result: a continuous stream of disappointment. What fun times we live in.
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it".
e.g.
- 45 minute "standups" (!?)
- PI "planning" that consisting of deadlines and glorified multiplayer MS Paint
- Rigid adherence to ceremonies or processes that add zero value
- Retros that focus on complaints and venting with no actionable outcomes
- etc etc
Every time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to:
- Short, daily standups
- Planning based on risk reduction
- Estimates based on complexity (ties in with risk reduction)
- Actionable retro items
- User demos every sprint (makes it easier to pivot - users rarely know what they want)
Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.
Sure, but if people are using the retro as a vent session, maybe it's because they need an outlet. Perhaps a separate meeting titled "vent session" is what you want. Although it's important to have action come out of that meeting as well, don't want to just channels peoples' real concerns into a meeting that is intended to hear them out and then do nothing. Manipulating peoples' concerns into a channel where they are made unobstructive and ineffective, so they can be easier ignored is a pattern of bad-faith bosses. Conflict avoidance is toxic. You and the team building skills in conflict resolution can help.
If you don't care about definitions, then it would be good to not perpetuate using the word agile for your own set process. "Individuals and interactions over processes and tools"
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
Good. I've worked in several organizations where we had Agile.
With the years, I've come to think about it as a sing and dance designed to make the project managers, PMs and sales feel like the actually impactful ICs considered them.
There's something really absurd about making programmers sit down and say it's a 5 or 8 effort, then punish them for being "wrong". All it achieves is reduce velocity at best, with the illusion that it's for the greater good.
1. estimate this sprint. let's say it's 100 points.
2. oh no, you shipped 80 points.
3. "we need to better estimates":
a) engineer spends more time trying to guess which direction the wind will blog
b) engineer starts sandbagging estimates
c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".
The problem with spec driven development is that your specs are never complete, and for sure contain inconsistencies, wrong assumptions, etc.
So now you write specs, and then an LLM, which is known to be overly compliant, will handle the implementation. If you don't see the issues with this workflow, you for sure have learned nothing about how the software development process evolved.
Wasn't the whole waterfall model originally a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product.
This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like.
I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!
> and at worst it was commercially unworkable ("Welcome changing requirements, even late in development")
It's been workable for me. We can change the requirements as late as you like, because I'm getting paid by the hour. Scaled up to a company, that translates to not giving a fixed price for anything.
If you need to give a fixed price, either be experienced enough to know by how much your agreement can change and factor that in, or turn it down. You should also turn down demands for a fixed price on novel solutions you can't have experience on.
I'm curious whether it's the author's contention that the signatories of the Agile Manifesto thought that the ideas they were championing went back only a few years, and they had no idea they went back at least 30. In particular
> All of these things were later claimed as Agile innovations
Are there some references that demonstrate that? [EDIT: that the signatories thought they were their own innovations]
And if so, is that a bad thing? Ideas are repeatedly rediscovered. This article isn't called "Saying goodbye to Royce, Bell and Thayer", and I'm wondering why not.
It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.
As others said, if agile fails, "you were not doing it enoug".
But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone.
Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.
I'm of the belief that most project management voodoo is just that - voodoo. There is no rigor, there's no formal basis for ideas, and there's no testing of hypotheses and rejection when evidence counters it.
Engineering (even in computing) has a formal basis and practice. Project management does not. Systems thinking and industrial organizational psychology does, but rarely do you see it applied like bullshit such as agile (and in environments that do - it works spectacularly).
Out with the voodoo, and in with the scientific method, I say.
> One unambiguously positive development that's followed is that software professionals are writing specs again.
I feel this in my core. There has been a period of the last 5-6 years where folks have stopped writing specs entirely and it has driven me nuts. Everything is a story or some other abstract requirement. The absence of a specs has made software worse and less predictable in my opinion. All hail the specification!
> One unambiguously positive development that's followed is that software professionals are writing specs again. LLMs - like many of us - do not perform well with ambiguity, and specifying problems is proving to be an effective tool for generating correct code.
Replace "LLM" with "compiler", "specs" with "code" and "correct code" with "correct machine code" and we are back to square one.
Gather requirements -> Small focused spec -> code -> Validate -> Fix/Adjust -> Remove spec once it is captured in code and tests.
Agile is stronger than ever, spending time on every small detail in a waterfall approach makes you burn human time on work that most probably could have been perfectly fine with a default approach.
Context matter but I fail to see people spending months on planning out a system before building anything.
If the term "agile" didn't have such double or triple meaning, it may have worked. The term itself promises too much with little context and it was always too easy to fall into the trap of "being agile" because, why not? Agility is a valuable trait in human terms.
If we just put enough effort in and write the right spec/prompt/design then the programmers/llms/plug compatible coding units will produce the correct output first time!
Closing feedback loops. That’s the whole thing. WE Deming would have recognised agile (little a) as a PDCA system and approved.
Saying the Agile manifesto was void of meaning is ridiculous.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The problem is that the Agile industry mostly didn't follow the Agile manifesto and ended up with monstruosity like SCRUM, which is all about processes over people.
Daily Standups, Retrospective, Backlog Grooming = PROCESS
This crap should all be replaced with async written communication (for quality of life and recording), but each team should ultimately be free to decide.
The Agile manifesto was all about freedom and it was turned into a jail.
So many times I have found myself writing the end-user documentation (even after writing tests for the code), and realized that the design should change.
This is the kind of post that makes me log in to hn to give a vote.
These arguments are pointless. Working software is shipped using either method, some combination, or no method at all.
Hell, half the devices in your life probably run some hacked together crap that was built by people who barely knew how to program and eschewed version control for USB sticks.
I really hate discussions of "software" as if the software in an F-35, the software presenting data on a webpage, and the software making a child's toy blink and speak are all the same thing. Only in a very abstract sense are they similar.
Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful!
Let me find my:
Requirements Specification
Requirements Analysis
...
The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier.
The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect.
In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up.
What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence.
This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.
And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.
Which means Agile will always be more expensive, time-consuming and difficult than alternatives.
Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard.
And there's two basic ways to build it: with plans, and without plans. Without plans, you have to design it yourself, then try to build it, then make mistakes, maybe even to the point you have to start from scratch. Time-consuming, expensive, hard. But start with plans that have already been built, and you benefit from somebody else's time, money, expertise and toil. The boat is built faster with less effort and fewer mistakes. And instead of needing master craftsmen, you only need journeymen who can follow orders.
It means, that you need capable engineers, who are willing to talk to users and build understanding, rather than just being Jira task rabbits. It means, that you might not even need all the intermediaries, each having their own personal agenda and incentives, that engineers usually have to put up with. It also means, that certain layers in an organization have to trust their employees a little more.
It means, that what you build it based on user feedback, rather than what someone tells the engineers, what the user feedback supposedly is, without having a clear idea, what the users actually want. I have seen this first hand. When in the beginning of the product I as an engineer interacted with the users and found out their issues with the platform I was developing, later on the organization added hierarchy layers, shielding or preventing engineers from talking to the users, to build their own job moat, and patronization going on in terms of "Your time is better spent developing the actual features.". In the end the product ended up drifting far from what is good for the actual users, and instead people talked more to B2B customers, than the employees at those other businesses and what they actually need or want.
With each additional layer between the user and the developer (which is also people who want to be paid btw.), the business is inflicting significant cost and increases the risk to steer off course.
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
This post sets up a straw man from the outset, and only gets worse from there.
I understand how we got here, where many experienced programmers, managers, and bloggers only know capital-A Agile as the watered down version sold via certifications, crummy medium posts, and atlassian flavored kanban boards. But that isn't agile.
I can’t even with the pitch into spec driven development as some sort of high watermark of software methodology.
Not in my experience. AI exposes the truth that agile as it is practised is a huge waste of time. All the bullshit ceremonies and short sprints were designed to get code squeezed out faster, no matter if the code actually addressed the goals of the project. The stupidity of agile is in its iteration speed since you can be handed utter crap, implement it to hit your story points and find out the drooling shitgibbon who wrote the specs phoned it in so your work is now wasted. Rinse, repeat.
But that is fundamentally what agile is about. It's not about coding faster, it's the recognition that the specs are incomplete or wrong because fundamentally, a lot of customers cannot tell you what the want until they see it. That's why "build something simple and iterate on it" works. Regardless of how good your spec is, once the coding is done the customer is going to realise that that's not what they actually wanted.
Holding analysts to account would be a good start. Agile lets them get away with laziness. It’s always “oh sure we got that wrong better luck next sprint”
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.
I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.
There's an interesting phenomenon that Agile (capital A) has exposed me to, and once I saw it due to Agile I've seen parallels elsewhere.
In that: if it fails, it is only considered evidence that you were not doing it enough.
The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
It's also true for Cloud providers; that they're not suited for certain tasks is no longer considered an engineering trade-off, it's that you architected your solution wrong, and the answer is to buy even more into how the platform works.
If your microservices become slow or difficult to debug, it's never that fatter services could have been preferable, it's that we didn't go hard-enough into microservices.
If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.
I feel like I see it all the time.
My favorite Agile-ism is when Agile is defined as “the process that works for the team”.
If a team adopts agile (in any variation) and doesn’t like it, the Agile defenders will appear and argue that the team wasn’t actually doing agile. Agile is defined as the process that works, so if it didn’t work it couldn’t have been agile. If only you read The Agile Manifesto you would understand!
Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof).
Regardless of success or failure you can say to what degree this is true, and to me this is really that only part of "agile" that is worth locking in.
In the team's power to determine a working process but in the scrum master's responsibility.
If you use scrum, and if you have a scrum master. You categorically don't need to do either of those things though.
My definition of agile is that process is a knob that you can turn. You don't like how the process is working out for your team? Adjust the process. Find the sweet spot for your team. As your team changes size and/or members, keep adjusting.
"We're going to do agile by following this rigid process" is an oxymoron.
The problem is that "just do what works" doesn't justify a whole agile industry and not even two days of training.
The real claim of the agile industry is that they know what can work and that you can find it using agile. That also has real value - if true.
Wow I guess we were actually agile all along, by virtue of being a team that defines our own processes. Yet I don’t think we’ve ever used the word agile once in any of our meetings.
> My favorite Agile-ism is when Agile is defined as “the process that works for the team”.
What compels you to believe it isn't?
I mean, read the Agile Manifesto. All it does is basically define a set of values and principles. Things like "customer comes first" or "we welcome changes in requirements" or "software must be delivered frequently".
What leads you to believe Agile implies a fixed set of precise, rigid rules?
The problem is a disconnect between management and those who build.
My thoughts when PE forced Agile on my employer were dismissed as "you're the technical expert, we're the process experts".
As someone without decision power, you read words of empowerment but your reality is a different one, and you're left resolving that dissonance on your own (quietly, otherwise you get pushed aside).
This is the problem with 'Agile', and why people refer to it as "Capital-A Agile".
As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you. They want to stay in business, so they need to make sure they have something to sell.
That's the dysfunction - a company that is forcing this laborious process on you, rather than giving teams the autonomy to figure out how they best work.
Agile works best as a toolbox of practices you can adopt, mix, and match to solve whatever problems you have. Do you need to work to a fixed schedule, or provide delivery estimates? You should probably have a way to regularly estimate your work. Are you struggling to actually ship and do things? Maybe it would be useful to plan things on a smaller, more frequent cadence.
> As always, the problem isn't the process, the problem is the people. There's whole industries out there set up to sell A Process, so they come in and try to force something like this on you.
I would go as far as to claim the problem is middle management types, who feel pressured to adopt buzzwords and want to micromanage things to cultivate an image of control and progress to justify their role.
It's the same type that brags about scrum but don't even bother to show in standup meetings.
> The problem is a disconnect between management and those who build.
That would clearly be a problem that falls well inside the domain "you are not doing enough Agile".
A key principle of Agile is literally "Business people and developers must work together daily throughout the project."
If a team suffers from that disconnect, it's failing Agile.
More to the point, whatever they are doing is not working, and Agile would fix it.
It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.
I actually think OP's criticisms apply mostly to Scrum. Scrum is well defined but its adherents' wont hear a critical word said about it. "You just werent doing it right" even when you were doing it precisely as described.
> It isnt but the fact it ultra vague and hand wavey means anybody can claim anything they do is agile including things that the exact opposite.
I don't really agree. The set of principles are quite straight forward. It's things like delivering software frequently, accommodating new requirements, continuously looking into improving processes, business types and developers working together, etc.
Then you have concrete executions like scrum vs kanban. Agile doesn't specify one or the other. Retrospective meetings are popular, but aren't specified by Agile per se.
The fact that you spell agile with a capital "A" says all I need to know.
> Agile is defined as the process that works
Can you show a reference of where it is defined like this?
I think the confusion comes from considering Agile as a process instead of a set of values and principles. The Agile Manifesto only talks about values and principles(https://agilemanifesto.org/). Values are not right or wrong, they are just values you agree to or don't.
The problem mostly arises when processes are shoe-horned under the guise of 'Agile' in setups where they might not be the best fit by so-called process experts under pressure from management which does not know any better. The authors of Agile Manifesto have frequently said the concept of Agile has been badly twisted.
I think it’s long past the time where we can pretend that The Agile Manifesto is representative of what the word “Agile” means in tech companies.
The manifesto is a minimal set of principles but every real world Agile shop I’ve interacted with has subscribed to a set of processes that everyone in tech would recognize as “Agile”.
The manifesto has become a safe retreat that agile fans bring out whenever someone has criticisms about real-world agile; Whenever someone has a complaint about Agile as implemented in the real world, someone will show up and try to defend it by pointing out that The Agile Manifesto doesn’t contain the specific thing they dislike.
The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized. We can’t keep returning to it as some safe home base that shields Agile from any criticism.
Industrial Agile is mostly Agile Manifesto with the negation of the first principle (Processes and tools over individuals and interactions).
"Industrial" cannot rely on any one individual. You have to be able to scale your process (or whatever), duplicate your process, have your process survive multiple people leaving, and so on.
Which means that any true agile cannot be industrial. And therefore any industrial agile cannot be true to the principles of the Agile Manifesto.
At this point I equate the Agile Manifesto to the Communist Manifesto. Sounds nice when you read it; in practice it is an absurd endless source of suffering.
>The Agile industry moved beyond The Agile Manifesto almost as soon as it was popularized.
Yeah, spending the amount of words in this thread trying to diagnose or complain about this simple problem in abstract strokes seems silly and frankly confounds me when considering the amount of time people wish to waste discussing the problem.
As with political parties, bad gentrification in cities, and all the rest, once money and consultants turn things into an industry you're pretty much fucked.
People should just immediately stop taking people with conflicting interests at face value when they talk. Stick to concrete details when you talk about stuff, avoid industry terms, don't let them turn things into abstract and general discussions. It only feeds the trolls (consultants) when you even complain generally about it.
Fight it with your day-to-day actions, not so much with your words. And then let it die in silence, it will die faster (I'm referring to any tech topic captured by consultants and monied interests).
I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.
I'm not religious is any traditional sense, but I'd argue that it's not always the hallmark of a bad dynamic when a system always asks of you to do inner work when failures happen in contact with the real world. Sometimes that's a healthier mode than the alternative -- externalizing the blame, and blaming the system (or the god).
I suspect there a very abstract game theoretic conversation that could be had about this :)
> I suspect there might not be love for this angle here, but there's something else that follows this format: God. Spirituality. Religion.
Yes, and that's because God, spirituality and religion make fuzzy truth claims and can be used to argue for and justify anything. God can be used as the excuse to start a genocide and the inspiration to stop it, spirituality can be the way for wounded people to work with their trauma and the vehicle for people without scruples to sell horoscopes or some shit, religion (the same religion) was used to justify and uphold slavery and to fight for its end.
They are containers for our politics, our lifestyle, for who we are and for who we hope to be.
The Agile manifesto is a series of statements in the form "we like X more than Y." It doesn't say anything. To make it mean anything you have to project onto it a framework of interpretation that exists independently of the "sacred text" itself.
So yeah, they are similar, and that's because Agile, sociologically, works like a religion.
when it comes to some diets, some only work if you follow them wholeheartedly, like meat only diet, one speck of peppar might be enough to cause an inflammation. But generally you can't take a process that worked well for another person or company and apply it on you or your company. Like for example a training program, you can't just take a training program from a professional athlete and reuse it on your kid and expect him/her to become as good as the pro. Programs and processes are very individual tailored.
I'm pretty sure a religiously followed meat only diet can't succeed at anything other than achieving scurvy.
Meat have all vitamins. But if you plan to stay on the diet forever you should eat all parts, not just the steak.
Ah, fair enough.
I still doubt that your average person would see any real health benefits from eating only meat, even if they ate enough organ meats to actually get all their vitamins and minerals (the lack of fiber is a particular concern) but I guess you're right that there's a version of an "all meat died" that doesn't promptly kill you through malnutrition, you got me there.
A process that fails when you slightly diverge is process that fails. Because all human orgs diverge from stated process here or there. Including army which puts huge amounts of resources into making people comply with everything.
It's usually because your company doesn't fundamentally want it. You cannot have roadmaps with lists of features that you advertise to customers AND have the flexibility to decide to ignore things that turn out to be useless or disporportionately time consuming.
If someone handed you a plan for making a jet engine and you messed around with the instructions ... why would you expect it to work? If you have a bug because there are not enough tests ... you write more tests don't you? Why would a method be forgiving when compilers and reality itself aren't?
But that isn't evidence that the method works. If you're a native tribe, that has an ancient traditional rain dance, it is invoked whenever there is a drought. Sometimes it rains shortly after the dance is performed. But if it doesn't rain, it's not proof that you danced poorly, it's evidence that you didn't understand the situation fully or properly. The instructions or "wisdom" you relied on, didn't actually capture something useful.
My evidence is that I was on a team that was not overly controlled by management and had clever people in it without any instant attitudes of rejection so they adapted to it. We produced updates bi-weekly and we had a huge backlog of stupid features which we were never going to get round to - we were able to get the important things done and it was one of the best feelings I've ever had about work.
Since then I've been on teams with any number of pathologies. From developers it is sometimes the desired to be special - those ones who want to work on their bit of the code and not let anyone else touch it. From managers it's things like forcing the way stories are split so that they're always too large and can never fit into a sprint - because they think that everything must be a "user visible change". Management types also sit in retrospectives and use them to crap on everyone. Product managers demand features which they don't know will really interest customers and are inflexible about them - they want "everything" just in case and that delays the work and deletes any chance of a feedback loop.
The good agile feeling came from being able to have control and be successful. When it's messed up, you're out of control and cannot avert disasters. Whatever method you want to call it, I think we need to feel we're in control enough to succeed.
What is the chance that you've perfectly captured every aspect of the situation that led to success? Versus, what is the chance that you were lucky enough to be in situations where a multitude of factors, both appreciated and unappreciated, combined to lead to success?
There are a million possible reasons for failure, but here is a very easy one: It doesn't matter how good you feel about the development process, if the company has the wrong objective. You will still end up being frustrated, and failing. Of course this will have all sorts of pathological and uncomfortable ramifications.
So while it is easy to say, "just act this way and you'll have success". You're not actually appreciating all the hidden elements that allow any hope of acting that way. You've been lucky enough to be in situations where it happened to work (ie. the rain dance made rain), but that does not mean it's actually representative, or that the prescription actually captures the critical information needed to ensure success for other people. Instead, you've described a rain dance.
You're right - there isn't one way to do things or one way that always works. There are issues that are outside a team's control, for example, that make it an impossible struggle. If you're rigidly forced to do something and cannot adapt then you're ... not really agile. But you have to understand why you're doing what you're doing and keep adjusting to see what works for you.
#1 IMO is that if the company you're in is non-agile in its general attitude, which is influenced by its own customers, then everything is geared against you.
That isn't to say that something like Kanban might not be usable or better than no plan at all but certainly scrum is not some universal solution.
> It's usually because your company doesn't fundamentally want it.
BINGO. Managers and execs want (or get sold on) "agile" but only want it to affect the structure and processes for the very lowest-level workers. They don't want to change the organization or what they do, and odds are those are really bad and won't let most systems like this, agile or otherwise, function properly.
(The big secret is there's no framework like this that "works" for fixing broken organizations; there are [rare!] well-led well-managed organizations where damn near any halfway-reasonable system they choose will work, so if they decide to do Scrum or whatever in places like that it'll work just fine—and then there's everyone else)
This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.
You can never use enough tokens.
Which also conveniently makes you spend more money on tokens.
With agile, at least no one was charging you for it. Like sure, there’s a cost to the process. But there wasn’t direct agile.com profiting from you.
Meanwhile agentic workflows every solution to the problem is giving more money to the ai companies.
Model is bad? Made more expensive model. Still bad? Here’s an infrastructure that reads huge text files again and again making you consume tokens. Still bad? Here’s a way to easily spin up multiple agents at once so you can delegate work. Still bad? Here’s a new service that will automatically review code. Still bad? Maybe a biggger more expensive model will help.
>> With agile, at least no one was charging you for it.
Depends. There are companies [1] making loads of money out of it. Charging for certification and imposing the idea that either you are certified, or you are going to fail. They are even eating the lunch of PMI, as PMI (PMBoK) is turning into an Agile manual. Where I work is being expended literally millions per year in Agile.
[1] https://scaledagile.com/what-is-safe/
> With agile, at least no one was charging you for it.
Charging people for Agile via his company ThoughtWorks (which sold for 785M) is how Neville Roy Singham made the money to fund far left groups in the US from his base in China.
> This is a great point! Reminds me of Agentic software development. When it doesn't work out it's only evidence that you could have used more agents.
A concept older than agentic software development is bad workmen blaming his tools.
I mean, if you can't possibly hammer a nail then is it reasonable to blame the hammer?
If it's an internet-required smarthammer without a handle that instead hits out on voice prompt, sometimes without enough or with too much force, sometimes knocks the nail out of the way and punches a hole, and sometimes hits you in the face, then yeah
> If it's an internet-required smarthammer without a handle that (...)
A suitable comparison would be to be faced with a nailgun and proceeding to criticize it on the grounds it doesn't have a handle, it doesn't pull nails, and it requires electricity to run.
While you complain about those detailed those using nailguns are an order of magnitude more productive at the same task, and can still carry a hammer in their toolbelt.
I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.
> I originally was writing the post using a nailgun, but decided someone would criticize it for straying too far away from a hammer. Alas.
The point is still unaddressed, isn't it?
Well, no, the examples are basically the same. A wifi nailgun that sometimes shoots a nail straight through the board, doesn't shoot one at all, shoots it randomly to the side, shoots you with it, etc.
[dead]
Clearly they didn't use enough hammer. Screws always require the most hammer. Common knowledge to any certified practitioner of Hammer™[1].
- [1] Get 20% off your Hammer Master™ certificate with referral code THUMBPAIN
You can use brick as hammer. Doesn't mean brick makes a good hammer or that person who tells that brick is a bad hammer and doesn't work from them is bad workman.
> if it fails, it is only considered evidence that you were not doing it enough.
Or not doing it properly. And I understand the suspicion, I really do; but in hindsight, if you honestly tried to review how an organisation was operating, would you sincerely be able to say that it was adhering to a certain agile methodology/framework/mindset/strategy/whatever?
I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed. So I can't really say if agile (or any of its particular variants) work or not. I have not seen honest experiments properly run.
> I have so far not see an organisation that would be following scrum, as it is described in the scrum guide; or kanban, as it is described in the kanban guide. I have seen or heard about various organisations that use these words, but they have little resemblance to what was actually proposed.
If that's true, wouldn't it point at the process being impossible to implement?
It is a myth. There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.
It signals to me that the process doesn't work in reality. You are better off doing something else.
It doesn't really fail any worse than other inflexible top-down process mandates from management.
That's where it becomes "impossible to implement"—you can't impose it as a cookie-cutter solution driven and controlled by management, and get much good out of it, yet that's the usual way it manifests in the wild. But that's not so different from anything else management might push in its place.
> There exists a version of Agile that could be implemented, and it would be the true Agile. The pure, honest experiment that would just work, because Agile cannot fail, you can only fail to Agile.
"Agile" is a very vague and shapeless idea which is hard to design an experiment for; but I would settle for clean experiments with well-defined methodologies/frameworks/strategies/whatever. Specifically, for scrum or kanban. Whenever people talk about these two, they seem to misunderstand them more often than not.
>It signals to me that the process doesn't work in reality. You are better off doing something else.
Whatever you do instead, you will also cargo-cult to some degree and fail equally as badly at.
For all the "You're doing it wrong!" I've seen in industry with respect to agile, I've also felt that every team I've been part of that did some version of it, seemed to function OK. I always found the "Agile Manifesto" a completely silly nothing-burger, but always understood the core tenet of 'agile' to be "employ tighter feedback loops", which... is sort of mostly how it plays out in practice??
I've belonged to numerous teams that followed some form of agile, to varying degrees of success (or failure).
The shape of what Agile meant in each of those teams was very different from one another. It would be disingenuous to say "the ones that succeeded were truer to Agile".
If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless. A single sentence, as useful a tenet as it may be, does not a philosophy make. And this idea was not even new by the time the Agile manifesto came out (as explained in the linked blog post).
> If Agile can be summarized as "employ tighter feedback loops", the whole Agile thing was beyond useless.
Not just that, Royce's original paper that coined the term "waterfall" in 1970[1] can be summarized as "employ tighter feedback loops" compared to top-down design (figures 2-4 in the paper).
[1] https://www.praxisframework.org/files/royce1970.pdf
Useless as it might seem, I really do think it is actually that basic. Is it useless? Hardly. Take out feedback loops and see what happens.
The tenet was not useless. But it was not bought forth by Agile. It already existed.
And if this tenet is all Agile is, then it contained zero new ideas or contributions.
It seems to have successfully popularized it though.
> In that: if it fails, it is only considered evidence that you were not doing it enough.
I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.
Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".
This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.
> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?
If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?
https://en.wikipedia.org/wiki/No_true_Scotsman seems pertinent here.
Yes, but on the other hand, there's https://www.reddit.com/r/ididnthaveeggs/, which collects cases of home cooks making inadvisable recipe substitutions and then complaining to the recipe creators that the resulting dish tasted bad. Sometimes there are essential ingredients and skipping them or replacing them with something else makes success impossible.
An appealing analogy but recipes have defined testable outcomes. You know what a Victoria sponge is supposed to look like (there's probably even a picture of one in the book). You can perfectly evaluate when a substitute has ruined it.
Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly". What does "Agile" adoption look like? Faster delivery? Happier Developers? More revenue? Fewer bugs? This is never defined up front and they shift depending on the person being asked. This means you can never actually determine if someone "left out an essential ingredient".
The irony is that Agiles own favoured development practice (TDD) cannot be applied to Agile itself. There is no acceptance test for the process, you can't iterate on something that isn't measured and has no defined outcome.
/r/ididnthaveeggs works because everyone agrees on what the dish should have been.
> Agile doesn't have that, there is no functional equivelant of "the cake should be moist and rise evenly".
That's not true for the way I understand agile. The way I understand it, the testable outcome is whether the principles of the agile manifesto are satisfied
For example, is your highest priority to satisfy the customer through early and continuous delivery of valuable software? If not then you're not agile.
https://agilemanifesto.org/principles.html
There is one and only one essential ingredient of agile, and it's feedback loops. That's all agile really is. The employment of feedback loops.
I mean, Switzerland and North Korea both call themselves democracies but the specifics matter. The specifics matter!
These discussions are always fascinating in a sort of baffling way to me because I've only had great experiences with what I call agile. Like, you bring it into the team and within months everyone is gushing about how much better life is now. Yet threads like this one are full of people reporting awful experiences.
Apparently whatever it is they're doing involves a lot of meetings and little actual flexibility? The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them? Every team and every business is different and you have to iterate to arrive at whatever will work best for you. That's possibly the one most important point, IMO. Dropping the things that don't work is a key part of that!
Eric Brechner of Microsoft (of all possible places...) gives a great talk on his team's approach, and I've had good experiences using it as a starting point: https://www.youtube.com/watch?v=CD0y-aU1sXo
But again, every team is different. Even the greatest possible theoretical approach is only a starting point.
And like with Switzerland vs North Korea, I guess the key thing is how much ownership of the process those subjected to it have?
> The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?
Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.
> whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP
Isnt that in itself "agile"? And I specifically dont mean following a religous ceremony plan etc but recognizing that a part of their process isnt working and then changing it. To me thats the entire point of actual agile. You try a process, it doesnt work, you analyze, and adapt.
Ideologues are everywhere.
If it isn’t presented as a theory that might be proven wrong, or an idea that might not work, that’s when my alarm starts going off.
Another signal: trying stuff we already tried that didn’t work, usually with an unconvincing reason why it’s different this time.
In many contexts "already tried" does not apply under "this and this conditions" though.
You can try the same thing under different contexts and it will probably yield different results (at least in any context that is organizational / social)
But is it wrong? If you're in a plane and it's on the ground and it starts moving but it doesn't take off, the answer really is to move faster. If you press a button and it doesn't activate, the answer might just be to press harder. If you're running away from a bear but it's catching up to you, the answer really is run faster. If you don't, you're dead.
So the problem with that is that it's an oversimplification in an attempt to sound smart and insightful and can't be used as a general principle to reason as to whether or not you need to double down to see results.
all of those examples have a known causal mechanism and a measurable outcome.
I know, right? If only the rest of life was that easy!
>I feel like I see it all the time.
Sometimes its justified. Like "This is only satisfied when x, y and z are correct"
But then you get
"We will do x and y as a compromise but not z"
And then you have to explain that, the compromise is actually worse.
> "We will do x and y as a compromise but not z"
This reminds a lot of this: "I'm going to try this extremely difficult pastry recipe at home, but I'll use margarin insted of butter because <idiot reason> and a teasponn of stevia instead of the prescribed 200 g of sugar for <another idiot reason>."
> In that: if it fails, it is only considered evidence that you were not doing it enough.
> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.
This isn't some religious premise, it's the lesson of bitter experience. It's like how when two trains crash into each other the inspectors start by looking for which one went through a danger signal, rather than questioning whether signalling systems work.
Isn't this type of reasoning okay to an extent until you (or in more humbling cases, someone else) points out it's no longer working?
Sure. Occasionally there really is a problem in your signalling system. Even more rarely there's a fundamental design flaw.
If and when I see actually-doing-agile fail, I'll change my mind. But so far I've seen a direct correlation between the extent to which an organisation was actually-doing-agile and the effectiveness of that organisation, across a wide range of industries/environments/countries.
> In that: if it fails, it is only considered evidence that you were not doing it enough.
Seen this multiple times
The problem is agile as in the original manifesto was an ethos, not a process.
Everything since the manifesto, called agile, has tried to wrap an ethos up as a process, playing lip service forgetting the ethos.
High performing teams are already doing agile, following the ethos without attempting to be agile. High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.
> High performing teams made to do agile become average teams and low performing teams made to do agile can become average teams.
This is also my observation. I compare it to McDonalds vs a star restaurant. Put the top chef of a star restaurant in McDonalds and he will perform average. Put a McDonalds member in the star restaurant and he will perform badly.
The amount of process needs to be tweaked to your team. Ideally, you can give your star players more freedom.
If AI fails, you wrote the prompt wrong.
I feel like Agile is just a tool. You adopt it, or parts of it and see if it works. If it does for your org awesome, if not for your org, try something else.
Organizations are all different IMO (even if slightly), and you gotta try things and move on.
Is it the fault of Agile if it doesn't work? I don't know, I'm more interested in finding what works.
That's why you need to evaluate things by their outcomes. It's the same as weightlifting, if you get injured, "you didn't have good technique".
If your thing sometimes harms people, for whatever reason, your thing isn't safe enough, or easy enough to understand how to do safely.
"If you failed it is only evidence that you were not doing enough." is the core principle the whole self-help, self-improvement and large parts of weight loss and health industries always have been based on.
> In that: if it fails, it is only considered evidence that you were not doing it enough.
In my experience, when it fails there's always someone to tell you that you were just doing Agile wrong and they've got a different brand of Agile and a training course to sell you
> If Austerity is not working as an economic model; the answer isn't to invest in growth, it's to cut even more corners.
The do-more-with-less cancer that is infecting so many companies, where the tumor is Continuous Growth.
reminds me of the impossible fight for when someone forces themselves into a project and prescribes "industry standard" off-the-shelf solutions, to a problem that requires an engineered custom solution.
And when the final product isn't fit for purpose, what do they say when their decision becomes visible?
the off-the-shelf solution is never at fault. It's your execution. You architect your solution wrong. You didn't configure it right. You just didn't adopt it fully enough. The answer is always to dig deeper into the solution and leverage more of its features.
The problem is that the off-the-shelf solution doesn't even have the right feature set needed for the job in the first place.
This applies to everything. If your coding agent has problems with non-trivial programs, it's your fault, too.
I actually agree with you but I love that the response was just a long version of "you're not doing it right!"
I've seen similar effect with Montesori, Waldorf, Kumon methods. If something is wrong, is because it was misunderstood, or not properly done.
Aren't these just examples of sunk cost fallacy?
If brute force is not working, you are not using enough.
Yup. Agile definitely suffers from the "nobody ever tried Communism correctly" argument. As far as I'm concerned Agile is: A) nearly impossible to get right, and B) not particularly helpful at unfucking poorly run projects.
It's definitely not a magic bullet and I suppose the only reason it's had the staying power it has had is because unlike other project management philosophies, it has an extremely profitable "Agile Seminary" ecosystem.
> I feel like I see it all the time.
That’s because it’s a common trait in ideologies. It predates Agile by a couple of millennia. We could add to your examples things like "if it failed, it means you are not pious enough; make more sacrifices", or "if the offensive fails, it means that you are not committed enough; bring more men and more artillery", or "if <whatever totalitarian idea> fails, that’s because people don’t believe enough; purge them". There are many, many examples in History.
This is the horseshoe theory of Agile. If you do Agile hard enough you end up at SAFe which is basically waterfall.
Waterfall disguised with other names and extrem expensive certification.
> if it fails, it is only considered evidence that you were not doing it enough.
20 years ago, this was the meme about XML.
More seriously, this was also the answer about Communism.
Communism comes to mind.
It's led to misery every time - but it's always because they just "did it wrong"
> In that: if it fails, it is only considered evidence that you were not doing it enough.
This is a cult tactic, for what it's worth
[dead]
> In that: if it fails, it is only considered evidence that you were not doing it enough.
Good way to ensure devotion to a process rather than devotion to a desirable outcome. Seems distinctly cult-like.
It's basicy gas lighting at this point
Isn’t Communism the original here? It’s often claimed that all historic attempts to establish Communism don’t work cause it wasn’t done in the right way.
In all seriousness, this pattern is probably hard to avoid in any reasonably complex entity/environment. If any such situation would be solved in a global solution (aka silver bullet), it would be used by everyone. As this seems not possible, any framework like Agile, Communism, … can only be a guidance to be applied locally, and broken internally and by external factors in many ways
Religion. Your life isn't better because of {not devout enough, didn't self-flagellate enough, didn't donate enough to the religious leaders/church/god, committed some other sins, belief is lacking}
Dude, this mode of ex post facto rationalization is waaaay older than communism. It's basically one of the main "retention warnings" of most religions.
Strategic Bombing - the idea wars can be won from the air alone - is the absolute worst of these. It's a religion that might well someday kill us all, or a great many of us. In the quest to dot it "enough" . . .
On a lighter note . .
The world of overly-complex CCS (component content systems) like DITA has made this "Agile flavor of treadmill[1]" into the entire business, greased with liberal squirts of FOMO and "Industry Standards".
It rhymes with capital A Agile in many ways, although in the case of DITA specifically I'd posit that the underlying assumption of the spec is a vast category error: that natural language has formal types.
[1] i.e., "you aren't doing it properly" . . . and with every change in technology the DITA / XML priesthood claimed to hold the keys to unlock it. SEO? Information Typing. Web Content? XML/XAL pipelines. Big Data? Content granularity. LLMs? Information typing and schema will "help" llms and not just be an unholy clog in the guts of vector embedding operations. And yet, the years go by, and all of it has worked and continues to work fine without switching the world to DITA (and a writing universe of strict validation based on speculative assumptions).
I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.
For reference, here's all the Agile you need, it's 4 sentences:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.
> […] when applied to small, excellent teams.
Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.
That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.
I don't really have a better answer, though…
I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.
Yeah, managers adopt agile to try to un-fuck their organization but it doesn't actually do that. You need an un-fucked organization first.
It's not a system of management and it won't work if the way you're managing sucks. Nothing targeted at a similar "level" as the various "agile" systems will either, though.
That's it, "excellent teams" are a needle in a haystack; the mythical 10x developer, if you will.
But at one point you need not one team, but a hundred.
I'm wondering how many production strategies strictly can't work with "excellent teams", small or otherwise, barring gross incompetence or intentional sabotage.
> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.
Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP, arguably the first agile methodology, very clearly and deliberately stated that this is nothing new, just a distillation of things that experience has shown to work well.
Anyway, at my next job I introduced agile (small-a-agile) to a team that was anything but skilled. In fact, that team was where the leftovers of that particular development organization had been shunted (public company, very difficult to get rid of people). When I arrived, the team was as non-functional as the software it was responsible for. Well...
We rocked.
And all the team member improved dramatically in skill during my tenure there. Including myself.
We did not do Agile. No scrum, no standups, no sprints, none of that BS. We were agile. We focused on the technical practices. Test first. Red-green-commit. To trunk, obviously. Because if it's green why on earth would you not? Do the simplest thing that could possibly work. We had a design for a database and then never found a need to put it in...so we didn't.
It took a while for the other parts of the org to adapt to this. The answer to the common question "well, when can you deploy?" was always "now". Well after a quick look that the tests were, in fact, green. So they stopped asking. The tests were rarely not green, and when it did happened there was usually a quick "Oops, I'm sorry" and they went green again a couple of minutes later. Our ops team got bored very quickly. Put jar on box. Start. Forget about it.
What made the experience scientifically interesting is that we had a control group: the main team, much larger, working on the "important" software with all the "good" engineers started with a new project about the same time we did.
They did Agile. Capital-A. Scrum, sprints, standups.
They did not deliver and in fact the project had to be completely reset about two years in. My team-lead (we were co-lead, I did mostly internal/technical, he external/managerial) then got to take over that team as I left for Apple.
TFA, incidentally, is just about as good summary of misunderstandings of agile as I've seen.
Not much to add just wanted to say I share the sentiment and it matches my experience :-) . I'm not smart enough to NOT keep it simple; 90% of stuff I work on at $company is really a CRUDbox and I do NOT want to "astronaut-architect" the whole thing. Comprehensive test-suite, push to prod multiple times a day, feedback, dev.
That's it really.
Thanks!
> I'm not smart enough to NOT keep it simple
Yeah, sometimes I feel that most of my "amazing architecture skills" is not understanding what 90% of that stuff is supposed to do or why, and hey, maybe we can just do without it?
For reference: what we did was replace an existing system, which was running over a hundred processes on about a half dozen boxes. We replaced it with a jar.
The jar was around 1000x faster, 100x more reliable, 10x less code while handling around 10x more of the domain.
Not to take away from your point, but that sure does sound competent, aligned, and motivated to me!
Yeah: as a result of doing small-a-agile for a while.
Not at the start.
I guess if the point is that agile doesn't work for incompetent teams because teams become much more competent through agile, then I'll concede the point.
They are conditions to be met. It's not enough to proclaim them as "your process" and expect results.
When playing piano, the condition you are measured by is acoustic harmonies in the air, not finger movements. The only reasonable advice is either practice more or give up. If you are tone-deaf, it's not reasonable to expect you will learn to play the piano.
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th."
"Oh, feature no 32 is going to take months and we realised that users can just...."
"No"
> "You're going to do agile .... and this list of features will be ready on September 20th."
Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then.
We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable.
This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.
Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.
If the org focuses on the customers one can work together to find a way.
What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.
When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
Right, that's deadly. We try to do small refactorings when we can, but for hard deadlines everyone is reminded to keep their focus on what's required for go-live. And if it starts to slip, one has to be dynamic and be ready to search alternate, perhaps temporary, solutions.
> "You're going to do agile .... and this list of features will be ready on September 20th."
That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.
Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not.
Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.
Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings.
It's a farce.
Ah yes, the old Agile-as-drunken-waterfall pattern
Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.
I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??
Not sure what the solution is. There might not be any.
> Working software over comprehensive documentation
this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.
Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.
If it’s good enough for a space program it’s good enough for pretty much anything
I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about.
The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.
One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.
It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.
Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/
It's got loops and infinity markers, AND iconography representing humans!
I almost threw up looking at that. Please mark things like that NSFW!
Agile, as implemented in every big company that I've worked for, was a lie.
It was really telling at a smaller company that was trying to behave like a big company. I asked a coworker (who had great metrics) what the secret was for dealing with the middle-management-heavy and quite dysfunctional environment. He told me how he did it. Paraphrased: "It's easy. During each sprint, I work on the next sprint's work. Once it's complete I'll know how to make sure things match the work that's already been done and that way its always a bullseye and on time - because the work is already done.". Agile at that company was a joke to the people who got things done, and was a weapon used against people who didn't realise it in time. It sure generated a lot of metrics and stats though. I used to joke amongst coworkers that the company produced metrics, not products.
I've also seen agile hollowed out to become a metric delivery system that keeps managers happy; They know what everyone is doing but it keeps upper management happy to see those metrics trend upwards so the wheel keeps spinning. The actual product ends up being a byproduct of the stats.
How did he see into the future to know which work he'd be doing on the next sprint, and how did he also finish the current sprint's work with a bullseye thus allowing the next sprint's to begin and match it?
From my reading, it's really quite brilliant. He just says that he's about to start the tasks that, in reality, he's just finishing up. Then he delays reporting that the task is done. His estimates are then always made with perfect hindsight.
This only works though, if one is working in isolation and no one else checks out the work before the time one commits to the work. That would mean being some lone expert in that part of the product, which is not a good sign for the business, because bus factors of 1.
That's the neat part of agile / scrum / whatever at larger companies, they don't actually change priorities much from one sprint to the next unless there's a major external factor like an outage. Larger companies like to be able to look ahead, at least a quarter but ideally a year or more.
At my current contract we use "SAFe", "scaled agile framework" which basically revolves around quarterly plannings, but above that is a long term planning of course. (energy industry, scale of hundreds of engineers)
Not the op, but you only commit to what you already did in this sprint.
So this sprint shows what you delivered 2 sprints ago, next sprint will be the work you just finished.
I think it's worth linking to the original Agile Manifesto[1], because that's pretty much all the consensus you're ever going to get on what's "agile" and "what's not".
Lewis is right that most of these principles were described before the manifesto, but I can vouch for the near-impossibility in many contexts of convincing anyone who wasn't a coder (and a lot of coders too) why these might be sensible defaults.
For every person burned by a subsequent maladaptive formalization of these principles, there was someone horribly scarred before the agile manifesto by being forced to go through a doomed waterfall process.
Yes!
Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!
If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.
No, you are not going to get that consensus, because middle management and hire ups don't want to know what agile actually means, but want to continue believing, that the processes they impose are agile, and they have probably never even seen that page. In a truly agile team, the team takes many if not all of their work and responsibilities, so that even the jobs of PMs and low middle management would be on the line. As we know it is difficult to get someone to understand something, when their income depends on not understanding it.
https://agilemanifesto.org/
Ward Cunningham [edit: oops, it was Kent Beck] had it right, long ago, when he wrote in "Extreme Programming" [paraphrase]: You don't drive to Florida by carefully lining up your car in New York on I-95 South, locking the steering wheel, and then pressing the accelerator until you arrive.
This was really all that Agile was ever trying to avoid -- the tyranny of imaginedf omniscience. The bad old way (which I did labor under in the '90s) set up a Gant chart of dependent requirement up front, during a "design phase" which completely de-valued learnings and insights gained along the way as a software system was constructed during the "implementation phase". It was the best we had till then, but many software projects were failing due to their inability to adapt to unforeseen design flaws or to the feedback of stakeholders (once the software finally got into their hands).
I don't know why the ceremonies became ossified and sacred. I guess every movement must confront the danger of settling for form over substance. I do know one thing. You can't build an amazon dot com, a Facebook, or a Grand Theft Auto in a 1-million token context session with an LLM. I'm sure you can do it with many such sessions, but it won't be an LLM that ties it all together properly (again - too much context). And I say this as an enthusiastic user of agentic programming.
TFA first claims that agile invented none of the things it encompasses, seems not to challenge those claims, but then just jumps to agile is dead because LLMs can code based on spec.
This is just a confusing and confused article.
Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
We are still doing that and will be doing it in the foreseeable future. Agile is very much alive and here to stay.
Iterative development has existed since forever, since earlier than written history.
It is not something invented by the Agile proponents.
They have proposed a much more specific variant of iterative development, which at least as I have seen it implemented in any company which claimed to implement it, was really bad in comparison with the right ways of organizing development work, which I have seen elsewhere.
Any high quality product must be designed starting from a good written specification. Obviously, almost always the initial specification must pass through one or more update cycles, after experience is gathered through the implementation. This has always been universally used, not just by Agile practitioners.
There have always existed bad managers, who wrongly believed that a development process can always be linear and who did not include in their timelines the necessity for loops, but that was just bad management, so if Agile proponents pointed to such cases, those were just strawmen, not the best existing practices.
> Agile just finally embraced that specs are incomplete and can even be wrong because the writer of the spec does not yet really know or understand what they want. So they need working software to show the spec in action and then we can iterate on the results.
I agree, but what you describe is agile, not Agile (capital A).
Agile (capital A) is Scrum (capital S) where you have Backlog Grooming (patent pending) where the team clears any ambiguity to define a spec (ticket).
Deviating from said spec is seen as Scope Creep (gasp) and might lead to complaints during Sprint Review (trademark).
So yes, agile prefers working software over detailed spec. But typical manifestations of Agile (capital A) are exactly the opposite.
I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.
The point is the agent writes the specs and the human reviews and revises or asks for another rewrite that takes 90 seconds or less. So specs are both cheaper and better than anything I've seen before. They still get a lot wrong and it is hard to review them very carefully, but its easier than reviewing code to suss out design intent.
The point is that sometimes you don't know the spec is wrong until you've built the software and it's being used.
Still though, that cycle can be iterated many times in a single day. Write a spec, let the agent build it, use the software, evaluate results, repeat.
Yes, that's agile software development.
No, not quite. The specifications we use for agents make any ticket written before them pale in comparison. That enables a hybrid workflow that is both spec-driven and "agile", in the sense that you're doing very rapid development cycles.
Until the agents start touching things that already worked well before and break them.
They do need a competent developer operating them. That has nothing to do with whether nor not specs have value.
I think there is some good middle ground between spec driven development and iterations, like Compound Engineering. https://github.com/EveryInc/compound-engineering-plugin
> The Manifesto sayeth naught of Daily Standups, nor Agile Coaches
The manifesto says "Stop trying to micromanage your programmers."
It's written vaguely and politely but its spirit is the opposite of mandating daily meetings ("processes"), having trained coaches, or any metrics like story points ("tools").
As the explanation says:
> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
When Agile came about to company (large American corp) I work for, around 2015 (arguably quite late), I was quite skeptical. In my opinion, a decent waterfall (basically a sort of compromise) worked pretty well, and I didn't like fake "innovations" like Scrum or renaming everything in project management terminology.
Then I read Steve Yegge's Good Agile, Bad Agile. It basically says, Agile is just a Kanban queue. And I think I got it, and I think that's working very well. At least from the project management side.
There are IMHO three management angles to look at any engineering project - product, project and architecture. If you are building a house, you need a blueprint to tell where to put what concrete, you need a render (or paper model) that you show to a customer, and you need a BOM and a timeline to make the investors happy. The software is not different. But that's also where there are misunderstandings in what Agile is - the product management, project management and engineering all have different ideas what kind of "plan" is needed.
So in the case of software, specs are like the house's blueprint. In some cases, specs might be useful prototype, in some cases not. It's just not the type of plan that the project or product management cares about.
Regarding the project management angle, for me Agile today is clearly Kanban, and almost everything else is wrong or not required. I often make an analogy with computers. In the 50s and 60s, people tried to plan the work that the computer calculates by creating some scheduling algorithms that plan ahead the use of resources, avoid conflicts and such. Eventually, we found out that simple dispatch queues work the best, don't estimate at all how long the task will take. Just give it a priority, a time slice, and let it run. And I think the same applies for the SW development. And I think it's time that project management people take note from computer scientists - they already know.
Doesn't mean SW development time cannot be estimated if you need to, it's just not a very efficient to do so (it takes extra time, depending on how good estimate you want).
I watched a video a few years ago where one of Kent Beck, Martin Fowler, Jeff Sutherland, Ken Schwaber, I don't remember who exactly, explained what they wanted to do with the Agile Manifesto, what screwed up. He explained that they wanted to give guidelines, not a strict rules. They wanted flexibility. But people started selling this as courses, business, rules. Some Agile practitioners become fanatics on the topic. And this created misunderstanding and chaos :D
For 20 years, I have seen it working and not working, and the reasons are a lot. It can be affected of level of expertise, quality of documentation, pressure from management, engagement of the clients, etc.
Simple example of failing, and how one of my team overcome it. There is no specification. Option 1: team complains that the specification is bad, and this makes the code quality bad. Option 2: the team pro-actively prepared the specifications, gave them to the client for approval. Writing the specification was, a kind of, added flexibility, that was introduced in the sprints.
Another example, why should the sprints be fixed at 2 weeks. Sometimes, people try to finish for two weeks and they produce bad quality code, because they are time pressured. Be flexible and make them 3 weeks, if the sprint includes things like, preparing specifications, or if the sprint includes pauses for bug fixing. :)
So it is not the Agile that makes the project successful, it is the people. Agile just help for tracking where you are , and what you need to do ;)
Now with AI, you can use Agile again, there are agentic frameworks that support it and they give good results, in my opinion. If the people use it wisely, think what they do, and try to do things better, it will work. Of people are lazy, don't know what they are doing, don't have expertise on software development, it will fail :)
What does "writing specs" here actually mean? Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth. A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
Oh that was it you're right. We have those documents but they are full of lies. Yet everyone can read it and believe it to be true in the way they want it to be.
Traditional design doc review processes aren't perfect but I'll take them over Radical Ticket Anarchy any day of the week.
> Every agile project I've ever worked on has had a design doc that laid out architecture, the basic shape of contracts, dependencies and so on. In fact, the agile artifacts(tickets, estimates, epics etc.) have always been downstream of a design doc source-of-truth.
That's not agile.
> A project where all the work comes directly from tickets with no overarching, agreed-upon document on what the end goal is supposed to be sounds hellish.
Maybe this is why so many people can't even try to do agile. It sounds bad. But it works great.
In an actually agile project or organization, the source of truth is the user of the software, because the developers periodically and whenever else necessary talk directly with the users and listen to what they have to say, and put that into writing.
In a fake agile project or org, the source of truth is a made up document written by the PO or PM and only remotely related to what the actual user says. Devs are kept away from the user by their higher ups, who seek job guarantees.
Author here.
Well I think this just proves we can slap "agile" onto anything. The people before agile actually wrote things with more substance than the manifesto.
The agile projects you worked on sound wonderful, and I would align "writing specs" with what you describe, at least in terms of the design doc.
Ran into the same wall - ceremony eating the actual work. The Flight methodology cuts through it: a landing date, a single captain, no story points, no mandatory standups.
The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."
Handbook: https://agile.flights/docs/introduction/why-flights/
Oh no, the kids are going to invent agile again aren't they?
Aigile
Stay hopeful, maybe Nu-Agile will become annoying in new and interesting ways!
Perhaps needing to estimate tasks in cloud credits? That would be a new one. And then of course mapping those credits uselessly to time needed.
Maybe you gotta do daily standups with all your own Agents and then have both you and them do standup with the rest of the team's Agents to touch base, sync up and loop back or whatever.
Author here.
So one of the main points in this massive, 700 word Treatise (which I do hope you will find the time to read) was that nothing Agile practitioners slapped their label onto was actually novel.
Why re-invent agile, when agile itself was just a reinvention by "the kids" (your words, not mine) of things people in the 1970s already knew?
One might as well go straight to the 1970s directly.
Yeah I read it and didn't get the point. So agile is dead? And we are now doing waterfall due to Ai needing unambiguous specifications? But also agile was nothing new because they knew that waterfall didn't work in the 70s. But now it works? Or are we still doing iterative development but the term agile is banned as unoriginal?
I am not Kent Beck; I don't have all the answers.
All AI has shown us is that we should probably write specs before we code. That was true before AI, but LLMs have just shone a light on this, and it will remain true if agentic coding falls out of fashion again.
Never once did I advocate waterfall...
Read the Royce paper, seriously. It's short, he's a much better writer than I am, and if nothing else it's a fascinating looking at the old state of the art.
There's a problem with any formalisation of patterns like Agile and other things like SOLID, Design Patterns (GoF) etc.: if you never saw the world before them, you will never appreciate why they exist.
Is anyone actually doing true waterfall development any more? How would that even work with the amount of open source software in use? The world is fundamentally different now than it was 25 years ago.
Stuff like SOLID and Design Patterns etc. are such good ideas that they've been incorporated directly into the design of modern languages and frameworks. It's natural that someone would pick up Design Patterns today and think it's all pointless. That's because the book was written in 1994 and it wasn't pointless to say it back then.
I guess this is why history tends to repeat itself. Many people can't internalise why something is bad unless they've experienced it themselves. Many more don't even read about it in the first place. Scary to think.
The problem is reality.
I've found that Finance, and the Tax Office of any government, rarely care about your Agile processes. They have their yearly cycles, and C-Level will always want to follow _those_ cycles.
Then, for those that have schoolgoing kids or work with people that have schoolgoing kids (aka: everyone everywhere): there is the school vacations cycles.
These too rarely care about your scrum rituals or PI planning. This means that your calendar is not a reflection of reality: July/August barely exists. Same goes for November or December. And at the same time December is full of actual deadlines due to end-of-year financial cycles.
And finally: the complexity of the work itself rarely lends itself to the linear timelines people expect.
Rarely have I met a Product-person, or a SCRUM person, that actually understands this. And can account for it in their Agile way of working.
End result: a continuous stream of disappointment. What fun times we live in.
Then don't use it in those environments. Agile is not a silver bullet, nothing is.
I don't get the negativity, there's plenty wrong with agile (notably the hours of meetings) but all in all, it's a method and I don't see anything better right now.
I personally have never worked in a team where Agile (the concept) has failed. But I've also seen it fail all around me. Especially when it's mandated without buy-in. Or when people just don't "get it".
e.g.
- 45 minute "standups" (!?)
- PI "planning" that consisting of deadlines and glorified multiplayer MS Paint
- Rigid adherence to ceremonies or processes that add zero value
- Retros that focus on complaints and venting with no actionable outcomes
- etc etc
Every time I've introduced Agile to a team or project that was new to it I was always met with skepticism. But 6 months down the line noone on the team/project wanted to go back to the "old" way of working. I don't even really care about any text book definitions. These are the only things we try to stick to:
- Short, daily standups
- Planning based on risk reduction
- Estimates based on complexity (ties in with risk reduction)
- Actionable retro items
- User demos every sprint (makes it easier to pivot - users rarely know what they want)
Venting is important. When you don't, tension builds and then explodes. It's necessary to give people a way to air complaints and be heard. And if your team has people with some organizational and social skills, you can channel that into action.
> Venting is important.
Of course. But you shouldn't run retros that are focused on it.
Sure, but if people are using the retro as a vent session, maybe it's because they need an outlet. Perhaps a separate meeting titled "vent session" is what you want. Although it's important to have action come out of that meeting as well, don't want to just channels peoples' real concerns into a meeting that is intended to hear them out and then do nothing. Manipulating peoples' concerns into a channel where they are made unobstructive and ineffective, so they can be easier ignored is a pattern of bad-faith bosses. Conflict avoidance is toxic. You and the team building skills in conflict resolution can help.
If you don't care about definitions, then it would be good to not perpetuate using the word agile for your own set process. "Individuals and interactions over processes and tools"
If your company doesn't fundamentally want "agility" then it will be an exercise in futility but if you're a person who doesn't want to do useless work then you're an agile proponent fundamentally.
Good. I've worked in several organizations where we had Agile.
With the years, I've come to think about it as a sing and dance designed to make the project managers, PMs and sales feel like the actually impactful ICs considered them.
There's something really absurd about making programmers sit down and say it's a 5 or 8 effort, then punish them for being "wrong". All it achieves is reduce velocity at best, with the illusion that it's for the greater good.
Worked in and managed a few "Agile" teams. Never heard of a dev get punished for a bad estimate. Can you describe exactly what you mean?
1. estimate this sprint. let's say it's 100 points. 2. oh no, you shipped 80 points. 3. "we need to better estimates":
a) engineer spends more time trying to guess which direction the wind will blog b) engineer starts sandbagging estimates c) engineer changes nothing. looks bad next time the imaginary goal isn't met. "bob needs help estimating".
Yeah okay. Thanks for clarifying. I guess I thought when you said "punish" you meant something more dramatic!
> 3. "we need to better estimates"
Push back on that. Agile says other things are more important.
The problem with spec driven development is that your specs are never complete, and for sure contain inconsistencies, wrong assumptions, etc.
So now you write specs, and then an LLM, which is known to be overly compliant, will handle the implementation. If you don't see the issues with this workflow, you for sure have learned nothing about how the software development process evolved.
The way the author defined water fall makes it sound pretty good to me.
Put your hand up if you are ever programming with poor specs?
Put your hand up if you have a better idea of what really was wanted after the first cut?
And what I really dislike is those that try to design a Swiss Army knife from day one when they haven’t a clue. Jump immediately into over complexity.
Wasn't the whole waterfall model originally a caricature to higlight all the issues one will inevitably encounter if they eliminate feedback loops and go with a strictly sequential development paradigm?
Author here.
Yes, that would be the first paper I linked to in the article, "Managing the Development of Large Software Systems" (Royce, 1970).
The first diagram is the classic waterfall diagram, used there for illustrative purposes as an example of what not to do.
Highly recommend it to people - it's short but a real breathe of fresh air. Mostly still applicable today.
LLMs and AI coding do not change anything to the validity and wisdom of the Agile Manifesto and principles. It's only a new tool in the tool box.
It is difficult to take the author seriously after his claims that the Agile Manifesto is only "platitudes" and "near devoid of meaning"...
I think that Agile in principle is a good idea, keep iterations small and work on the issues together and deliver working products. The missing piece I think is that PDCA (Plan/Do/Check/Act) cycle isn't being done correctly. The idea is not just to improve the product but to improve the process of creating the product. This may mean you stray way of the path of the Agile system but that doesn't matter, the standard Agile process is just a starting point, it's your shop, create it how you like.
I like a saying from the LEAN manufacturing culture - "The Process is the Expert" but that comes with a caveat, each and every team member is a Process Engineer!
> and at worst it was commercially unworkable ("Welcome changing requirements, even late in development")
It's been workable for me. We can change the requirements as late as you like, because I'm getting paid by the hour. Scaled up to a company, that translates to not giving a fixed price for anything.
If you need to give a fixed price, either be experienced enough to know by how much your agreement can change and factor that in, or turn it down. You should also turn down demands for a fixed price on novel solutions you can't have experience on.
I'm curious whether it's the author's contention that the signatories of the Agile Manifesto thought that the ideas they were championing went back only a few years, and they had no idea they went back at least 30. In particular
> All of these things were later claimed as Agile innovations
Are there some references that demonstrate that? [EDIT: that the signatories thought they were their own innovations]
And if so, is that a bad thing? Ideas are repeatedly rediscovered. This article isn't called "Saying goodbye to Royce, Bell and Thayer", and I'm wondering why not.
Yes, there is an entire narrative that first there was chaos, then there was waterfall, and then there was agile.
For example, https://www.infoworld.com/article/2334751/a-brief-history-of...
It's as if people believed that all the microcomputing software of the 1970s and 1980s, from VisiCalc to Zork to the Macintosh, was done by waterfall design.
Right, some people believe that. But did any of the signatories of the Agile Manifesto?
Oh, absolutely not.
As others said, if agile fails, "you were not doing it enoug".
But if agile is criticized... only worse alternatives are given, if at all. Here, spec-driven development is inferior, as in most cases the goal is only vaguely known. Cyclical development is not some hollow mantra, it is how life works. All the rituals around it were just to faciliate more communication. A lot of people in this field just hate that, they want their tickets and to be left alone.
Now that implementation cycles are even shorter, there is even less manual need for coding, agile methodologies will be actually more prevalent.
Here is one experience I did not maybe consider enough:
the teams that behave the closest to what the Agile manifesto seems to define as agility had three things in common, two of them were inside the team:
1. emotionally mature team members
2. competent team members that were able to deliver and knew their strenght and acknolwedge their unknowns
and the one item outside the team:
3. Trust and respect for them from the business leadership
Of course having these 3 things makes any SDLC work
I'm of the belief that most project management voodoo is just that - voodoo. There is no rigor, there's no formal basis for ideas, and there's no testing of hypotheses and rejection when evidence counters it.
Engineering (even in computing) has a formal basis and practice. Project management does not. Systems thinking and industrial organizational psychology does, but rarely do you see it applied like bullshit such as agile (and in environments that do - it works spectacularly).
Out with the voodoo, and in with the scientific method, I say.
> One unambiguously positive development that's followed is that software professionals are writing specs again.
I feel this in my core. There has been a period of the last 5-6 years where folks have stopped writing specs entirely and it has driven me nuts. Everything is a story or some other abstract requirement. The absence of a specs has made software worse and less predictable in my opinion. All hail the specification!
> One unambiguously positive development that's followed is that software professionals are writing specs again. LLMs - like many of us - do not perform well with ambiguity, and specifying problems is proving to be an effective tool for generating correct code.
Replace "LLM" with "compiler", "specs" with "code" and "correct code" with "correct machine code" and we are back to square one.
Gather requirements -> Small focused spec -> code -> Validate -> Fix/Adjust -> Remove spec once it is captured in code and tests.
Agile is stronger than ever, spending time on every small detail in a waterfall approach makes you burn human time on work that most probably could have been perfectly fine with a default approach.
Context matter but I fail to see people spending months on planning out a system before building anything.
If the term "agile" didn't have such double or triple meaning, it may have worked. The term itself promises too much with little context and it was always too easy to fall into the trap of "being agile" because, why not? Agility is a valuable trait in human terms.
If we just put enough effort in and write the right spec/prompt/design then the programmers/llms/plug compatible coding units will produce the correct output first time!
Closing feedback loops. That’s the whole thing. WE Deming would have recognised agile (little a) as a PDCA system and approved.
Saying the Agile manifesto was void of meaning is ridiculous.
- Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan
The problem is that the Agile industry mostly didn't follow the Agile manifesto and ended up with monstruosity like SCRUM, which is all about processes over people.
Daily Standups, Retrospective, Backlog Grooming = PROCESS
This crap should all be replaced with async written communication (for quality of life and recording), but each team should ultimately be free to decide.
The Agile manifesto was all about freedom and it was turned into a jail.
SDD has no real track record.
It's only a promise of a method.
If you think it's waterfall again: Wrong.
Everyone who phantasizes about "just"™ writing the perfect spec will be in for a rude awakening.
The spec will change over time and your initial version will turn out to be very wrong.
I've written something similar https://blog.dochia.dev/blog/waterfall-returning/ As code is less expensive, specs are the new bottleneck.
Getting the requirements right was always the hard part. Hence agile.
Yes, exactly. We move cost in another place. When you look holistically at a (complex) project, efficiencies are not that big.
How about "documentation driven development"?
So many times I have found myself writing the end-user documentation (even after writing tests for the code), and realized that the design should change.
This is the kind of post that makes me log in to hn to give a vote.
These arguments are pointless. Working software is shipped using either method, some combination, or no method at all.
Hell, half the devices in your life probably run some hacked together crap that was built by people who barely knew how to program and eschewed version control for USB sticks.
I really hate discussions of "software" as if the software in an F-35, the software presenting data on a webpage, and the software making a child's toy blink and speak are all the same thing. Only in a very abstract sense are they similar.
Doesn’t the F-35 need to be rebooted on a regular basis to keep it running. That sounds exactly like my TV.
Spec driven ddevelopment.. ahh yes, because the formal methods era of computer programming was so quick and successful!
Let me find my: Requirements Specification Requirements Analysis ...
The circle will turn once again when people re-realise that by tue time you've written what should happen in enough detail, you've written the software, and English isn't that great at avoiding ambiguity.
I wonder if there is no AI product yet which runs scrum ceremonies, assigns user stories in planning and computes story point velocity after the sprint ends.
That's clearly a human's job. The AI's job is to do the programming.
If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier.
The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect.
In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up.
What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence.
This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.
And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.
Which means Agile will always be more expensive, time-consuming and difficult than alternatives.
Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard.
And there's two basic ways to build it: with plans, and without plans. Without plans, you have to design it yourself, then try to build it, then make mistakes, maybe even to the point you have to start from scratch. Time-consuming, expensive, hard. But start with plans that have already been built, and you benefit from somebody else's time, money, expertise and toil. The boat is built faster with less effort and fewer mistakes. And instead of needing master craftsmen, you only need journeymen who can follow orders.
No, that's not at all what it means.
It means, that you need capable engineers, who are willing to talk to users and build understanding, rather than just being Jira task rabbits. It means, that you might not even need all the intermediaries, each having their own personal agenda and incentives, that engineers usually have to put up with. It also means, that certain layers in an organization have to trust their employees a little more.
It means, that what you build it based on user feedback, rather than what someone tells the engineers, what the user feedback supposedly is, without having a clear idea, what the users actually want. I have seen this first hand. When in the beginning of the product I as an engineer interacted with the users and found out their issues with the platform I was developing, later on the organization added hierarchy layers, shielding or preventing engineers from talking to the users, to build their own job moat, and patronization going on in terms of "Your time is better spent developing the actual features.". In the end the product ended up drifting far from what is good for the actual users, and instead people talked more to B2B customers, than the employees at those other businesses and what they actually need or want.
With each additional layer between the user and the developer (which is also people who want to be paid btw.), the business is inflicting significant cost and increases the risk to steer off course.
Someone once described agile as this: Its just pantomime and posit notes... implying that the process (from the outside) was more performative than anything else.
From "scrum masters" to "planing poker" it's all very silly.
That’s Scrum you are thinking of. Not agile.
This post sets up a straw man from the outset, and only gets worse from there.
I understand how we got here, where many experienced programmers, managers, and bloggers only know capital-A Agile as the watered down version sold via certifications, crummy medium posts, and atlassian flavored kanban boards. But that isn't agile.
I can’t even with the pitch into spec driven development as some sort of high watermark of software methodology.
But if Agile is going to die, what are Scrum Masters going to do?
Same as before: nothing.
And good riddance too.
Agile was always aiming to solve the wrong problem (that code is the bottleneck) but it turned out to be a massive lie exposed by LLMs.
It’s always the poor specs, terrible analysis and release constraints that kill projects.
"Agile was always aiming to solve the wrong problem (that code is the bottleneck)"
No, it aimed to solve the "out specs are bad and we need to iterate faster" problem.
"a massive lie exposed by LLMs"
No. LLMs add no insight about the problem and they expose nothing. They just help to engage this well-known problem with another tool.
Not in my experience. AI exposes the truth that agile as it is practised is a huge waste of time. All the bullshit ceremonies and short sprints were designed to get code squeezed out faster, no matter if the code actually addressed the goals of the project. The stupidity of agile is in its iteration speed since you can be handed utter crap, implement it to hit your story points and find out the drooling shitgibbon who wrote the specs phoned it in so your work is now wasted. Rinse, repeat.
> always the poor specs
But that is fundamentally what agile is about. It's not about coding faster, it's the recognition that the specs are incomplete or wrong because fundamentally, a lot of customers cannot tell you what the want until they see it. That's why "build something simple and iterate on it" works. Regardless of how good your spec is, once the coding is done the customer is going to realise that that's not what they actually wanted.
This is a weird backwards logic to justify terrible analysis
No this is literally in the agile manifesto. It's not logic at all, it's the written word of what agile is.
What that means is that Agile and agile are not the same thing. Most companies practice Agile, very few are agile.
Agile never claimed that.
Agile is about working code instead of hundreds of pages of spec nobody reads.
Ironically the AI guys are now saying good spec is what we need for the agents to code. So which one is it
>It’s always the poor specs, terrible analysis and release constraints that kill projects.
So most of the problems are related to business people and not the development teams? Who would have guessed?
Holding analysts to account would be a good start. Agile lets them get away with laziness. It’s always “oh sure we got that wrong better luck next sprint”
Lucky me, I've never had to say Hi Agile in a first place. It is a tumor. Been in programming since 80s. Mostly on my own except 6 years long stint at the company. Quit in 2000 from position of CTO
at the same time, how can you judge something so harshly if you've never experienced it yourself.
Because I had "pleasure" watching others doing it. One does not have to step into shit personally
A requirement specification is how you prompt software engineers. One-shotting it doesn't work (waterfall). You need to put the SEs in planning mode. They will ask you questions and refine the plan. And you end up with a better plan. But if you make it too complicated the plan will go off the rails. So, you need to make them assign Fibonacci tokens to their planned tasks. Now you have a better plan and you can assign your SEs to tasks and get them working on it. Fibonacci tokens are not time units. This is very important. But you will run out of tokens after two weeks. So you need to buy some extra pizza tokens and make them work until midnight (crunch time!). That's how you get the job done. Every time. Sort of.
I bet some jerk is going to organize a multi agent scrum process at some point and burn some tokens on this nonsense.
Absolutely awesome, thank you, Lewis!
Feels like another bad idea from management born in the silicon valley
[dead]
[dead]
[dead]