Agility at Scale - A Meeting of Mindsets

YOW! September 2021 Recap

Anna Urbaniak and Daniel Terhorst-North

“Scaling Agile is not a thing. What we’re after is agility at scale.”

With that statement, Daniel Terhorst-North kicked off a fascinating talk about the myths and misconceptions of trying to scale up what works well for small software teams at an organisational level. To begin with, Anna and Daniel compared the two competing mindsets that we see in the industry, based largely around the traditional management mindsets of the Industrial Revolution, and the more modern Digital Product Mindset;

Clearly, the above table demonstrates that tension exists between these mindsets. When you think about a more practical application of these mindsets in software organisations, the differences become even more obvious. Digital Product thinking encourages teams to optimise the flow of work and not slow down delivery - Industrial mindsets put in place a Change Approval Board and require all changes to go through CAB. Digital Product thinking encourages the “Just In Time” design principle, making decisions only when required and at the right level. Industrial thinking applies Big Design Up Front, and a work breakdown structure of an entire project. While Digital Product thinking says “Trust teams and verify”, Industrial thinking looks at failures and believes the solution is even more process.

Clearly, the differences could not be more stark. Yet Daniel and Anna say both mindsets are needed in order to successfully delivery agility at scale. Their experiences working with the UK Government’s digital transformation played a big part in these learnings - something previously covered at YOW! by James Stewart.

From their experience, Anna and Daniel say this meeting of the mindsets can be achieved through a concept also made famous by Spotify’s Henrik Kniberg - the idea of autonomy with alignment.

(You can see some of Henrik’s talks on this subject here and here. It’s been reproduced and referenced to death, too… but with good reason.)

Alignment, as they saw it, would be necessary across the following areas:

• Product Vision; owned by product leadership, and shared via a product strategy
• Tech Vision; owned by technology leadership, and shared via a tech strategy or roadmap
• Approach; owned by practice leadership, and shared through ways of working (could be guilds, standards, etc.)
• Focus; owned by delivery leadership, and shared through shared OKRs.

Autonomy on the other hand is something they find to be more liquid in an organisation - it changes its shape and availability over time. Daniel modelled it as a supply and demand problem.

Demand was defined as;

• An objective, a purpose, or a goal
• Constraints; the rules of the road that must be followed
• Accountability; in terms of doing the right thing, and doing the thing right.

Supply was defined as;

• Capability; the skills, experience, information and context required to solve a problem
• Resources; be they digital or physical
• Authority; being able to have the permission to act to do the things you need to get the job done

Daniel would further go on to talk about “Autonomy Liquidity”, the idea that the above will flex over time and companies would need to understand this liquidity in order to guide their strategy. For instance, in terms of resourcing;

• If something is easy to obtain, just obtain it.
• If it’s hard to obtain, then perhaps we need to rent, borrow, or buy it.
• If it’s impossible to obtain, then we need to change our strategy entirely.

Wrapping the subject, Anna surmised that while alignment without autonomy is simply autocracy, the opposite was no better. Full autonomy without alignment would simply lead to anarchy.

As a final note, I did ask Daniel about his very first statement, that Agile cannot scale - you must scale agility. I put it to him that SAFe claims to do that very thing. His response?

“This is easy. It doesn’t work. And I can prove it doesn’t work from first principles… The armchair cynic is this; Scrum won. If the point of Agile was a marketing construct, Scrum won. Scrum created a wonderful, wonderful Ponzi scheme of certifications that certifies that I sat in a room for two days. It doesn’t qualify you for anything. And that created a billion dollar industry. That money came from people who used to buy the Rational Unified Process… But here’s the thing - what if instead of structuring this whole organisation of Scrum teams, and then waiting for the work to flow down to them, we instead structured the teams around the work we have to do?”

“SAFe cannot work outside an impossibly constrained, trivial environment in which literally anything could work.”

I actually found this to be one of the best talks of the entire conference - there’s a gold mine of stuff in there in terms of organisational design and team culture, and it’s definitely worth a rewatch when it becomes available.