There are two distinct benefits of Agility. Assuming either is universal and exclusive causes unnecessary conflict: Agilists need to appreciate and value the diversity and find context-specific balance.

We are uncovering better ways of developing software says the manifesto, while fudging the question about what ‘better’ means. Exactly what you’d expect in a superficial peace treaty. But by ducking the major source of conflict and focusing on the easy stuff, it pretty much guarantees further conflict.

Since its very inception, the Agile community has been riven by conflict. The very manifesto event was essentially a peace treaty between different groups and individuals who had some very different ideas about what they were writing. Like most intractable conflicts, these are not driven by conflicting answers to a question, but different views of what the question is.

In Cynefin terms, we are in Disorder, and the clearest conflict is between two Cynefin domains, each of which addresses a different business question. It’s no surprise that the conflict is illustrated through the first two Agile Principles.

Early and continuous delivery of valuable software

This school of thinking emphasises minimising Cost of Delay, and says that if you start delivering value earlier, and incrementally, you will deliver a lot more total value than if you wait until it’s all delivered.


Typical value acceleration curve, based on delivering highest value first.

You can find this all over flow-based approaches, in Theory of Constraints, DevOps and Kanban. Move the value through the system faster. Smaller batches, moved more frequently. Deploy often, minimising the time from developer desktop to production.

Often in this school, we work to identify reducible uncertainty and variation. Elephant Carpaccio is a really useful pattern, as is the INVEST model of user stories.

In this thinking, the project model is supported because it is possible to understand the majority of scope boundary at the start, and plan to deliver value incrementally towards it. However, if you’re in a product development environment, you will probably be thinking about reducing Lead Time from business idea to realisation, and therefore will be constraining a pipeline of ideas with Little’s Law.

Managing this, we’re applying expert principles and acknowledging that there may indeed be One Right Way (or configuration of ways) to achieve this undertaking. This is essentially Cynefin Complicated. And it’s very attractive, because it’s economically efficient, and definable in processes and guides without having to constantly re-evaluate.

Harnessing change for the customer’s competitive advantage

In this environment, change is constant and situations emergently unpredictable. Fast feedback loops, where hypothesis meets reality frequently and direction adjusted are essential to avoid drifting dangerously far from reality. Indeed, the very concept of hypothesis (and therefore experimental methodology) can be thought of as flawed, as it implies the existence of a consistent ‘theory of’ model that simplifies the problem space.

This is the world of Lean Startup, of ‘move fast and break things’, of If you are not embarrassed by the first version of your product, you’ve launched too late. first mover advantage, of stochastic planning and outright rejection of all the control mechanisms of the Complicated Domain.

If you are not embarrassed by the first version of your product, you’ve launched too late.  - Reid Hoffman

If this sounds to you like the Wild West of Complexity (and even Chaos), you’re right, it is. Where radical environmental change can be initiated by a few words in the right place (think: government announcements).

Working in this environment is incredibly exciting: it’s an exhilarating fairground ride, with all the passion of a new romance. It’s no surprise that you get serial entrepreneurs, addicted to the gambler’s rush of uncertainty and the lovers’ new romance. It’s really useful economically to those working in it too – it requires hands on levels of high skills throughout, and is incredibly difficult to reduce to a level where lower skills can cope. This kind of protectionism has been exercised for centuries by craft workers: bespoke is best, there are no good (let alone best) practises, and where rhetoric fails, consider the etymology of the word ‘sabotage’.

It’s a Spectrum

Of course, no organisation is strictly one or the other. Nearly all organisations are balancing between the two, organisationally, from delivery to delivery and even within deliveries. But different organisations in different contexts will definitely have a pull one way or the other. And if you spend your life in either, it’s easy to be biased towards thinking that everyone is like that.

Given that our community is overrepresented in people with loud voices, poor social skills (empathy in particular) and an over-developed sense of their own intelligence, often conversing over a medium that values brevity over nuance, is it any surprise that our bias leads to frequent conflict?

Why are we even trying?

A good question. If our perspective is so markedly different, or even is from multiple points along the balance beam between the two domains, why do we stick together?

Because many of the Agile ways of working, particularly the emphasis on speed and the methods used to achieve speed with quality, are helpful to both. So we pretend we’re in the same place, and just have arguments along the way.

What’s the Answer?

My prescription? A healthy, regular dose of Go and See.

Bootnote: Cynefin Catchup

Cynefin Brief Summary

The Cynefin model consists of four quadrants of “Simple”, “Complicated”, “Complex”, and “Chaotic” and a fifth quadrant “Unordered” for when you do not know which of the other quadrants you are in.

A “Simple” system is over constrained and has cause/effect behaviour.

“Complicated” is the realm of the expert.

“Chaos” means there are not enough constraints.

“Complex” means there are just enough constraints to create an emergent behaviour which can be nudged and tweaked into a system with desirable behviour.

“Complicated” means an expert can reduce the problem to component parts with predictable behaviour.

“Complex” means there are feedback loops, agents and limits that create an emergent behaviour that cannot necessarily be predicted.

Essentially, the difference between the two can can be distilled to “A complex system interacts with its context and evolves as a result, and a complicated system does not interact with its context or evolve.”

Chris Matts
Follow me
Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 The Two Agiles by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: