Invited by my excellent colleague and friend Alain Sacquet to offer feedback during a Think Tank on Agility@Scale traps by GFI, I thought about the angle on which I would like to approach the subject. It didn’t take long before I decided on my favorite topic: the teams, and more specifically, the maturity of the teams.
Indeed, at the start of an Agile transformation, we experiment on one or two teams, most of the time, to put the maximum chance for the success of the project. To achieve that, we constitute a team with the best elements of our teams. First, because they are often promoters of the method and because we also want to promote them. However, as this is a pilot team, we are going to create a hyper-protected space for them, with the right to make mistakes and psychological security without really realizing it. This creates an ultra-biased situation, and in truth, regardless of the approach used, it is very likely that the result will be up to expectations.
If it is useful to be able to convince sponsors to launch an agility approach at scale of your IT, or even of the company, you have likely learned nothing, except probably some artifacts from the method you have chosen, often SCRUM.
The Cargo Cult
Building on this “success,” you are preparing to deploy at scale, through extensive training for some of your employees to become your future Scrum Master or Product Owner, or you buy an “Agile Transformation” package to a big consulting company. The walls are transformed into post-its columns for visual management; your teams meet every morning standing up to discuss the post-its they have dealt with.
That’s it; you are Agile. Champagne!
Or not. It’s more likely that you have A.I.N.O. – Agile in name only: It has the color of agility, the taste of agility … but it is not agility. This phenomenon is called the Cargo Cult.
The Cargo Cult is a phenomenon that appeared in the 20th century when the Aborigines copied what they observed from Westerners without understanding, to obtain food in particular. Thus, they copied a radio transmitter because they thought that they would also receive rations and equipment. After many unsuccessful calls – and for a good reason – they created an airstrip. Without more results, obviously.
By copying without understanding, they had no chance of achieving the results they hoped for. Does that remind you of something?
Symptoms can be simple to detect; just walk around your open spaces and ask questions.
For example, it is very likely that most teams have visual management because it is one of the primary markers visible to everyone, including managers. But is it really used or even useful? Ask a member of the team, is the topic he is working on in the “current” column? Conversely, take a post-it from this same column and ask who is working on it?
One of the other primary markers is the daily stand-up meeting. Does it respond really to intentions of collaboration and transparency?
It is often summed up in three usual questions. Little by little, the members of the team no longer listen to each other because it becomes a moment of reporting. In extreme cases, it gets longer and longer; people arrive late, even people don’t speak to each other outside of this meeting…
Many coaches have written on this subject, I invite you to read:
- Anthony Mersino – You Should Stop Doing Daily Scrum Meetings
- Age Of Product – Daily Scrum Anti-Patterns: 20 Ways to Improve
- Judicaël Paquet – The Daily Scrum Meeting
- And – of course – CommitStrip:
“When the organization does not understand the philosophy, culture, and intentions of Agility, individuals apply “recipes”. It then becomes more important to respect the instructions (such as the 3 questions of the Daily) rather than to apply an intention – increasing collaboration and transparency.”Martin Proulx, Expert in Agile behaviors, Audacium Leadership inc.
Transform at scale
To avoid this phenomenon, it is crucial to understand that a transformation, a change in practices, cannot be deployed simply by applying a framework (Scrum, Safe, etc.). Human beings are not robots on which we apply updates:
In particular, if we do not understand the meaning behind these practices, we will only transmit the artifacts and not the intentions. Asch experiment demonstrates our ability to conform to the group, even when he’s wrong.
This is how, sometimes, with the help of a consulting company, we achieve the A.I.N.O. – Agile in name only. By imitation, conformity, we very quickly see ceremonial and other artifacts bloom. The scrums masters and product owners are certified, and as if by magic, your organization is “Agile.”
The situation can even be even more fragile because often managers and teams retain only the perceived benefits without understanding and therefore taking into account the constraints.
This is how we end up with “autonomous” teams with a tendency to “independence” because we did not support the team’s growing maturity on this subject. This is also how we end up with managers who “trust” the teams as long as there is no problem, but who returns to a controlled mode as soon as there is vagueness or risks.
This is not about giving lessons; the previous paragraphs have mostly shown that it is not enough to apply recipes for it to work. The object here is to share what I thought helped in my various contexts.
These points are the fruit of learning and experimentation, and seem important for me when scaling up:
- Have a vision, a horizon. We do not scale because it is fashionable (in any case, it is not desirable), but to meet needs in a context. We often underestimate this part, which allows everyone to find meaning in the transformation. It is not only a question of co-constructing a vision, but also of promoting it, of “marketing” it so that it is known to all and shared.
- Develop human skills, “soft skills.” During recruitment or the transformation, it is particularly necessary to develop the capacities to:
- manage a disagreement or conflict,
- decide together,
- listen without trying to convince,
- support each other in the face of uncertainty.
- Integrate new employees and teams. Bootcamp formats allow you to spread your company’s DNA, for example, to experiment with practices in the context of psychological security. The practical cases are much more exciting and motivating than slideware.
- Build a network that supports the change and the dissemination of skills. An Agile coach alone, or even a team of coaches cannot support the transformation solely, and above all, must be able to get out of the device. It is, therefore, necessary to set up a sustainable system that will support the teams over time.
There are many others, and to dig deeper into this subject, I invite you to read the book co-written with Alain Sacquet Implement DevOps: How to evolve towards an Agile IT? #self-promotion #in-french
Beyond the previous points, what seems essential to me to remember is that a company is a complex environment, individuals, and groups as well. You can’t use one method for everyone, and it takes time.
We must accept that each team will have a different level of maturity and that we will, therefore, have to adapt our management and support methods according to this level.
This maturity model is based on Olivier Duvillard & Bruce Wayne Tuckman, who proposed models for building group cohesion.
The idea is, therefore, to develop Agility according to the level, for example, by taking inspiration from the Shu-Ha-Ri concept — a concept from the Japanese martial arts which describes the 3 stages of learning. Shu-Ha-Ri can mean following the rules, understanding the rules, and transcending the rules.
The frameworks (Scrum, Safe, …) are useful in the Shu stage of learning Agility. But to be able to really move to Agility @ Scale and bring all of our teams to the level of Excellent teams, the organization will have to understand and above all transcend them.
To explore this subject further, I invite you to read the work based on Bruce Tuckman:
- What is a group and how does a group function? Group dynamics and the model according to Bruce Tuckman and Ruth Cohn by Antje Kreher
- Forming, Storming, Norming, and Performing by Michel Johnson
Back to basics
Finally if we return to the Agile manifesto, and in particular this principle:
An interesting question to ask our teams to measure our agile maturity:
What value that you have delivered to your user/customer have you been the most proud of in the past three months?
The word proud is important because the company spends significant budgets on our subjects, and we spend a significant part of our time in our professional activity, make sure that this time is useful and that it makes us proud:
“I cannot imagine that we cross life and time unconsciously in a common way. By not knowing, the day passed, at the edge of the night, what we did with it. It’s one of the things that scares me the most, to realize that time goes by without doing anything.”Christiane Taubira, politician