Less is more agile

Waterfall was not the name given by Royce to the multi-stage model of software development but it's easy to see how it got called that. Boehm called it "Waterfall" and used it as a foil for his own ideas in the spiral model, which was a pretty good description of a "middle-out" sort of process with an emphasis on feedback and customer support.

The Royce paper saw the one-shot waterfall as unrealistic even with the project alternating back and forth between phases. It ends with a complicated-looking process of writing two systems. Estimation of time to completion or cost is not really solved there.

But really what people mean when they refer back to Waterfall is the idea that you can put a reasonable upper bound on cost and time to completion of a larger project while keeping a maximum lower bound on functionality/scope.

Even in the 1980s, people were looking at business software systems and thinking they were pretty well defined in terms of complexity. A database, a bunch of data entry and data retrieval screens, some online functions, some batch functions. Maybe you could specify these like a builder specifies a concrete sidewalk. (A literal example from a software engineering book). Then estimation should be possible.

The trouble is that the requirements of a multi year project are often out of date before the project is started and many specifications are underspecified until the customer has seen something like the final product. So why not plan around change? Bound the budget, allow some schedule time, and see how much functionality can be built in that time. Let the customer prioritize parts of functionality and the developers work smoothly, and the whole team can stay in a mode of delivering functionality frequently.

Royce 1970. https://dl.acm.org/doi/pdf/10.5555/41765.41801

Boehm 1986? https://dl.acm.org/doi/10.1145/12944.12948

> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference.

The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team.

No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue tracking. Deployments scheduled every Tuesday when their QA person signed off on the feature working as expected (this was in the days before CI/CD became common).

Worked great. Low friction, they got features and bug fixes, we didn't get hassled, and we could set up a call (or usually just a couple of emails) if we needed clarification or needed to explain why something was more complex to do than we or they originally thought. One of the best six month periods in my career, and I've been doing this stuff for almost 25 years.

I don't mind some aspects of scrum, but the things I don't mind (mostly around team autonomy and self-organization) seem to be the same things that are quickest to get thrown out when someone gets impatient.

If you don’t have a good idea, don’t even start. The problem with a lot of projects is they focus on the process (because it’s easy) without having a good or clear vision to begin with.

If you have a clear and compelling vision, then everything else falls into place.

Start with no process and add (sparingly) as needed. Always treat process as the least important thing on any project.

I don't agree with the "no estimates" sentiment.

My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically.

However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we make up these elaborate games to create guesses for these conversations. Sometimes the guesses are close, other times not.

I don’t know what the answer is, but there exists a gulf between what developers and managers need. Both needs are equally valid.