Agile: scaling via sprawling

Scaling agile is a hot topic. With more and more organisations needing to ever-more rapidly respond to change, they find themselves needing more agile teams, and this presents challenges in communication, collaboration and alignment.

Recently, two of our Agile Coaches, Kelly Cook and Josh Lynas, were discussing scaling agile challenges over coffee. Here’s what they had to say...

Josh Lynas:  I’ve encountered the various forms of scaled agile over the last few years, and often found it frustrating. 

Kelly Cook: Oh really? In our seminars on scaled agile there’s a lot of people saying how frustrating it is, but I actually had a really good experience for a few years in a scaled agile environment. What do you find to be the most frustrating part of it?

JL: I’ve always felt like there’s an inherent inefficiency in trying to throw more people and more teams at a problem, hoping they can remain efficient and effective whilst tripping over each other dealing with a shared challenge. How can you possibly keep that spirit of small groups of people collaborating in an agile way whilst adding more and more people?

KC: There’s an interesting sentiment I heard during SAFe training that said there’s nothing more powerful than an agile team, except a team of agile teams. I think the key to keeping the collaboration spirit high is fostering the feeling of belonging to a tribe. But I suspect that one of your main bugbears is the extra processes and governance it seems to require.

JL: It’s always felt clunky to me, like the extra layers are too complicated, like the natural flow of collaboration is lost. I just haven’t seen an example of it that makes me go “wow, that’s the solution everyone’s been looking for.”

KC: Clunky as it may be, in many places, given the rate of change in the market and competition, as well as the scale of ambition, organisations have little choice but to scale… So tell me this then, if you absolutely had to, how would you go about Scaling?

JL: Absolutely, there’s clearly a need for it. If I were looking to scale, I’d scale by not scaling, or at least, by not scaling in the way we traditionally think of it. 

KC: Not in the traditional way… sounds interesting, can you expand?

JL: I feel that often, Scaling is often treated like building a Skyscraper [bear with me here…]  we throw more and more people at a problem, hoping we can just add another floor, another team, to our foundations and suddenly deliver at a greater pace. People see Scaling like a Skyscraper that they want to build higher and higher, putting more floors (people) onto the one problem, in an effort to ‘do more, and do it faster’ (you can almost hear the building owner demanding “build it higher!” at their architect).

KC: What inspired your skyscraper analogy?

JL: Well, Skyscrapers exist to fit more people into an expensive space. We build upwards because it is more efficient than buying more land and building outwards, it’s expensive to buy more land, so instead we build further upwards (which is also expensive, but somehow, less than buying more of the land).

JL: Scaling, as it's commonly understood, [throw more people at it! Add another team!] is also expensive, designed to get lots of people working on the same real estate, and leading to people tripping over each other, struggling to coordinate and being overall inefficient. 

KC: There’s definitely times when companies fall prey to the temptation of throwing more people on the team to get the product live quicker, and we know this rarely works. So, coming back to your approach to scaling, how would you like to do it?

JL: To continue with the Skyscraper analogy, my thoughts were drawn to Auckland, a city I'm very fond of. Auckland is the largest city in New Zealand, has around 1.4 million people, and is fascinating, because unlike most big cities, it doesn’t have a skyline full of skyscrapers - there are approximately 20 buildings that are more than 100 metres tall! 

Sure, it has a few, but many of its buildings are only a few stories tall. There’s a small cluster of tall buildings, but it doesn’t have a skyline full of skyscrapers like New York or London. There’s more space to build outwards, and therefore things can stay a bit closer to the ground.

KC: Right, in the world of agile teams instead of architecture, what does a sprawling city look like (as opposed to a skyscraper)?

JL: The most efficient and effective teams I’ve ever worked with were 4-6 people, communicating well and collaborating constantly, whereas teams of 10 or more certainly have started getting in each other’s way, with communication suffering. These, in building terms, are 2-3 story buildings, rather than Skyscrapers. And, in terms of getting numerous teams to work together, I’ve seen it work well across groups of 3 teams, but beyond that it’s often felt more arduous. 

KC: Yeah, that’s very small in the scaling world. So, what do you think it should look like?

