Thread by @RonJeffries

Today I'm thinking about precision. In a sense I might be against it. Stick with me. The eminent @ivarjacobson is promoting Essence, which is a candidate approach to precisely defining methods and practices (and more) for software development. /1

My initial reaction to this was that it's a great idea, and frankly I still think it is. The ability to say more clearly what a method is and is not has many potential advantages. Clarity is of course one. Increased ease in creating a team's own method is another. /2

A team /always/ has its own method, and organizations that try to impose their "standard" method on all teams are making a serious mistake. This happens all too often. /3

So, one imagines, if we could make it more clear that your local method is composed of some practices from, say, Scrum, but with al these additional practices that make up the real meat of what you do and how you do it, that could be a great thing. /4

It seems at first that a precise way of saying what is, say, SAFe, and what is not, could be quite valuable and powerful in helping organizations improve how they build software. It seems. And I hope that's the case. However ... /5

I have two concerns, one philosophical and one political.

Philosophically, human behavior cannot be defined by precise rules. One way of looking at this is via Cynefin, the work of @snowded. The search for a precisely defined method of making software is doomed to failure. /6

You can follow your precise method as carefully as you wish and you're still not guaranteed success. Arguably, the closer you follow your method -- beyond some limit -- the more likely you are to fail. Now precise understanding can be good, but it's fraught. /7

So in this sense, the search for precision is a search for a unicorn, and not just any old imaginary unicorn, but one that if you do find it, it'll stab you in the heart with its horn. I like the idea of precision, but it's inherently limited. /8

Politically, there's a worse concern. Even though none of us here would ever imagine that precision would be over-used, and all of us here are ever-alert for the signs that we need to be more adaptive, there are strong forces pushing the other way. /9

Companies, especially larger ones, are prone to pick up on the latest thing, "Agile" in the present case, and to impose them on the organization so as to bring about "improvement". Inevitably, it seems, they impose the wrong thing, poorly. /10

They don't really understand "Agile", and parts of it are uncomfortable, so they modify those, without understanding, and then they rename some job titles and jam their custom-made "BigCo Agile" down the throats of the people doing the work. /11

You'd have hoped that they'd understand the Method and the Practices, and assemble a really good "BigCo Agile", but in practice they do not. The precision offered by this good idea is grandly misused in practice, all too often. /12

Now, I've been saying, regarding problems people have with "Agile", for decades now: "You're doing it wrong." And if BigCo uses, say, Essence as I've just described, well, they're doing it wrong. But they are, and they will. Precision isn't bad but BigCo Precision is bad. /13

But wait, there's more. What about the enterprises selling "Agile" methods, like SAFe or Scrum or DAD or the others? They now have a PRECISE WAY of saying exactly what their method is. This lets them distinguish their product from the competition ever more clearly. /14

This brings focus onto the wrong question: "Should we use SAFe, or should we use DAD (or Scrum or LeSS or ...".

What we're supposed to ask is "What assembly of all these Practices should make up our BigCo Team 51 Method?" But the Agile Industrial Complex doesn't want that. /15

They want to market you their canned method and using the precise definitions available, they'll be able to more and more clearly say, no, see use XYZ because it has Practice 131 and ABC clearly doesn't. /16

Precision should be a good thing. But I'm not at all sure it is, because it is likely to empower Agile-pushing companies to better confuse people into believing that their method is better than the other method and that all you have to so is adopt XYZ and it'll all be fine. /17

When we combine the desire of big companies to adopt a rubber stamp method, with the ability of rubber stamp companies to be more precise and differentiate themselves better, we may well find ourselves with more faux-Agile, more Dark Agile, instead of less. /18

I'd like to think this isn't inevitable. I'd like to think that more precision would be better. But both philosophical and politically ... I suspect that greater precision is not what we need. Greater understanding doesn't come from greater precision.
/end (sorry for this storm)