"Waterfall" in the broader sense is inevitable. What we moved away from was "let's spend 6 months writing up a 300 page specifications doc for this new Operating System that will be handed off to 100 engs" to "a PM and designer can mockup this feature in a few days with some input from the person who will implement it, then the person who will implement it will build it with input from them along the way".

Actually 3 week long mini-waterfalls. :)

The difference now is more bureaucracy under agile.

Both agile and waterfall methods attempt to give you a pattern by which you can predict when software will be delivered. That's the main business value. The suits don't care how the devs operate, provided they can get things on time.

Waterfall tried to do this by trying to understand the problem as fully as possible, to liken it as much to previously solved problems, and to involve gurus to say "that kind of problem will take X amount of time to resolve", and thereby create milestones and delivery dates.

Agile instead said "look, we don't know enough at the start of a project to do that. Let's instead keep track of everything we want to do. Let's try and estimate each set of tasks (stories), individually. And then let's rank them in priority. We can measure how good our estimates are, we can modify them, we can generate more data and determine what we'll have at a milestone, and then can either push back the due date, or at least recognize that we won't be able to ship the entire feature set at that time.

Continuous delivery can be done with either one of those (it almost never is in waterfall, but it -could- be). But by itself it offers a business nothing for planning purposes. All it does is allow an immediacy, a "as soon as it's done it's out in front of the users". This may or may not be a good thing to the business, but it doesn't solve the basic issue that business people want to know when they can expect a given set of features to be live.

The larger the batch size, the less time you spend designing, coding and delivering, and the more time you spend (mis)managing the batch - what goes in it, changing what goes in it, planning what goes in it, explaining what will go in it, explaining why half of it didn't go in it.

All of this invites a certain type of personality who is not incentivized to deliver but to talk about delivering. That is when the horror stories start.

> Nope, this one’s in the bin, I’m afraid. It used to mean “not waterfall” and now means “waterfall with a status meeting every day and an internal demo every two weeks”. We have to find a new way to discuss the idea that maybe we focus on the working software and not on the organisational bureaucracy, and that way does not involve the word…

I've noticed that demos tend to lead to "demo driven development" model where software devs write code to impress other software devs, without any real connection to customers, and with the benefit of a decade of time most of those got dustbinned pretty quickly.

I've definitely experienced this. A large waterfall development group decides to call themselves Agile. They start proclaiming their mutant fast-waterfall as the One True Agile, adopting terms and structures to appear Agile.

Then you get invited to the hour-long "standups" attended by dozens of un-involved people, "stories" that amount to poorly worded system requirements, "grooming sessions" filled with chickens and "sprints" with development/release cycles that look oddly similar to what we had before they started calling themselves Agile.

It's just a rapid waterfall. Call it "rapid waterfall," or just keep calling it "waterfall" and increase your velocity. It confuses things when people that have worked in Agile shops come around and try to understand what you're doing.

Sidenote - I'd probably title the article "How a ten-person team moved a government agency forward twenty years in two days."

The permalink says "spring" so "sprint" is an improvement on the draft title anyhow. :)

I just proposed to our team we move from 3 week sprints to 1 week. It's working out far better already. In part it's already waterfall done as sprints, so the duration is not as bad, but it's helping my boss stay a lot more focused on delivering and keeping in mind WIP limits.

I do draw a distinction on "Agile" between 'agile development' and 'agile project management'. Unqualified, I would assume "Agile" to mean "agile project management", in which case IMHO it's mostly garbage. The interesting stuff is 'agile development' IMO, the project management is context dependent and would tend to flow readily from a development project where:

- developers focus on releasing early & often

- developers are speaking directly to customers frequently

- customers/users are interacting with the software as it is being built and are providing feedback along the way

> Sometimes you have to sit in an office undisturbed. To Agile people, that's the worst thing ever, but fundamentally everything truly significant in software stemmed from that.

I would tend to agree. My impression is generic IT management, or business & project management stems from just the 1920s & has evolved only so much. There's a lot of emphasis on predictability, removing variation, reducing risk and maximizing utilization. (eg: Gantt [1], and there is someone else whose name I can't think of around the same time that was also as foundational). For the context in which that management was created, in part it's fine (ableit de-humanizing) - but for an industry that is more akin to a story writer than a factory worker - it's not really fine.

[1] https://en.wikipedia.org/wiki/Henry_Gantt

This assertion is nonsense. There's nothing magical about a couple of weeks such that it forms a boundary outwith lie impossible predictions. The validity of predictions depend entirely on the understanding of the problem domain and the complexity of the solution space.

The single biggest benefit from agile in theory, IMO, is controlling risk by getting the customer in front of the software sooner, so it can be iterated based on feedback. The primary risk being controlled is building the wrong thing. But you wouldn't develop e.g. an autonomous driving subsystem for a car that way.

Agile (scrum, specifically) in practice is too often used simply to chop large tasks into bite-size stories to be fed on a conveyer belt to a team of more or less replaceable programming cogs; the sprint scope keeps blinkers on everybody so they don't look too far in the future, they just keep munching through stories.

And when agile is used in this way, not only can it be demoralizing, but also extremely inefficient: a focus on user stories typically encourages building small features that involve narrow vertical slices through the stack of an application. That's hard to parallelize effectively - related stories will affect the same bits of code and cause conflicts. If you can bundle a bunch of related features together based on how they are likely to be implemented, you can slice them up horizontally, and implement the different layers separately, using things like APIs and data models at the boundaries. This paralellizes quite well at the team level.

It's still not great for software design. It's still a very blinkered approach; you're not going to design an application-specific framework that makes implementing features easy. It doesn't allow any space for experienced developers who have foresight, and relies on refactoring to create reusable domain-specific abstractions. But refactoring isn't a user story, and a team munching on stories isn't in a good position to think holistically about a problem.

"Work": I don't mean that the projects fail but that they fail in some aspect. Like they deliver late, or don't deliver the full requirements, or they don't deliver the real requirements (because the requirements were written 5 years ago by a consultant, this might be a total failure in many cases).

"agile" (not Big-A Agile the faddish cult) resolves a lot of this by one simple thing: frequent feedback between developers and customers while developing smaller increments. Which, ironically, was actually Royce's point in the paper: Feedback loops, not necessarily with the customer, need to be incorporated in order to develop large scale systems.

One of the issues in discussing this is that it turns out that when most people say "Waterfall" they mean a modified version. When you dig into what they're doing it's either a small modification (we bring the customer in during testing, which is good but that's still 4 years into the project) or a major modification (V-Model which incorporates all of Royce's feedback loops and then some). Others have gone to doing incremental & iterative development or evolutionary but still call it Waterfall because they don't know any other term.

But yes, Waterfall exists, it is a nightmare, and I hope to never be involved in it again.

I thought waterfall was to plan it out in detail, then do all the work according to the plan despite realizing that the plan is wrong, then finally, after disbanding the development team, test it to see if it works?

That's obviously a caricature, but if you have the feedback loop to see if it works while you're working on it, you might also call it agile.

Agile-ish systems work great when you don't have pre-determined delivery dates, but unless you are an internal-facing team with only a backlog of tech-debt to burn down... who is actually in this position?

Nobody can; that's the primary failure mode of waterfall. Anybody who is telling you to decompose a feature into that many subtasks might claim to be doing agile but they really are trying to do waterfall.

Taking things iteratively, small iterations, delaying decisions, learning as you go — that’s what agile development is. And all the stuff you mention above is possible when developing with agility.