--- English will follow ---

Au travers de mes expériences de coaching, j’ai pu constater que le changement, ce n’est pas facile. J’ai déjà mentionné dans un article précédent que l’adaptation au changement est une clef de succès et peut s’acquérir. Il est cependant possible que des gens ne souhaitent pas évoluer, pour diverses raisons.

Dans ce cas, le coaching devient plus compliqué, et donc le changement culturel s’en trouve ralenti. Voici quelques situations et exemples qui peuvent apporter de la lumière sur ces comportements, pour vous aider à les identifier et vous apporter quelques pistes de solutions. Je tiens tout de même à indiquer qu’il n’existe pas de recette miracle, chaque cas, chaque personne, chaque contexte étant unique.

Devenir Scrum Master (ou son penchant Kanban), les chiffres font la loi.

Ce fut mon cheminement, et ce ne fut pas facile, loin de là. Lorsqu’on est PCO ou CP, bien souvent, c’est parce qu’on est cartésien et qu’on aime les chiffres. Personnellement, je me débrouille bien avec Excel et à l’époque, lorsque j’étais CP, trouver et appliquer les formules pour automatiser les calculs dans mes différentes feuilles me donnait un certain plaisir et de la satisfaction. Je le fais encore à l’occasion aujourd’hui, mais pour des passe-temps, et non plus pour le travail.

Quand on devient ou souhaite devenir Scrum Master, il faut être ouvert à désapprendre. Il faut être capable de sortir la tête de l’écran et de ses chiffres pour regarder, découvrir, ce qui se passe au niveau humain. Et il faut avoir une certaine dose de leadership pour accepter ce rôle de berger, c’est-à-dire être en mesure d’avoir des conversations difficiles autant avec les membres de son équipe qu’avec ceux qui constituent l’environnement de l’équipe – qui sont bien souvent ceux qui nous demandent les chiffres en question.

Les CP sont habituellement à l’aise avec l’aspect leadership, mais se trompent en pensant rester en position d’autorité. Un SM n’est pas en position d’autorité. S’assurer que Scrum soit appliqué comme il le faut, comme le recommande le guide, n’est pas mettre le SM en position d’autorité. Il s’agit de fournir à l’équipe un guide, un « sage », un « Wikipédia humain » auquel on se réfère pour appliquer Scrum. Tout CP qui souhaite se transformer en SM parce qu’il pense garder une autorité sur son équipe se trompe et est un facteur des échecs de transformation.

C’est aussi pourquoi les CP tendent plus à devenir SM que de s’impliquer dans Kanban. Kanban a des rôles différents dont les liens avec le « traditionnel » sont moins évidents. On observe aussi un plus grand déséquilibre dans le quotidien des CP qui passent en Kanban que ceux qui passent à Scrum à cause de la responsabilisation plus importante des équipes. Malgré les principes et pratiques Kanban, on dirait que le guide Scrum donne un sentiment de sécurité que Kanban n’offre pas. Pourtant, au même titre que le PMBOK (ou encore le Macroscope pour les initiés), ces guides sont beaucoup plus prescriptifs et ne permettent pas aux CP de reprogrammer leur cerveaux pour apprendre de nouveaux réflexes. Le guide, dont ils doivent avoir connaissance (et que l’on cherche à cacher des membres de l’équipe, pour conserver leur supériorité en connaissances) leur confère ce sentiment d’autorité.

Kanban n’étant pas prescriptif, tout le monde peut avoir raison tant et aussi longtemps que cela permet à l’équipe d’être efficiente. La perte de cette perception d’autorité est majeure. La jeunesse du CP se transformant peut aider à avoir une transition plus douce.

Les carrières pré-définies

L’autre difficulté à laquelle on fait souvent face lors de nos transformations est la relation que les gens ont avec leur carrière. Le développeur passé analyste, puis architecte, puis chargé de projet, voit d’un assez mauvais œil le passage à Scrum Master. Pour lui, l’accomplissement d’avoir obtenu un poste de gestion supplante (supposément) le plaisir qu’il a d’être dans le contenu. Et pourtant, ce sont souvent ces mêmes profils de CP qui plongent dans le contenu constamment, au détriment de leurs équipes. Dans ce cas, n’est-il pas préférable de leur demander où trouvent-ils leur plaisir? Lisent-ils plus sur l’Agilité ou sur leur domaine de compétence technique? C’est un point important à questionner lorsqu’on s’apprête à changer les rôles traditionnels vers des rôles considérés Agile.

Il y a également l’effet « Je reproduis ce que mon patron/directeur a fait ». Dans la majorité des organisations, le comportement du supérieur immédiat sera reproduit, car la logique humaine veut qu’on copie ce qui marche, notamment en ce qui a attrait au succès. Pourtant, est-ce que ce directeur est la bonne personne? Ne dit-on pas que plus l’on progresse plus, on atteint notre niveau d’incompétence (principe de Peter)?

Cette biomimétique dans une organisation est l’un des éléments critiques, mais difficile à changer. Car aux yeux de ce supérieur, cela pourrait donner la perception d’admettre ses erreurs, de perdre ce qui a été gagné au bout de vingt, vingt-cinq ans de carrière. De même que pour cet aspirant-supérieur, le cheminement fait pendant les cinq dernières années l’amenait à suivre les pas de son « mentor ». Et maintenant l’Agilité voudrait l’empêcher d’y arriver? C’est une situation délicate qu’il faut être capable d’identifier pour ne pas se heurter à une résistance forte au changement.

