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 softwaresays 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.
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.
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 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.