The abuse of Cynefin

Scrum has been the tact giver for "Agile" for a long time. And Scrum is all about empiricism. And this "empiricism" has become a problem in recent years: Self-proclaimed, unqualified "coaches and trainers" proclaim that current organizational processes don't help, and hordes of incompetent "Agilists" swarm the market, only to wreak havoc on unsuspecting organizations.

Based on a mis-representation of Cynefin, people abuse Scrum and ditch available knowledge wholesale, because ... "In the Complex Domain, you don't know until you tried."

Now, is Scrum or the Cynefin framework really the cause of this problem? Not really - they are merely the door-opener for the snake oil sellers. And given Cynefin's and Scrum's easy appearance, people don't spot the trap until they fell for it. These frameworks are so popular and so easy to abuse, and it's really difficult for someone who sees them for the first time to discern what's correct and what is a mis-application.

Cynefin Framework by Dave Snowden

Now, let me describe the chain of "Cynefin Reasoning" that leads us down the wrong path:

"Knowledge Work (e.g. Development) isn't simple. It happens in the Complex domain. In the Complex domain, we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable. Complex systems are dispositional and not causal. Hence, we cannot rely on good or best practices. Instead, we need to create safe to fail experiments and not attempt to create fail safe design."

It's a flawed understanding of Cynefin, combined with a false dichotomy that becomes a toxic soup. Here's why:

1. Just because something isn't simple doesn't mean it's automatically "complex". There's the entire domain of Complicated problems that's blissfully ignored, and even "Complex" is a category of varying degrees of complexity.
2. The idea that existing knowledge is entirely inapplicable doesn't describe the "Complex" domain - that would be the "Chaotic" domain: We can predict the outcome of a software development process pretty well. What we can't predict quite so accurately are customer reception and market conditions, but even there, we have quite elaborate mechanisms.
3. A shallow "dip into chaos" doesn't mean we should engulf, immerse or drown ourselves in chaos. Whenever we can prevent chaos, we're well advised to do so.
4. A scientific approach would rely on so-called "experimental conditions" where we fix all but the one variable under examination. If we let go of all control variables, we really won't be able to predict anything any more ("Chaos"). The latter is pretty pointless, and it can be avoided in knowledge work.
5. Just because something is "complex" doesn't mean we have no reliable process and are fully reliant on empiricism. To retain control, we need to minimize the impact of uncontrolled factors. For example, we would never have a smartphone if we didn't know exactly how to build computers, exactly how to build mobile networks, exactly how to mass-produce microtechnology, and those things would be a nightmare to use if we didn't know exactly how to build software that doesn't crash. It's complex, but it relies on a lot of things we precisely understand, and operating in this domain without high degrees of knowledge would be economic suicide.

And that's where we get into the mess today often called "Agile":

People don't understand what they're doing, because it's not a requirement to get into an "Agile" role. Fake "Trainers" without development experience make it look like that's not required - because, "hey, we got Empiricism". We encounter so-called "Agile Coaches" who don't know the building blocks of a functional company, we have to put up with 2-day "Scrum Masters" who don't know how to build a team, and see misplaced "Product Owners" who don't know what makes a product successful. And that's just scraping the surface.

Does this sound familiar?
"We don't need market research, probabilistic forecasting or demand control: Let's just write a User Story and put it into the backlog!" - "There's an entire science around Demand Management" - "Who needs that? Let's just incrementally Inspect and Adapt!"
Product Management, Quality Management, Process Management, Delivery Management, Operations Management, People Management, Finance Management, Sales Management ... we know a lot about these things! In the "Agile" community, however, there's a growing number of people who meet these with resentment, ideology and opinion: "managers are worthless anyways, so let's shoot all of that to the moon and apply empiricism!" 

The knowledge is discarded wholesale under the pretext of Cynefin - complexity and empiricism become the arguments against existing knowledge. "Inspect and Adapt" trumps science. Hence, "Agile" gets a free pass for obliterating functioning organizations: people with zero understanding of a domain "coach" long-term experts who have academically studied a subject, read the books, and gotten their share of field experience - and some even have the galls to claim that "coaching in the absence of knowledge works better, because it allows the coach to be unbiased!"

Thus, we set the playing field for quacks who will dismiss all scientific achievements and progress we have made in software engineering, bringing on the mumbojumbo, kumbayah, post-its and canned bikablo doodles: those professionals who did put in the hard work become indiscernable from quacks, organizations and individuals decline, order descends into chaos.

"Agile" has become a habitat for the same kind of science denialism as Anti-Vaxxers or Flat-Earthers: Except it's more subtle to spot, because the bodies of knowledge these people despise are the invisible fields in knowledge work. And Cynefin has been their door-opener.

Let me conclude with a question: "How will you approach complexity?"