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.
> 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?
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 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 :)
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?
> 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.
> 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.
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?
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.
> 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.
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.
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 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.
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.
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 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.
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."
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)
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.
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.
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!
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 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.
> 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 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. 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.
> 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!
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.
260 comments
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.
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!
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.
> Another way of phrasing this though, is that it's in the team's power to determine process (or the lack thereof).
Which they almost never have.
"We're going to do agile by following this rigid process" is an oxymoron.
> 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?
> Agile is defined as the process that works
Can you show a reference of where it is defined like this?
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'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 :)
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?
You can never use enough tokens.
> 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.
> 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?
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?
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.
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.
>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.
> 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.
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.
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.
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.
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.
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.
> 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.
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).
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 :)
The tagline from the handbook: "Agile started with a manifesto. It ended with Jira."
Handbook: https://agile.flights/docs/introduction/why-flights/
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.
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)
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.
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.
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.
It is difficult to take the author seriously after his claims that the Agile Manifesto is only "platitudes" and "near devoid of meaning"...
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!
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.
> 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.
> 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.
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. 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.
> 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!
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
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.
Closing feedback loops. That’s the whole thing. WE Deming would have recognised agile (little a) as a PDCA system and approved.
- 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.