Scaling ≠ at scale – Remember: «at scale» means something different than «scaled»!

It might be because I'm not a native speaker, but there is something about "scaling agile" or "scaled agile" that really has been bothering me these last couple of years.

As I wrote before in my recollection of events agile was described as something that works well for small teams.
IMHO at least two of the principles, namely "face-to-face communication" and "architectures, requirements and designs from self-organizion" are extremely hard to do in larger groups – unless you add additional constraints like structures (aka hierarchy) or special roles outside each individual group of people or team (aka specialists).

So what are we talking about, when we talk about Agile at scale? At scale means (according to YourDictonary.com) to have something that is "at the required size to solve the problem." Scaling on the other hand means "a linear transformation that enlarges or diminishes objects."

What does that mean for scaling agile approaches?

Do we really want to scale e.g. the number of people involved in solving one specific problem? Because, actually the communication overhead does not scale linearly – it 'scales' according to Metcalfe's law and thus communication quickly becomes inefficient. (With 5 people there are only 10 unique ways of communication, with 12 people the number is already 66)

Therefore: Why do we keep talking about "scaling agile?"

I think we should talk about "appropriate solutions at scale" and strive for them. That might include approaches from the lean and agile communities, some implementation of the Kanban Method to facilitate the change and many other ideas that are appropriate for the actual challenges at hand. When we truly live in a volatile, uncertain, complex and ambiguous world, than maybe the solutions for big and complex organizations can also only evolve over time according to each specific organization.

till next time
  Michael Mahlberg

Let's Scale the Small Team Approach?!?

After the chaos report came out in the mid nineties and made the public statement that 53% of evaluated projects where "challenged" and only 16% of them could be considered "successful" a lot of people started to focus on the errors that supposedly had been made in the 53% of challenged projects. And from the tries to eradicate those errors from all future projects a lot of the so called ”heavy“ processes where born. For the curious: the remaining 31% of projects got cancelled before they ever saw the light of day.

Yet some people focused on the question what the 16% of successful projects did differently – in line with the old coaching mantra of "catch them doing something right." Amongst other things a lot of these projects followed what today would be called an agile approach - kind of living and breathing some of the principles behind the agile manifesto even though that didn't even exist at that time.

Although the principles could be weighed differently one of the key concepts in my perception always was

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

which also requires the teams to be of manageable sizes – the magic number 7 ( plus or minus two ) comes to mind.

Because the number of required communication lines grows exponentially with the number of team members it quickly gets impractical to have face-to-face conversations with larger teams and this in turn contradicts the whole idea of "scaling agile."

Of course it's possible to develop software in an agile manner with more that just one team, but then something else has to come into play. At least "Agile" as defined by the agile manifesto doesn't account for scaled agile. Scrum tried to address this topic with the Scrum-of-Scrums, but I think nowadays there are more obvious ways. Like integrating agile teams via a lean organization. You might want to give it a try.

Cheers
   Michael