JL: Inspired by my love of Auckland, I would reframe scaling like this: Stop thinking of how many more people we can put to work on one problem, and instead start asking “how can we split this project/product up into smaller chunks that we can give to separate teams?” How can we scale outwards instead of upwards?

KC: Let's come back to that in a minute...Where else can we draw inspiration from to break big ideas into smaller pieces?

JL: We don’t have to look far for examples of where this has already been done. The fastest processors today aren’t one mega fast processor, as was the case for a long time, instead the model and architecture has changed. Now the focus is on lots of small, efficient processors working together, splitting down the problem at hand to smaller simple processes that can run side by side. Similarly, software architecture has moved away from monoliths to building in more discrete and modular ways.

Coordination between these small, efficient units is the challenge, and what could really slow us back down. To minimise this, we should aim to keep the separated problem chunks as discrete as possible, minimising dependencies and coordination required between the small efficient units. 

So to come back to your question, and give a more concise answer - How would I go about Scaling? I would Scale via Sprawling. 

KC: Got you, but the scaling frameworks in the market today believe that they solve this need for effective coordination between small efficient units. They each try to achieve it with slightly different techniques, but certainly their goal is lightweight collaboration between cross-functional, empowered teams. Obviously I can’t speak on behalf of them but I’m sure they see themselves as the Auckland model already. 

JL: Perhaps, but in practice I’ve not observed that these frameworks are effectively helping organisations to break down their product ideas into smaller ones. You’ve spoken of positive scaling experiences in the past, so what was your experience with that?

KC: It definitely takes time to get the hang of it. There’s organisational barriers in place that push back on attempts to break things into smaller pieces, e.g. funding cadences, business case processes, fear of releasing simple versions of products, and both infrastructure and cultural challenges analysing product performance, usage and feedback to iterate simpler versions into more refined ones. 

Where I saw SAFe work really well, was in a large bank where the online and mobile banking platforms were the gateway to all their products and services. That meant high, frequent demand to deliver new features and products from all over the bank, serving many different stakeholders. 

JL: and what made it work; what were the key ingredients?

KC: One simple thing was that the release train doesn’t stop, it releases regularly whether or not your feature is ready. Therefore it’s imperative to break ideas down into small enough chunks that you can get it done in time. And it’s important to build up your technical enablers like feature toggling and considerable automated testing to support this.

The other really important ingredient was ensuring that each cross-functional team was responsible for a part of the system. They could build up their expertise and their sense of accountability. We had a team that looked after any changes to the Payments features, another team for Accounts features, another team for Sales Product Pages, etc. Whilst there were still dependencies to be ironed out, they were reduced, which meant less tripping up over each other’s feet in the codebases, less governance overhead, and ultimately a little less coordination effort.

I also think SAFe’s solution to visualising cross-team dependencies during and after PI planning works really well.

JL: That sounds like your experience lines up with my thinking, giving discrete sections to teams, allowing them to have ownership and a level of autonomy whilst working on their own area. 

I wonder if we go back to the skyscraper analogy, is my frustration coming from companies trying to build skyscrapers on the foundations of a 2 story house, rather than laying new foundations and starting afresh? Is it that some companies want to move to ‘scaled agile’ without ever doing a hard reset, getting those new foundations in place, setting up for success.

KC: There’s definitely a balance to be found, holding off on starting that transformation until everything’s set up perfectly is not the way to do it, but we shouldn’t just carry on with the status quo as if the continuous improvement work will magically happen. It’s about finding that balance, ensuring that as you are delivering your product features, you’re also improving the technical infrastructure, paying down tech debt, improving automated deployments, and improving automated testing capabilities. These are crucial foundations for scaling successfully. It’s not just technical foundations either - there’s great need for excellent product ownership, good visualisation of progress, communication between teams, and a strong community spirit throughout - you have to care about the success of all of the teams, not just your own. 

JL: That all sounds really sensible. I wonder if we can summarise then, to a couple of top tips for scaling. It sounds like we’re both agreed that ‘Sprawling as you scale, creating discrete chunks of work that cross functional teams can own and deliver’ is crucial.

KC: Yes, and ‘ensure you invest in foundational activities as you go’.

Trying to scale an Agile mindset in your organisation? Talk to us about how we can overcome the challenges together. 

Get in touch.