Agile software development is a tough pill to swallow for non-engineers. The lawyers and business people can't wrap their head around the idea that building iteratively could actually reduce bugs and improve quality - because the way they work is via process planning docs and checklists.

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

Or did you mean some quality in particular?

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

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

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

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.

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.

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.

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.

But there was lots of boring bullshit in there too ;)

My (outside) impression has changed the more I've heard over the years, to the point that I assume the DoD and military are acutely aware that the drones aren't really interchangeable, and that at every level they cultivate people under them they know "get shit done" and hand the important projects to them. Those people in turn have those under them that "get shit done" they hand the important things to, and so on, all the way down to privates in the military. The important thing being that those people that get shit done are given a lot more leeway in how they accomplish things (which might later become doctrine of successful), and this is specifically how those orgs evolve over time.

Again, that's my outside perspective from someone that's interested whenever I hear it and reads/listens to history sources (podcasts,etc).

Within military troops, yes. That's an active goal, especially on the officer side where the whole career path is pointed towards increasing levels of responsibility and leadership. The problem is not in the troops, but in the program offices.

I was on a spectacularly failed Waterfall (big-W, they were explicit about what they were doing) where they handed the task of managing a large, multi-billion dollar software system (from the DOD side) to a 1st Lt history major. She had no preparation for the role. Software acquisition in DOD is, mostly, a clusterfuck. I felt bad for her because she legitimately did not know anything more than the basic legal and financial side of things, she had no technical comprehension and had to trust people (contractors) who were lying about the system status and quality (what was delivered, after she had moved on, was years late and had a fraction of the target capabilities).

Program offices are not generally composed of people who have real-world experience with software development. Remarkably they have great engineers, good finance people, but the software person (often singular, even in programs that are almost exclusively composed of software systems) is usually not from a software background or a straight out of college EE major (more often than not, occasionally a CS major).

Ugh, I can see that being a problem. I remember my practical experience in projects after graduating with a CS degree, and it was close to non-existent (a class in development methodologies without experiencing it yourself is just a survey of all the things you can do badly if you were to be in charge).

What they mean by that is that the person who invented the phrase "waterfall method" did it specifically to tell the world about something that did not work. In fact, even going back to the NATO software engineering conferences of the 1960s, they were discussing how development needs to be agile.

But sure enough, few big organisations got that memo.

However, where I am, there is a huge emphasis on "getting shit done" well ahead of schedule. I'm lucky to work with smart and motivated folks who together, work well and we are wildly successful.

My biggest gripe, shared among many of my coworkers, is the level of micromanagement. Multiple business analysts, product owners, stakeholders, SCRUM masters, managers, etc. who all share essentially the same job - delegating and scheduling work. It makes every project 10x more difficult and complex than it otherwise should be.

An example just from this past week: Project A: we are delivering a single product. Three managers, two SCRUM masters, multiple business analysts. We engineers have four different JIRA/task-boards to keep up with. All of them overlap, three of them are essentially the same board in different spaces. Each day we have 2-4 hours worth of meetings spread across stakeholders amongst those three boards where we regurgitate the exact same information.

It's repetitive, backward, and a time-waste. Some engineers are currently "revolting" by saying what I'm saying now - in the meetings themselves. We've had multiple blowups with management.

Having meetings and discussions spread so wide leads to a lot of confusion because us engineers appear to be the only conduit with which the analysts and managers are communicating. Often times, the different stakeholders will ask for the same features in different meetings, other times they ask for different or conflicting features which leads to confusion and the need to schedule more meetings to clarify as they are not communicating amongst each other.

For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing.

Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design.

Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed.

Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes.

In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit.

Our little bubble is agile in a waterfall world.

Imagine you have a group of illiterate managers who have just hired a group of writers to write some company policy documents.

You could have the managers (carve / draw / modern dance) their requirements in a waterfall manner.

Of course you could get one of the managers to sit down with the developers and tell them how the policy's work each day, embed with them Agile style.

However in the end you can't be everywhere, sometimes there aren't enough people in the company who understand what is needed, or even be sure that the embedded people agree on what is needed.

These are business problems - but they are also literacy problems. We have a literate society and so there are enough literate people to write policy documents to cover a whole compmay.

We need to make enough people who can code, so they can write the policy documents of the future.

The only thing I'm not convinced about is whether programming is something of a functional specialisation or if it will (GAS already?) become a literacy-like thing.

I mean, we generally think of numeracy as something widespread in the West for the past few decades, but the average person really does not do even basic arithmetic very well. Are we really going to do a better job of teaching people programming, or will we have to resign to the reality that most people won't learn it well?

The bit that's gets me is how fast does earth spin (without which sun rise is a bit hard to explain). Until it was accepted that air was just a thin atmospheric layer, it becomes insane to imagine we spin at a 1,000 miles an hour though a air medium that extends to Jupiter. How do you keep your newspaper still.

Kids today have Mickey Mouse cartoons explaining space rockets, moon to mars, earth spinning etc. We just accept it as true without trying to be clever about it

The same is true for literacy and numeracy - just having a society where you absorb character arcs, sub clauses, chapters, publishing, versions etc makes so much difference. Mathematical symbols were the names of Ed Sheeran albums.

Look at something simple like git - most business users should have this all the time but it's not a world view

(#) Look for episode on the podcast "Subject to chnage"

Fully 25 years after computers-in-business, especially for any significant size of business, was virtually universal.

Humans don't manage businesses anymore. They are essentially all software managed. Business management is now really meta-management of business management software.

>>> Business management is now really meta-management of business management software.

It really ought to look like :

for each emp in employees_by_dept('accounts'): emp.getvacationplaennedthismonth

or something

https://youtu.be/nvfYLZ52zX0

That would be news to most tech companies, these days, that seem to be obsessed with hiring huge armies of inexperienced engineers, relying on the process to make them magically deliver code like they were masters.

I worked for a couple of major corporations, and got lots of waterfall. A the Japanese company, I quickly learned never to utter the dark majik phrase "A G I L E," as it conjured demons from managers.

Also, looking at that PDF, I realize that it is a slide deck.

That presentation must have been a soporific.

Also, you can edit your comments which is better than tacking on additional self-replies just a minute or two after.