Oh dear, a “vs” in the title on a subject where perhaps some nuance is called for. My apologies – naming is hard – but then again, on this topic I do take a strong and (I suspect) non-mainstream position.

Last week I put this question to LinkedIn:

At scale [across multiple organisational units], do you:
1) maintain neat hierarchical work breakdown structures (saga, epic, feature, story, task, perhaps)
Or 2) allow each level and each unit within – down to team if not individual level – to express their respective strategies in their own language as they are fit?

To be clear, the intention behind this question is not about terminology (not method-level terminology at least)

Quite a range of answers, many of them describing organisations that were much closer to one extreme than the other, with aspirations to reverse the situation. The really funny thing: this went in both directions. People working with neat hierarchies aspiring to greater self-organisation, and people at that end aspiring to consistency and to what they saw as a source of alignment.

So where am I on this? Pieter Mulder’s comment represents my thoughts pretty well:

My opinion is very much that point 1 will only let you scale so far and it must take a heck of a lot of effort to maintain that as you continue to scale and it comes with risk when teams or individuals don’t conform and the whole system breaks down – also, who decides the structures and how do you change them when they don’t work? Point 2 can scale infinitely as the decision-making and accountability sits much lower down so it is much easier to optimise the system (smaller experiments, smaller tweaks, smaller risk to the whole).

Teams are living organisms which are never the same. What works for one team doesn’t always work for another (even if they are seemingly identical).

I am completely biased as I have never seen 1 work well (and have seen it fail or frustrate too many times) and I have seen 2 work really well.

Late 90’s, before Agile was even a thing, two investment bank projects sealed it for me.

The first of these projects impacted borrowers and lenders of fixed income securities in the UK (Gilts most especially) and was sponsored by the Bank of England. I was hired as a contract developer into the relevant front office team and was surprised (in a very good way) about how things were organised. Quickly I found myself taking the lead in agreeing interchange protocols with middle and back office systems and we all got on with our work. For the purpose of this project, each system had its champions in various parts of the business, and between us all we worked out how testing would be conducted, both separately and integrated. Project managers meanwhile stayed mainly out of our way, looking after the BoE relationship. On launch night we converted literally billions of pounds worth of stock between old and new trade models, and one minor hiccup aside (fixed in minutes), we were live. My first experience of a “front-to-back” project was a very positive one.

Since many of my front office colleagues preferred more trading-focussed projects it wasn’t surprising that I found myself as the front office tech lead for another front-to-back project, completely rewriting a mission critical system in the year leading up to the launch of the Euro. What would have been a high profile project at any time became a truly high stakes project. And the really great thing: we followed much the same model but with two enhancements:

1. Even greater business involvement, to the extent that across all impacted systems (of which there were several), people co-opted from “line” jobs to work as subject matter experts and testers easily outnumbered the developers
2. An early focus on testing (one of my first bits of development helped to make testing a largely self-service activity, a few hours coding that paid for itself countless times over), supporting a highly engaged and iterative process

In early autumn we went into parallel running, started migrating trading books a few at a time and then in larger numbers until we were fully live. Not only were we ready in good time for the Euro conversion, we were earlier than anyone’s best predictions!

20-25 years have passed since those projects and despite all I’ve experienced since, there’s very little that I would change about them. And if self-organisation can work on projects of such scale and significance, why is it not more the norm? Or perhaps it is, but we don’t like to own up to something that looks messy, and surely those nice, neat hierarchies are what counts for “doing it properly” these days?

In more recent years my opinions have only hardened. I know that context is everything, but show me a beautifully-groomed backlog and two worries spring immediately to my mind:

• When the work gets to the front of the queue, will it still be relevant?
• How much does it cost to incorporate everything that’s been learned meanwhile?

To make that learning process work at scale and speed, you’ve got to be truly exceptional. For the unexceptional – and I’m referencing Right to Left here – the big risk is that you end up ploughing through backlogs of requirements, a mediocre experience leading to mediocre results, hardly Agile at all (if that’s a goal).

More recently still, and in the process of appreciating and integrating models as diverse as OKR, Viable System Model, Sociocracy, and Leader-Leader, I keep landing on a common theme: autonomous teams (and other organisational units) each expressing strategy in their own words, strategies negotiated, developed, and aligned through collaboration and participation.

To the top-down extreme, in the Agendashift 2nd edition (due later this month) I express my feelings thus:

It’s a funny kind of autonomy when strategy is something that happens to you. [And] it’s a funny kind of adaptive strategy if it doesn’t know how to listen.

Again, to make a hierarchical approach work effectively at scale and speed, you’ve got to be truly exceptional. Maybe you are; more likely you are not. Whether or not you are, please let’s agree not to describe it as the default “doing it properly” approach to which all Agile organisations should aspire.

While we wait for the 2nd edition (subscribe here for news), let me recommend Allan Kelly’s Succeeding with OKRs in Agile: How to create & deliver objectives & key results for teams, foreword by yours truly. Highly relevant to this topic!

Related:

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

---

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