Yesterday I was able to meet Thomas who runs a digital café, the café craft. Pauline was recently able to present our Wake Up RH offering there: in this episode / podcast. Thomas wanted to talk about “scaling agility”, like many people today. The episode will be released very soon, I had prepared this short text to start our conversation with Thomas. The episode will complement it.

Why are we talking about scaling agility?

  • Beyond approaches for teams (like Scrum) we’re questioning the entire organization. Either on an organizational level (liberated company, holacracy, etc.). Or on an operational level: this is what people mean by scaling agility: agility for the entire organization.
  • A movement reinforced by the impression that when it scales it becomes “serious”, more “acceptable”, than those agile teams, sometimes isolated. A bit like the absurd idea that persists that Lean is more “serious” because it’s “industrial”.
  • And therefore the underlying idea that “phew we’re going to regain control”. Agility, or rather evolving in a complex world, plunges management into perplexity. It can no longer clearly dictate what it expects as deliverables because the world has become uncertain. It must describe its vision, and maintain a framework that allows everyone to express their potential to achieve it. That’s completely different. In this systemic, holistic world, it can no longer play with its excel file by adding so many man-days here, and removing so many there, it no longer makes sense. It doesn’t work anymore. People are not interchangeable, dynamics are unique, additions and subtractions don’t work logically: you add 2 people to a team it will go… faster? slower? I don’t know anymore. Thus by scaling some hope to find clearer, more predictable cause and effect principles.
  • We know that it’s by applying constraints that we obtain more predictability. For example limits in Kanban, for example iterations in Scrum. By reinforcing these constraints at the company scale I suspect that some people hope to lay down a mesh that gives them back their predictability. But blanketing with constraints stifles involvement and results. Scaling agility is as its name suggests scaling up, multiplying, growing, but we don’t change worlds. It remains uncertain. It continues to demand a different approach from our traditional approaches. Different roles.

To summarize:

  • Need to question the organization beyond the team: organizationally and operationally.
  • Illusion of scaling = predictability, industrialization, but the world remains the same: uncertain, complex.

What then are the foundations of scaling agility?

  • If we must summarize the essential components in my eyes. The quest is for value creation. Whatever it may be: learning, better results etc. We can only learn, judge, benefit from this value if it’s carried through to the end, “done” in the jargon. Delivered. Exploited. Observed. The sooner the better, to get out of hypothesis as quickly as possible. The smallest element capable of proposing value “through to the end”, “done”, is the individual. But very quickly it’s no longer enough. In most cases it’s rather the team. A dynamic and assembly of individuals whose multidisciplinarity allows them to deliver finished things. The constraints imposed by approaches like Scrum or Kanban allow a group of individuals to work together, to form a team, roles, responsibilities, rituals. Clear rules for a clear objective (the desired value). For this to work even better, it’s desirable that this clear objective carries meaning (and values), and that the rules leave space to allow individuals to commit and have the best results. This is important for what follows. The individual will go faster than the team (relatively) but we’ll prefer the team because it brings with it its non-negligible dose of collective intelligence, and its ability to finish things more easily (multidisciplinarity). So the essential components are the team and the value focus and the framework and clear rules that allow individuals to commit.
  • When is there scaling? When value creation requires the aggregation of several teams. But keeping well in mind that the more teams there are the slower and more complicated it is for “done”. And that value comes from “done” (delivered, exploited, observed). Scaling agility is therefore above all cutting the perimeter well to allow maximum autonomy in its “done”, in its ability to deliver an autonomous set that makes sense, for the maximum number of teams. And when that’s not possible to still pursue maximum autonomy for each of the teams with strong synchronization points to a) regularly consolidate a “done” that makes sense with several teams b) learn from other teams, observe emergences, divergences, convergences, etc. There can also be exceptionally a synchronization role: for example a product manager who synchronizes the product owners as a meta-product owner. A prioritization role in this case.

To summarize:

  • Understand that the team is the basic component, value is the target and synchronization is the need.

What approaches should we turn to for scaling?

  • The mistakes of scaling in my eyes are the same as a classic approach around a single team. In a team we must understand that the best results come from committed people, and therefore from self-organized people (Dan Mezick). We simply ask them to self-organize for a certain purpose, a certain meaning, and respecting certain constraints, certain rules. These rules must leave enough space to have a real sense of control over one’s work tool within the team. The framework is therefore to be put in place, but certainly not the gesture to be defined: the gesture belongs to the team. This multi-team synchronization effort that I mentioned is also part of the framework.
  • The two “mistakes” (they are very deliberate in my eyes) made by the most well-known of these “scaled agile” frameworks, SAFe, are a) instilling a mindset contrary to the needs of these companies by making them think that “yes, the world becomes predictable again, yes they will find certainties again, yes they can function by forgetting the whole, yes everything is complicated (expertise) and not complex (emergence)”. b) giving a recipe on the gestures to perform and not the clarification of the framework. It’s quite revealing that everyone remembers from SAFe the “PI Planning” which is an element of the framework and synchronization, and not the multitude of details that kill commitment and good results but reassure management. I take this as good news – that people remember PI Planning –.
  • Scaling is not a reinforcement of certain gestures. It’s a reinforcement of the framework: particularly concerning inter-team synchronization, inter-team prioritization, acceptance of certain quality constraints (for example everyone does high availability – definition of done). By wanting to specify the gesture we stifle involvement, innovation, value creation.

To summarize:

  • The framework is important to define, not the gesture.
  • Illusions of SAFe: deceitful mindset and precision that stifles.

So it’s growing and not massifying.

  • Scaling is therefore growing it’s not massifying. Like a beehive, it must live in a very interactive way. It’s hot, not cold like a diagram that doesn’t move. We don’t add elements to add elements in this scaling. We preserve a value focus, we add elements because they bring value. Massifying to reduce costs is an approach that doesn’t work in this framework, in the context of a constantly evolving, complex world (massifying can work in other types of contexts). We’ll recall the key idea that if you follow costs you generate costs, if you follow value you generate value.
  • Growing doesn’t mean repeating. We don’t repeat the gesture(s) in any case otherwise we lose people’s commitment, involvement and thus a real lever to have the best results, innovation. If we don’t involve people, not only do we not get the best results, nor even the good ones, but also the transformation often fails, and the organization returns to its previous form.

A short series on scaling (and self-organization).

And otherwise the event we’re organizing in April 2018 around scaling agile: