The ONLY way to get quality is through quantity. That's the key insight.

Quantity of... dollars?

I’m betting releases and iteration cycles they’re tied to. The most agile place I ever worked shipped code most days of the week in some fashion. For control reasons we released Tuesday-Thursday not Mondays or Fridays. So was nearly every day something went out.

I’m including bug fixes here but nothing got stalled. We had a working iteration loop of Test -> Develop -> Test -> Review -> QA -> Release

Lots of automated checks, investment in infrastructure and good architecture made this possible. Ironically one of the smallest companies I ever worked for

Iterations.

"Breaks when you try to use it" is a quality that I can usually achieve on the first try.

Or did you mean some quality in particular?

I think this is true even in “civilian” industries. Can say doing this for over a decade now that I have worked at exactly one place that followed anything close to what was laid out in the Agile manifesto.

Every other place always sings the praises of agile and/or scrum but it’s always just waterfall with ceremonies.

I feel like the collective of how software is developed evolved little from circa 2006

The notion that gets talked about at Netflix is “context not control” and I think it would go along way if everyone looked at software development management this way. Too many people try to control software development lifecycles instead of just providing engineers enough context to get their work done and trusting that reasonable people will make reasonable decisions

Large organizations value predictability.

IMO it’s not this simple. Culture has more to do with it than anything. See my note about Netflix having this mantra of “context not control”. Managers are less inclined to be domineering in that setting and allow people to do the work in a reasonable way because they are given the context of why their work is being done in the first place.

Not perfect but a more than above average way to approach the problem yet this kind of thinking or its permutations have not caught on at all. It’s still top down process oriented models

What a bizarre claim. Agile doesn't mean "cowboy coding" (I've met as many cowboy coders in Waterfall, may it die a fiery death, as Agile projects).

Nothing about Agile says, "Don't ever test and validate this system before deploying." Anyone who believes that is, frankly, a moron.

In my experience it was less a lack of intelligence and more results-oriented thinking (they thought we were wrong so they found a way to argue it).

If you have twenty versions of a thing and multiple deployments to fix and fine tune it, that means to this person there are 20 plus examples of "mistakes" you made in building it. They were looking for evidence that the software was built with "poor quality controls" and ironically interpreted iteration as evidence of poor build quality.

Such a great point.

I think one way to go about it is to just put the Agile bits inside a Waterfall.

Which is frankly how it works anyhow.

You can characterize early sprints at 'research'.

Later the sprints are just 'sub projects'.

I think people could be convinced that 'feature refinement' is a real thing. Put it out in the field, doesn't work the way we want it, and so it needs to be refined.

I know that I would hide 'Agile' to anyone outside the team and just talk in simple, easier to understand phases.

It's also possible to put checklists in those phases, and if you say someting like '75% features' at such and such phase and assume '25% of that 75% will be reworked' it's not irrational either.

But you are right, culture matters.

This is so true. They don’t teach agile in management classes and ‘planning’ generally means years, not t-shirt sizes. I believe that also many economic theories and practices don’t regard agile practices. I’ve always felt that the business and their planning are at odds with the agile ways.

> management classes

It would seem they don’t do a very good job teaching how to think about uncertainty, risk, and unknowns, which is what agile is good at addressing. If you want a suit to lose their mind, tell them they can only pick two of feature, quality, or schedule.

Waterfall seems a lot better when you have done something before and there's nothing to discover.

> Waterfall seems a lot better when you have done something before and there's nothing to discover.

I've said this here on HN before, but the only Waterfall projects I've seen it work reliably were where:

1. The systems were small (in which case any method would work)

2. The systems were trivial (in which case any method would work)

3. The systems were well-understood by the people making them (in which case any method would work)

It does not handle large, non-trivial, or novel systems very well. Almost without fail they will deliver late, over budget, or deliver the wrong thing. This can be a win for contractors, though, who get to bid on the rework or sustainment contract for their own work.

Buulding iteratively can reduce bugs and improve quality other things being equal. The problem with how Agile methods sometimes get implemented in practice is that an excess focus on quick-and-dirty iteration to the exclusion of everything else leads to having mountains of very poor quality code, with little to no support structure around it in the form of broader design or documentation. Agile methods advocate for growing these kinds of support structures via refactoring, but this is often not done to anywhere near an adequate extent.

Agile is a tough pill to swallow for many engineers, but it's become part of the theology of software development, so everyone's afraid to object to it.