Think back to the project management triangle that was probably drawn up in the 1960s. Between scope, time and quality, you can only constrain 2 out of 3. Waterfall constrains scope and time at the expense of quality. Agile constrains quality and time and leaves scope flexible. That is an incredibly tough pill for most businesses to swallow, but it's absolutely in their own best interests. Agile manifesto lauds "working code" and if you build debt, you're probably not producing working code. Quality-first requires flexible scope. If business accepts flexible scope, then agile is miraculous.

These processes are not for developers, they're for business. To give them visibility and skin in the game.

Nowadays I always refer to agile as mini-waterfall, because that is how it gets actually done in most companies, with the same kind of SLAs.

First of all, very interesting piece. Excellent writing – that's really great to see! I think you touched on a lot of really good points.

I've got some feedback about your section on agile. I think it does a good job of summarizing ineffective agile adoptions. But there are a lot of teams that get extremely good results with agile, and I'm not sure your piece does them justice. I've spent the better part of the last decade – and my last two books – helping teams get from ineffective to effective, and I've seen agile work really, really well on a lot of teams.

I do think this is a very accurate picture of agile on a lot of teams, possibly the majority of them:

> The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.

But if you ask someone on an effective agile team, they'll generally have no trouble describing exactly what they do.

One problem that plagues ineffective agile teams is agile zealotry, and I think it's really good that you called it out:

> It’s no coincidence that the Agile paradigm has such a quasi-religious hold over a workforce that is immensely fluid and mobile.

This is a real problem with a lot of newly minted agile evangelists. They're excited that they found a new way of working that goes a long way to help with their headaches, and feel like they've found the silver bullet for every team's problems, but take it too far and demand that everyone around them immediately change to the way they think the project should run. Honestly, I've been there myself. We grow out of it, so be patient with us! :)

So while these what you wrote describes the state of agile on a lot of teams, it's not an accurate picture of agile when it's working well. I think Jenny Greene and I did a reasonably coherent job of giving a big-picture view of agile in the first chapter of Learning Agile – if anyone's curious, you can read that chapter for free on Safari: https://www.safaribooksonline.com/library/view/learning-agil...

A few more things.

I don't think it's fair to use an image of Scaled Agile Framework, or SAFe, (https://en.wikipedia.org/wiki/Scaled_agile_framework) as an example of overly complex, "un-agile" agile. For those who don't know, SAFe is a framework for scaling agile to work with multiple teams across an enterprise. Like all tools, it can be used effectively or ineffectively. It has a lot of moving parts because it needs to work with enterprise PMOs, but it's actually built on sound and simple principles. And it really does work when everyone brings the right mindset. And on a team that's working at a company that uses SAFe and working on an effective agile team, day-to-day life definitely does not look like that picture. It looks a lot more simple, like life on any other effective agile team.

In Learning Agile we caution agile coaches that a common warning sign that people on their team are having trouble when they think that agile is the same thing that they've always done, just with a few minor name changes. Here's what we write on page 376:

> “This is exactly like what we’re already doing, just with a different name.” > This is one of the most common reasons that people reject agile methodologies. They’ll find ways to keep doing what they’re doing today, and just choose new names for them that match agile practices they’ve read or heard about. This can make all of agile seem trivial—and even wrong, if they’ve decided to give the agile name to a practice that failed for them. In fact, if you do a web search for a term like “agile sucks” you’ll find people who have done exactly this, denouncing agile as “hype” without substance because it’s just another name for old waterfall practices. They’ll even call agile an “obfuscation” of simple, commonsense software development. As a coach, you need to recognize that this isn’t done with malice or ill intent; it’s just a natural reaction from someone who’s never actually seen agile (but thinks he has). Your job, as a coach, is to help your team understand that agile really is different from what they’re doing, and that it doesn’t suck.

I wanted to call this out, because I suspect some of the people you asked about agile have fallen into this trap, since you mention that your view of agile mainly comes from talking other people:

> When I quizzed people who claimed to know about it their explanations almost invariably lost coherence quickly. The few that really had read up on it seemed incapable of actually dealing with the very real pressures we faced when delivering software to non-sprint-friendly customers, timescales, and blockers. So we carried on delivering software with our specs, and some sprinkling of agile terminology. Meetings were called ‘scrums’ now, but otherwise it felt very similar to what went on before.

This is a good description of an extremely common failure mode for agile adoption. In Learning Agile we give it a name: "better-than-not-doing-it results" – "we followed the rules of an agile approach like Scrum, and a few things got better, so we're a little better off than we were before and it was worth doing it... I guess?" The team went through the motions, but things don't really seem all that different. It sounds like the people you quizzed have this experience.

So:

> So I’m cool with it. Lean, Agile, Waterfall, whatever, the fact is we need some kind of common ideology to co-operate in large numbers.

This is correct! Absolutely!

It's worth pointing out that the agile world has done decades of work on this problem. When people on really effective agile teams see things like the Agile Manifesto (http://www.agilemanifesto.org), they see guiding principles – "common ideology" is a good way to put that – that tie together different agile approaches to getting people to work more effectively on teams.

When people on less effective, "better-than-not doing it results" agile teams see the same thing, they think, "That's a bunch of touchy-feely BS. Just start programming, motherfer." Then they run into the same problems that teams always run into, and end up thinking that agile doesn't work, and it's just another name for the same thing everyone always does.

One more thing:

> I started hearing the word ‘Agile’ about 2003. Again, I don’t think I properly read up on it… ever, actually. *

If you'd like to read up on it, I'd be happy to have folks at O'Reilly send you copies of Learning Agile and Head First Agile. I'd be really interested to know if they address some of the issues you wrote about. If you'd like that, use our contact page (https://www.stellman-greene.com/contact-us/) to get in touch.