pablo pernot

Dojo Agile at scale

Last Monday, like every Monday, there is a dojo at the vessel. The ship is the offices at beNext. The dojo is the place where you study. Every Monday we propose to the teams on site 1 hour on a subject carried by someone who knows a lot about it (on the subject). Last Monday, therefore, it was a dojo on “agile to scale” because we are often (unfortunately) asked about SAFe. You can imagine that I offered myself.

Note: No participants were mistreated or certified during the dojo.

Here is the content of the dojo that I summarize here, for me, for you and for them: “one hour on agile to scale”.

Agile and agile enterprise on a scale

First of all, it is necessary to make the distinguo between agile and agile companies to scale. The two can mix, but it’s not the same thing.

  • Agile on a scale: spreading a way to produce value to as many teams as possible (potentially only impacts the production apparatus). Designed for large companies (large in size).
  • Agile Enterprise: Operate in all parts of the company in an agile way and with an agile mindset. Aimed at any company.

SAFe, Nexus, Less, Spotify, Scrum@scale, and all the rest

In the mid-twenties, there was an explosion of Scrum and Agile in the heads. Beginning of the years 2010 until 2015: the big companies until then haughty, Scrum appearing only for the teams in a rather unitary way, deign to take a look at it. But they are different, they are big, they are big, you have to understand when you hear them: “they have some”. They need something that is up to them. Frameworks* (ready-made bases) of Agile to scale are there in ambush to serve them. Either these frameworks have emerged from a company and through feedback and conferences have become protected designations (Spotify), or they are simply marketing assemblies made to seduce at any price (SAFe, see links below).

These approaches are not reproducible as they stand and are often alibis for being agile. You have to look at them with suspicion. Or have fun as Henrik Kniberg said: “I love SAFe, I use 30% of it” (why you have to be suspicious of SAFe and Henrik Kniberg’s presentation at Octo (thanks for the invitation at the time).

So yes, we’re asking you about these frameworks, but it’s a bad starting point. A real company on a scale raises the question of value on a scale and not how (agile podcast on a scale at Café Craft).

Scaling Agile

How to bring back Scaling Agile to its essence?


We start with one team and then several. These teams must then be synchronized. Agile on scale is first and foremost a question of synchronization. For this purpose, agile has been offering quarterly planning (or other names) for a long time. During one or two days, every three months (for example), the actors of these teams are synchronized. All the actors are present in the same place. Opening for example by the PM (product manager) who oversees his PO (product owner), then each product owner presents his stream (his part of the product, which we hope is dependent), perhaps the team of architects, for example, presents the key points for the next three months. And in the afternoon there is a phase where each team progresses on its planning for the next three months (ideally format user story mapping). The day ends with a phase of reconciliation of the different schedules, adhesions or not.

From experience with six or seven teams, we saturate the synchronization capacity. But I saw quarterly planning whose limit was 150 people. It’s a smart limit. We must therefore think carefully about its organization into departments organized around products with these limits.

As always for an agile iterative approach, we must try to avoid adhesions as much as possible, to decouple.

On synchronization: Agile to scale: synchronization

The big picture

To scale means big size. It is necessary to have a global perspective with adequate levels of aggregation. Agile to scale requires a good vision of your project/product portfolios. For this reason, it is often a Kanban the difference (Portfolio Kanban).

We need a way to see the large groups, the synchronicity needs, the dependencies, the global strategy.

A product is often divided into vision, epic (big theme), feature (functionality), user stories (user stories), tasks (tasks). You can have kanban portfolios at the product or project level, epic or features. The important thing is to perceive the dynamics, the strategy, the macro motives.

Reorganization of managers and therefore of the organizational chart

An organization that really tries to become agile often has to rethink its structure, its organization chart. Quite often we come to the point, and this is very good, of having to distinguish the manager of the product, the manager of the competence. For example Gérard - drawing team leader - Natacha’s manager - drawing designer - before the reorganisation. He tells her what to do and why and how. After the reorganization, he becomes his manager of competence: how to make Natacha’s competence grow, he accompanies the how. He now lets Emily take care of him what to do and why. This is not easy for many managers who are used to saying what and how (and who sometimes, often, forget the why).

Organizational issues and transformations

When and how quickly is the organization or agile on a scale fully implemented? That is to say, truly to scale, or that the company becomes truly agile in its entirety? At first I thought it needed some kind of big bang. Then I changed my mind, I supported a gradual transformation of the whole company, and for the past two years I have gone back again, you need a big bang in my eyes. Not a big bang for the 8000 people in the organization, but rather a big bang that makes you go from 200 to 2000 (2000, 3000 is probably a limit). Usually it all starts with a pilot. But the pilots, unlike their names, are not representative of what will happen. They just give a glimpse. The pilots are carried out with interested people, involved, in protected settings. And as long as they are pilots, the organization lets it happen. It is when we move to the level above, to the level of the department, real clusters of several teams, that the resistance of the organization really comes to light. If it works at this level, say from a department, it is the signal that you can switch to scale.

So why a big bang at this time, which would increase you from 200 to 2000, for example? Because there’s two chaos. The negative chaos that drains your energy away. It is the one where the organization has not chosen. The two approaches coexist: agile and non-agile. It is a source of pain and misunderstanding, which leads to difficulty in reading and understanding. It is a negative chaos: you suffer things, you are in reaction, in confrontation. Positive chaos is the one just after the switch, just after the big bang signal. It’s chaos, but it’s positive, you know what the target is, and all your efforts are linked to rehabilitation, reconstruction. It is a chaos that creates value.

And if you think you’re doing without chaos, it’s because you’re not changing anything. Chaos is necessary. You change jobs, you change lives, you change places, you usually change jobs, there is always chaos.

Risk with Scaling Agile ?

The risk is that it will start to work up to a certain perimeter, a certain extent. Then for some reason you went back. A change of direction, the resistance of the organization that returns to its previous state, etc. In this case you risk losing your talents. People who have tasted autonomy, responsibility and involvement are like having tasted the forbidden fruit, it is difficult to go back. They will be very frustrated. And who will have the facilities to leave the ship quickly if not your talents?

Dojo agile échelle

scale enterprise chaos safe less synchronization risk transformation vision