The Supple Manifesto
Here’s how to make awesome digital products in the post-Agile world
Observant readers of my blog will already know at least 12 reasons why trying to be ‘Agile’ creates more problems for Software Development than it solves. In summary:
- ‘Agile’ is a faulty metaphor. It turns changing direction quickly into an absolute virtue, a goal in its own right. This is a recipe for waste, frustration, and the exponential growth of technical debt.
- Agile is a reaction against the Waterfall methodology, as practised on 1970s and ’80s mega-projects. Nobody does Waterfall anymore. Agile is only justified by fear of a straw man, which already burnt to ashes.
- Waterfall’s flaw was delivering value too slowly: business contexts had changed before the software arrived. Agile has an equal (and opposite) defect: it emits a steady, thin drip of outputs that don’t add up to positive overall outcomes or business value.
- Managers love the various process frameworks which grew out of Agile (Scrum, SAFe, …): not because of anything like agility, but because they provide a false sense of control and predictability.
- The Agile Manifesto was about delivering monolithic, free-standing, client-server applications. Agile is counter-productive in the distributed, hybrid, cloud service ecosystems where modern software runs.
We need a better way to conceptualise and organise the process of delivering digital technology products.
My proposal below mimics ‘The Agile Manifesto’ in language and structure — as a homage more than a parody. You might like to read them in parallel. I have no expectation or desire for my ‘Manifesto’ to be wholeheartedly adopted. I do hope it will get people thinking more about why we need a paradigm shift, away from Agile.
Manifesto for Supple Systems Development
We are uncovering better ways of delivering valuable digital services, by doing it and helping others do it. In the process, we have come to value:
- Shared meaning and purpose over incessant over-communication
- Adjusting a clear plan over reactive re-engineering
- Automated testing at interfaces and boundaries over the illusion of working software
- Stable platform processes and tools to support agility where it actually matters (in interactions with the individual customer)
Twelve Principles of Supple Systems Development
Our highest priority is continuously delighting the customer. Early and monotonous delivery of small value increments is not always best.
Welcome changing requirements, within reason. Supple processes flex with change but never to breaking point. The customer’s competitive advantage is a balance of time-to-market, cost of development, and quality of outcome. Developers shouldn’t tip the scales towards long projects and extended contracts by absorbing every new idea without question.
Deliver working systems frequently. The cadence will naturally vary: get over it. Effort expended on unnecessary releases has an opportunity cost in quality and sustainability. Focus instead on keeping your software always releasable.
Business people and developers should share a product vision. Daily collaboration may be too frequent for either to do their own work well. Constant, unfiltered communication among all Management, Product, UX, Development, Test, Release, Operations, and Delivery specialists generates far more heat than light.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. [This is the only point I’ve copied straight from the Agile Manifesto. It’s an extremely facile platitude, though. It’s made impossible to achieve in Agile itself by the Manifesto’s previous point “business people and developers must work
together daily…”] Supple Development makes this goal more realistic by accepting that each specialism needs time in isolation, to translate the shared vision to its own language and practices.
Efficient communication requires appropriate use of various media. Face-to-face conversation needn’t be the default. Maximise signal-to-noise ratio, and let a representative or delegate of each team or specialism document the key outcomes of a meeting in the format most suitable for their audience.
Business outcomes are the primary measure of progress. Software is never fully ‘working’. Consider the holistic effects of a release on business, and feed this information back into the plan.
Supple processes support sustainable development better than ‘Agile’ ones. Human beings can’t maintain a constant pace indefinitely. Let big improvements take longer that small ones.
Continuous attention to technical excellence and good design reduces the need for agility. Less things will be broken, so less time will be wasted changing the plan to fix them.
Simplicity — the art of maximizing the number of interfaces not modified — is essential. Supple agrees with Agile that simple is best. In a distributed, microservice-oriented, event-driven world, the limiting factor for safe and fast delivery is change to existing services or platform components.
The best architectures, requirements, and designs emerge from clusters of self-organising teams or individuals, with the right amount of inter-communication. Small teams with high cohesion and low coupling are preferred. Cross-functionality fails when any function is purely a taker-of-instructions.
At appropriate intervals, the teams reflect on outcomes, then tune and adjust their behaviours accordingly. Rather than regular retrospectives, focused on development metrics like story point velocity or bug rate, in Supple, everyone involved in the product lifecycle reflects on the overall outcome for customers and the business, then feeds this back into how they work, per-specialism.
[My next article will envisage what a practical implementation of a Supple Development approach might look like]
