What the (Lean-)Agile scaling frameworks don’t give you

[Minor edits 2020-12-11 and again 2021-01-08 with an updated title. It is now aligned to the final version of the manuscript that went to the publisher this week] 

Not a gratuitous provocation but putting it out there for review. The text below comes from the final chapter of the forthcoming 2nd edition of Agendashift; it’s a quick first draft (written today) and I want feedback! The chapter is new to the 2nd edition; it is titled Up and down the Deliberately Adaptive Organisation and the excerpt below comes at the end of a section called Scaling up.

For context, we have by this point reconciled Agendashift with a powerful diagnostic tool, the Viable System Model (VSM). Stafford Beer’s classic model has lessons for all organisations that have the desire to “meet the demands of surviving in the changing environment”.

What the (Lean-)Agile scaling frameworks don’t give you

I can’t help noting that not everything identified in this reconciliation exercise is addressed well by the scaling frameworks. If you’re looking to one of those as the basis of your Deliberately Adaptive Organisation or (somewhat equivalently) as a model of business agility, here are five things that you may need to attend to yourself:

1. Meaningful experimentation

A worthwhile proportion – perhaps even the majority – of your delivery capacity will need to be devoted to objective-aligned insight generation. There is nothing adaptive about ploughing through backlogs of requirements and hoping for a good outcome. Random experimentation isn’t adaptive either; whilst it flexes some important muscles and can be a useful source of innovation, unless the bulk of it is meaningfully aligned to shared objectives (and driven from them in a way that creates meaning for the people doing the work), it’s unlikely to take you very far.

2. Meaningful negotiation between levels based on trust and transparency

If you’re not careful, cascading hierarchies of objectives end up as backlogs of requirements to be ploughed through, and we know where that leads. Dressing up that hierarchy in Agile terms – saga, epic, feature, story, etc – doesn’t change that.

Remember that what’s asked for, what’s needed, what’s possible, and what’s sensible are four different things. Moreover, each level will have its own language, its own way of looking at things, and its own measures of success, and it’s not helpful when one level projects (or worse, imposes) theirs onto another. Instead: trust-building transparency, then mutual understanding, then alignment.

3. Containers for multi-level, multi-loop organisational learning

I’m referring of course to your framework’s equivalent of the Outside-in Service Delivery Review (OI-SDR) and VSM system 4 more generally. How does your framework help you build and evolve shared models of the system and the world outside? How strong are the expectations of learning that it creates? How does it challenge? How does it help you monitor progress towards objectives? How does it challenge? How does it ensure that intelligence and insights are shared quickly across the organisation?

4. Meaningful participation in strategy

Let me say it again: It’s a funny kind of autonomy when strategy is something that happens to you. Now let me add that it’s a funny kind of adaptive strategy if it doesn’t know how to listen. What we have here are two organisational antipatterns that Agile frameworks – scaled or otherwise – has done little to address. Perhaps it’s unreasonable to expect that they would, but when they’re sold as transformative models of organisation I believe that some scepticism is entirely appropriate.

5. Meaningful self-organisation at every scale

Not just who does what (better described as self-management), but self-organisation as the interplay between structure and spontaneity – who collaborates with whom, at whatever scale, and with what potential. How does your framework both encourage that to happen and ensure that when it happens it is done well?

How well does your scaled (Lean-)Agile implementation demonstrate those five things? The most likely answers are “not very” or “not at all”. If you’re thinking of embarking on a framework-based scaling initiative, I would suggest that it may pay to attend to these issues first. You’ll then be in a much better position both to understand what the frameworks still have to offer and to make whatever further changes now seem necessary.

To be clear, I’m not anti-framework. To understand how a scaling framework really works is to appreciate how its patterns have been integrated, and there’s definitely value in that. But anyone thinking that it’s cool to roll out a large framework waterfall-style is living in the 1990s! Expert-driven ‘tailoring’ doesn’t fundamentally change that. Much better to use your expertise to help people experiment with combining patterns from the full range of sources at their disposal.

Related:


Upcoming workshops

All the usual discounts apply: repeat visits (not uncommon), partners, gov, edu, non-profit, country, un- or under-employment, bulk orders. If you think that one might apply to you, do please ask.

And if you’re thinking of becoming an Agendashift partner, it pays to sign up to that first (in fact it might even pay for itself).


Agendashift™, the wholehearted engagement model
Links: Home |
About | Our mission: Wholehearted | Become an Agendashift partner | Assessments | Books | Resources | Media | Events | Contact | MikeSubscribe
Workshops: Transformation strategy | Outside-in strategy | Short training
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s