Space Gopher posted:

There is a way to contain Agile to what it's good at. I'm bored and going to do a less cynical than normal effort post.

Basically, agile is very good at dealing with certain, hard-to-handle problems. It's absolutely terrible at others. People see that it's able to handle some tough problems, and think it's the one true framework for them, then try to implement it where it's not as good and fall flat on their faces.

To identify where it's good, and where it's not so good, we've got to drag out another framework. The one that's useful here is called "cynefin," which is a Welsh word (pronounced coo-NEV-in) that means "habitat," and also a 4-box categorization system for problems that came out of IBM in the late 90s/early 2000s. Like a lot of business frameworks, it has a few genuinely useful insights, as well as a lot of bloviating nonsense articles and books that overextend the hell out of it. But, it'll be useful for this, I promise.

Cynefin puts problems into four categories: simple, complicated, complex, and chaotic. Simple isn't necessarily easy, but it's well-understood: it's the category of problems that are already well-known, documented, handled with best practices, and so forth. The challenge with simple problems is executing the known solution effectively and efficiently. Complicated problems are new and challenging, but you can still break them down and analyze them before you get started. You might not know every detail of a complicated problem, but it's one that you can pin down, get expert advice on, and so forth - they respond really well to up-front analysis before you dive in.

Complex problems, on the other hand (and, incidentally, gently caress you, cynefin framework authors, for using close and similar-sounding synonyms for very different concepts), are ones that tend to change out from under you, and that you can't analyze up front. They tend to involve a lot of unpredictable or only semi-predictable human behavior, rather than automated systems. To handle complex problems, you have to take probing actions and run experiments, see if they work, get rid of the failed experiments, and scale up the ones that do turn out well (maybe even turning them into complicated problems, as you get a clearer handle on what works). Finally, chaotic problems are just the "somebody just do something, for the love of god" category - there's no good way to handle them besides trying to get everybody doing something, putting a lid on the chaos where you can, and eventually getting to a place where you can bring in the experts or run experiments or whatever.

Agile is purpose-built to handle the complex problem space, which is a weakness of traditional project management that wants to make big plans upfront. All the stuff about quick sprints, product reviews, regular re-planning, and so forth is intended to give you space to run those little experiments, improve on the ones that work, and not invest too much into the ones that don't. The cynefin approach here is "probe, sense, respond," and you can basically map everything you do in well-run agile methodologies to one of those verbs.

People see that agile works really well on those tough complex problems, and think it's the magic swiss army knife that'll make all their problems easy to solve. But, if you're trying to attack one of the other problem spaces, it's just a bunch of bullshit that enables experiments you don't need to run and quick changes you hopefully don't need to make. Meanwhile, up-front planing and analysis stages, that traditional project management does well, are sidelined - so you're basically crippling yourself by getting rid of very useful tools that handle complicated or "simple" problems. Incidentally, you're exactly right about SAFe. It's just a way to launder trendy-sounding agile language back into processes that work well for complicated and simple problems, at the cost of throwing out or undermining everything that makes it useful for complex ones.

Accounting is close to the archetypal example of one of those "simple" problem domains that's not necessarily easy, but well-understood. You don't need to run experiments. You don't need to make quick changes. You can get to most of the requirements in an accounting system just by studying the field, and for the ones that are left, you can analyze your needs up front before you start work. Agile is bad here because there's no use for the things that it does do well, and you're giving up plenty by not following other approaches that are better suited to the work you're actually doing.

If you're in a position to argue against an agile implementation that doesn't make sense, you could do worse than grabbing a bunch of cynefin articles from HBR or other prestige business journalism sources. It's not super trendy, but it pops up often enough that you can find recent sources. Or, worst case, just sigh and suggest SAFe.