A couple of days back, I tweeted about SAFe.
It created some stir on the timeline, which was great, as I got to see a lot of perspectives. I want to use that tweet as an excuse to talk about something much larger. This will be a long one. 🙂
Meanwhile, I remind you, geekery’s not as important right now as some other things.
Please, stay safe, stay strong, stay angry, stay kind. Black Lives Matter. We are the only thing that can change this.
This muse is not really about SAFe for the most part, but about all of what the "methodology turn" in our trade produces. I do have one specific thing to say about SAFe, tho, so let’s do that first and get it out of the way.
Every SAFe installation I’ve seen, and it has been quite a few of them, and I use the word "installation" advisedly, is deeply committed to a hierarchical command-and-control approach to optimizing software development.
This is more true of SAFe-in-practice than any of its competitors. Hierarchical command-and-control is in fact deeply embedded in what SAFe’s purchasers understand "scaling" to mean. They install it for exactly for that purpose, exactly from their commitment to that idea.
And my objection to SAFe is straightforward: you will not get optimum software development by emphasizing hierarchical command and control.
You will not get the thing that you came to agility for in the first place.
Now let’s change the subject. Or. Let’s broaden the subject:
What current method would I use?
None of them.
Let’s talk about why there are no extant software development methods that reliably lead to optimal software development.
(Because I am a natural-born pedant, I do not use the word "methodology" or its cognates to refer to what are in fact just plain ol’ methods. Methodology is the study of methods. Methods are things like SAFe, Scrum, DAD, Prince2, XP.)
There are reasons why our current methods don’t lead to optimal performance, hence why I am not an advocate for any of them, not even my beloved XP. I want to note just five of those reasons, though there are many more than five.
Is there an alternative approach to method possible? Yes. But it’s not going to fit in today’s thread. These reasons take up a lot of space, and they’re negative in tone. If you only want the positive, you should wait for another thread. 🙂
Here are the big five:
First, these methods rely on what I call the Anna Karenina assumption:
Tolstoy wrote, "All happy families are alike; each unhappy family is unhappy in its own way."
This idea morphs, in these methods, into "All high-performing software teams are alike." The notion is baked in quite deeply in most of them, tho they always throw in a pro forma inspect’n’adapt clause, they never really quite tell you how that might work in practice.
Some of these methods, the ones intended to operate on more than one team at a time, explicitly require standardized procedures inside teams, standardization that has almost zero demonstrated merit.
Examples: 1) All of our sprints start and end on the same day. 2) Each team’s idea of a story point* is the same as every other team’s. 3) We fill out five document templates for every commit. And so on.
[*] Story points have long been deprecated by their originators.
Are all happy teams alike? The answer might even be yes, though it’s far from obvious. What is obvious is that they are not all alike at the level of analysis being used. Neither, for that matter, are all unhappy teams all different at that level of analysis.
Bringing us to the second reason these methods don’t reliably lead where we want:
They focus their attention and their reasoning almost entirely around "process": structure, artifacts, rules, forms, procedures.
If one says anything bad about one’s experience of any of these methods, someone will pipe up that, of course it doesn’t work if your leaders aren’t good, or your geeks suck at programming, or your customers are idiots, or any other flavor of "your relationships are broken."
Ahhhh, yes. We observe that the method would work if our relationships weren’t broken. If we were otherwise healthy, stable, motivated, safe, close, trusting, and so on. But these methods don’t actually attend — for the most part — to achieving any of those things.
Here’s the thing, tho. If your relationships were those things, you wouldn’t need much method. And if your relationships aren’t, structures, artifacts, rules, procedures, all of these things are usually neutral or even net-negative in impact on those relationships.
A favorite quote of mine: "You can’t organize your way into community." Yet, to the extent that I, personally, have seen the ways in which all high-performing teams are alike, they boil down almost entirely to "they are all communities".
These methods don’t take that seriously.
Third, these methods nearly always bundle the demands of customers, stockholders, and stakeholders, into a single abstract unity, but not only are those three separate categories with different goals, but each of the three contains within it multiple competing voices.
In this age of surveillance capitalism, for instance, a customer’s interests and a company’s interest are often in sharp conflict. Corporate value statements notwithstanding, the resolution of these conflicts is not for the weak of heart or mind.
And for all that, the stakeholders in an org, neither stockholders nor customers, typically carry more weight than the other two forces combined, and balancing their demands is often even more difficult.
And we still haven’t mentioned the geek at the face of the silicon mine.
The extraordinary difficulty of balancing these tensions is exactly why so few methods even mention them. To give the punchline w/o reciting the ancient joke, "Because the light’s better over here."
Fourth, tho each of these methods describes a City on the Hill, none of them sketch a sufficiently detailed and option-laden path for how we are going to get there.
They are marketed, sold, bought, and installed as big-bang switchovers.
We send a team to a class. We write up some workflow documents. We declare some rules. We hire some psuedo-boss installers. We change every word, every channel, every step of the flow. And we turn it all on. It is difficult to imagine an approach less likely to work than this.
The consequences of this in terms of organizational change are brutal beyond belief, and they’re made even moreso when you consider that the other items on this list strongly suggest that the method won’t work anyway.
A year or two later, when we realize what a mess we’ve made? Well. The HBR and the airline magazine covers and the websites and the buzz will have gone bounding through the weeds after another method hare, and we’ll do it all over again.
Fifth, and perhaps most dauntingly, one can succeed, impressively so, at the method-selling business, regardless of the success or failure of one’s customers.
There are long-term consequences to selling ineffective methods, but really no short-term and few medium-term ones.
You might think we could handle this by tracking success or failure data for method-buyers. If only we knew what was working! But we don’t, and, realistically, we can’t. That would require data from the method-adopters themselves.
But if a method-adopter is winning, they regard their method as competitive advantage. And if they’re losing, there is zero incentive to say so. So the data winds up being surveys to elicit the most popular method, not the most frequently successful.
And of course, the discourse around these methods is not remotely disinterested or grounded or analytical. The part that’s not popularity surveys is just acornyms and marketing brochures by any other name.
So, there’s five reasons I don’t advocate any method. There are others, too, but this thread is already long. If I get enough action out of this, maybe I’ll write it up more thoroughly.
No current "Agile" method can create high-performing software development teams.
I don’t endorse any of them. I don’t sell them. I don’t coach them. I actively advocate against adopting them.
I said I wasn’t ready yet to propose a positive view, and I’m not. But.
I can tell you what things I will demand of any future method before I even consider embracing it.
- It must focus explicitly on the development of what I have called community — active, dynamic, mutually beneficial, and healthy relationships between human beings.
- It must describe multi-option multi-variant multi-step paths from a number of "heres" to the "there" it proposes.
- It must address causation as multi-source, multi-effect, multi-directional and multi-layer, rather than the naive mechanical models with their single causes always arising in single directions from a single "above".
I won’t accept less than that, and I will most likely want more, much more. I would hope that the whole trade would join me in this.
So, yeah. I was pickin’ on SAFe, for sure. But I was really aiming at the whole failed enterprise of inventing "software development methods", branding them, marketing them, selling them, and buying them.
We need to lose this practice.
Thanks for reading along. In all fairness, I did warn you this was a long one. 🙂
Get Involved!
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.