Les départs en retraite

Beaucoup de gens que nous accompagnons sont proches de la retraite. Quelque soit leur excellence et professionnalisme au cours de leur carrière, ceux-ci ne voient pas, à quelques exceptions près, l’avantage de changer. Souvent on entendra « qu’il était temps que ça change ». Mais eux, ne voient aucun sentiment d’urgence de changer. Ils partent bientôt. Identifiez-les, non pas pour les exclure, mais pour vous assurer qu’ils ne viennent pas influencer négativement vos équipes. Au contraire, et notamment en Kanban, c’est l’occasion de les décharger de la réalisation au quotidien pour les mettre à disposition de l’équipe pour un transfert de connaissances optimal et au besoin! Mais attention aux « il faut lui trouver quelque chose à faire ». Malheureusement, ce réflexe organisationnel est à combattre. Car en réalité, ce futur retraité a déjà quelque chose à faire : transmettre sa connaissance, être le « pair » de « pair programming », être celui qui fait la revue de code, par exemple.

Quelles ont été vos situations bloquantes et humaines?

 

---

 

Through my coaching experiences, I realized that change is not easy. I already wrote in a previous article that adaptation is a key of success and can be learned. However, you can face situations where people do not want to change, for various reasons. In these cases, coaching become difficult and the cultural change of the organization you are helping is slowed down, if not halted. Here are some cases and examples that can help you get some light on these behaviors, which will help you identify them and bring some resolution proposals. Be aware that there is no miracle recipe, as each person, case and context, is unique.

Becoming a Scrum Master (or its Kanban counterpart), where numbers are the law.

This is the path I took, and it was not easy. When you are a PCO or a PM, most of the time, it is because you are down to earth and you like working with numbers. Personally, I am good with Excel, and at that time, finding and applying formulas to automate the calculations in my many, many sheets gave satisfaction. I still do it from time to time, but for hobbies, and not in a job context anymore.

When you become or want to become a SM, you must be open to « unlearn ». You must have the ability to get out of your screen and numbers to look up and discover what is happening with your team members on a human level. Obviously, an amount of leadership is required with this role of a « shepherd », namely when you need to have difficult conversations with your team members or the people revolving around your team – which are often the people asking for those numbers.

PMs are usually fine with the leadership part of the role, but they get it wrong if they believe they will still have authority. A SM is not in an authority position. To ensure that Scrum is applied according to the guide, or as the guide is recommending it, doesn’t mean that the SM is in authority. It is a way to give the team a guide, this « sage old man » or even a « human Wikipedia » to whom we refer for applying Scrum. Any PM who transforms from PM to SM because they think they will keep an authority position is mistaken and becomes a factor of failure in an organization transformation.

In my opinion, it is also a factor of why PMs prefer to become a SM than its Kanban counterpart. Kanban roles are different and their links with traditional delivery are less obvious. We can also observe differences in daily Kanban-PM routines versus SM-PM ones, namely because the team is empowered faster. I also believe that the Scrum Guide gives a sense of security or comfort to the PM, whereas Kanban’s practices and principles do not. When, like the PMBOK, the guide is very prescriptive, it does not allow the PM to reprogram their thinking and reflexes. They then use the guide as a way to keep authority over their team members by saying « I know it, I have read it, I am certified and you are not ». Which, of course is not the intended Scrum Guide’s purpose.

With Kanban being not too prescriptive, everybody is right, as long as the team is efficient. Losing this kind of superiority is major in the head of a PM. However, the younger a PM is, the smoother a transition can be.

Predefined careers

One of the other difficulties that we face during coaching is the connexion people have with their careers. The developer who became an analyst, then an architect, and then finally a Project Manager does not see becoming a Scrum Master as a success. For them, and supposedly, the acknowledgement given by their management position supplants their satisfaction of dealing with content. Unfortunately, it is often the PM and/or the SM that interfere continuously with the content for their teams. In this case, is there a benefit to ask them where they get their satisfaction at work ? Do they read more about Agile or their previous technical domain ? This is a key element when we are on the verge of transforming people’s roles.

You will also face the « I will do what my boss did ». In most organizations, the immediate superior’s behaviour will be imitated because it is human nature, mainly when « success » is involved and perceived. However, is this superior a good one ? Don’t we say that we always reach our highest level of incompetency (Peter’s principle) ?

This biomimetism in an organization is critical and difficult to change. This boss doesn’t want people to believe they made errors or to lose what they did for the last 20, 25 years. The same applies to the people that want to have this management position and follow in their mentor’s steps. Agility wants to « destroy » their last 5 years of work ? This is a sensitive situation that you must be able to identify and address to not face a strong and negative resistance to change.

Retirements

Many people that we coach are retiring or are close to. Whatever their excellence and professionalism during their career, they do not see, with some exceptions, the pros of change. They do not have an urgency to change. They are leaving.

Identify them, but do not exclude them. Mitigate the negative influence they could have. And, most importantly, use them as a way to transfer knowledge within the team. Remove them from delivering value items, so that they can be available to the team for pair programming and code reviewing for example.

What were your own blocking and human issues ?