The Myth of Scale
The brilliant Cooper Review once published a set of 10 Tricks to Appear Smarter in Meetings. They’re all excellent and can be seen every day in every office on earth. If you’ve been in a meeting with a consultant, you will have seen more than one of them.
The one that I’ve found most interesting recently is number 6:
Ask ‘Will this scale?’ no matter what it is. – The Cooper Review1
In keeping with the Cooper Review’s observations, and as a white middle-class male, I’ll presume an eleventh trick: in response to the question of scale, we should ask why?
Corporate Scaled Agile
When we talk about agile in a corporate setting, it’s a matter of minutes before someone mentions the s-word, and a short time after we’ll begin discussing the successful, fully licensed off-the-shelf frameworks a company can buy to go Full Scaled Agile TM.
We get from asking about scale to choosing a framework too quickly, and this is problematic. This doesn’t mean frameworks are bad — indeed, that we talk of them so quickly suggests just how successful they’ve been. Indisputably, SAFe and other models have demonstrated significant success in large enterprise IT settings such as big oil and big tech. For example, I once found myself on an aeroplane sat next to Intel’s chief information security officer who was amazed with the results of applying it, and he was keen to point out the more rigid the application the better.
All models are wrong, some are useful; frameworks are no exception. Where the context and the framework align well, success happens.
Equally, if we don’t understand what’s driving scale, we’ll end up misapplying a framework. The fallout from whatever follows could end up being a costly transformation effort that doesn’t deliver as promised.
Why?
Assumptions
Two assumptions have been made, one swiftly following the other:
- We must scale.
- Therefore SAFe/Spotify/AWS or any other established model.
The first, I think, is the one that bears more consideration.
Certainly, any company that has run some successful agile projects will want to see the benefits of this approach more widely — at scale, if you will. This calls to mind such concepts as economies of scale and thinking around restructuring the organization to enable scaled agile.
And this is where we enter the danger zone. We’re now driving toward scaled agile as the goal, not the results of scaled agile. A small syntactic difference is a big implementation difference.
Scale is not more-of-the-same-but-bigger
The familiar concepts used to deliver agility at a team level (such things as Scrum or Kanban, alongside more intangible ideas around mindset) are very good for a team.
However, where the principles that underlay them are sound for bigger things, it’s often the case that companies seek to apply the same-practices-but-bigger to get to this Shangri-la of scaled agile.
One such example is Scrum-of-scrums. It works really well for organisations that have few layers between strategic leadership and delivery. But if your company has thirty layers of hierarchy between the CEO and those doing the projects, then scrum-of-scrums caters for only two, maybe three of them. If you repeat the model (a scrum-of-scrums-of-scrum-of-scrums… and so on), trying to align all those showcases and surface the information in a timely manner will quickly become the antithesis of what you’re trying to achieve.
I paint a caricature here, but I’ve seen almost this a bit too often.
The Myth of Scale
We risk leaping from a back-of-envelope calculation saying “if we repeat the success of these individual teams across our enterprise, we’ll save x” to costing more money than we aimed to save. This is because we’re driving at scale for scale’s sake and, maybe, applying a model ubiquitously. Here be dragons: mythical, uncharted bits at the edge of the map.
What is Scale?
Scale for scale’s sake is irrelevant.
While it’s quite fine to ask how to scale benefits of agile (as opposed to simply scaling agile), it’s even finer to ask why. The purpose of scale is not to deliver a scaled agile model, it is to reap benefits on different operational levels — the subtlety between the two is vitally important.
What to do?
To quote the Cooper Review again, let’s take a step back.
If your company is trying to reap the benefits of agile at a team level and see benefit at an organizational level, what does that look like?
Here are some key questions that can help drive that conversation.
- What would an agile enterprise feel like to work in?
Ignoring the concept of scale and putting in some analysis to understand what this would mean for your company in its industry/ies.
Some of the nimblest companies operating today have not ‘gone agile’ in the superficial application-of-process sense. - Are the benefits of scale real? Or, do we need a framework to deliver benefits?
If you have every team running agile, is that enough, or do your numbers include calculations on economies of scale beyond a team-level application? Could the business realize that back-of-envelope benefit of having every team work in agile without implementing a multi-team governance structure?
The answer might be no for any number of reasons, but it’s still worth doing an analysis to assess the costs of implementing a common structure (such as SAFe) vs the benefits you’re expecting.
Are they really that great, how real are these numbers? Are you accounting for things like single points of failure, or the age-old-problems of a shared business services being unable to have concept of end-customer and suddenly being a cost centre? - Do we need consistency?
Or, do we need every team to implement agile in the same way?
Hint, the answer is “no.”
What does good look like if we accept inconsistency between applications? - Do any of the existing agile frameworks look like what you’re trying to do beyond one team?
Established agile frameworks such as SAFe and Scrum became established in enterprise IT settings. How much of that is useful to your context?
And as for assumption number two: If any of the answers to the questions above start to look like you need a clear, established framework that you can get implemented by any number of agencies, then it’s worth consideration: frameworks are effective if applied with relevance.
However, if your answers to the above leave you in doubt, it’s worth understanding what you think you need when you talk about any scaled agile framework. These questions can help you on the path to creating your own framework that’s tailored for you and your business.
