Large, conservative organisations using traditional software life cycles cannot expect Skunk Works Agile at the programmer team level to have wider impact without deliberate senior stakeholder strategic intent. The implications of Lean thinking are that to be effective, this change must come, and must encompass every aspect of company operations.
"You can be as agile as you want – you'll hit a wall if the executive level operates based on different principles." @bbogsnes #agile2014
— Olaf Lewitz (@OlafLewitz) August 1, 2014
Many large organisations, particularly in regulated industries such as banking and pharmaceuticals, have adopted something along the lines of the ‘V’ model of systems engineering.

The V Model of Systems Engineering
Image extracted from Clarus Concept of Operations. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
Conceptually simple, and offering powerful auditability and clear Separation of Duties process safeguards, this is highly attractive to corporate governance, for whom a failure can bring at best a regulatory impact, and at worst, a political and PR firestorm. And not just in banking, but in other industries too. If you supply mobile telephony base stations and they fail, you’re paying very large sums of money to the network operators in short order. And if you’re supplying hardware or software to those base station suppliers, and it’s your component that caused the failure, you can be sure that those fines are going to be passed on to you, with the addition of contingent damages and costs.
Well publicised failures in the last few years have made it very clear to managers that being found responsible for another is a career limiting move. If you thought such organisations were risk-averse before, you ain’t seen nothing yet.
In this context, Lean and Agile ways of working have been very slow to gain penetration. They have tended to come in at the development team level — right at the tip of the V — as a team-led initiative, coming from smart engineering teams thinking about how they might work better, and seeing effective models in the wider software industry.
However, the rest of the company doesn’t work to the same assumptions because it hasn’t undergone a similar transformation of mindset. So you have a little bubble of Lean/Agile culture operating in one small part of the product value stream, optimising for quality and speed. Outside that bubble are some very different assumptions, which make Lean/Agile working very difficult. These are usually under the heading of governance of one kind or another, be it risk, technical, financial, strategic or other policy based.
The bubble skin interface quickly becomes a painful place as the two cultures come into conflict. Because Agile’s culture is one of puritanism and resistance to any kind of compromise to its methods, meeting the needs of anyone from outside — especially if they’re from traditional management — is criticised, ridiculed and punished. The only possible response is to make the cell wall thicker, and work hard at not even seeing the needs of the outside world and where they differ from our definitions of what (by our definition) they should need.
Those different assumptions cause failure in many Agile adoptions.
In this model, all the real business decisions are made up front, and the delivery team are effectively told you kids can do your Agile thing as long as it doesn’t screw up too badly.
This is often called Water-Scrum-Fall, and it’s so often blamed on Management. But of course this is an oversimplification.
By keeping the walls of the bubble so impermeable and obsessing about small teams, we keep the business at bay, rather than engaging them. When we define the relationship with Management as adversarial and complaining that their unsuitability and unwillingness to how we’d like to work is to blame, we set up a self-fulfilling prophesy, further exaggerating the difference between Us and Others, and every day showing how we’re not like Those People. And that’s simply inviting attack from organisational antibodies. So we build the walls thicker. And higher.
When we build our walls thick and high, we limit our revolution to our part of the value stream, and ensure that there’s no risk of their culture invading our fragile world that we keep so pure. And we self justify our failures by complaining that the rest of the system never works in a way that helps us.
But what if we took a different approach?
What if — instead of sealing ourselves in our little diving bubble with the thick walls — we expanded those walls and grew it instead?
We know from Deming that 95% of a system’s performance is down to the system, not to the individual components and people within it. And yet, we keep focusing on the team level, not the system level.
This means of course that — while it’s important to grow and share knowledge at the operational level — we’ve been focusing our evangelism on the wrong audience. To change the system, we need to engage with the system owners. And that means executive management.
So when we talk about Scaling, it doesn’t just mean “Big Teams, Big Systems, Big Deliveries”. It means system-wide change. That skunk works rarely achieves.
Focus more on the system to make the environment supportive of our aims. Engage with executive management on their terms to make this happen.
Bootnotes
Important inspiration for this came from
- Compulsory Basic Training - May 14, 2019
- New Slides: Meaningfully Reframing PI Planning - May 14, 2019
- SAFe RTE Class Review - November 22, 2018
The Other Kind of Scaling by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Well quite.
But bubbles are easier to defend, and easier to get all righteously dogmatic about what’s allowed inside it and what’s Just Not Good Enough.
And this is true right back to the earliest human groups, right back to the earliest circle dances.
We appear to have lost an upstream comment. I suspect it was a Social Media response; using those made the whole comments section hard to use so I killed it on site rebuild in 2016.