Conduire le changement

Introduction

Contrairement à Kanban, Scrum est une approche prescriptive qui impose formellement des règles, des rôles et des artefacts. Certes, Scrum impose beaucoup moins de processus que PRINCE2 ou SAFe, mais ces changements, même peu nombreux, impliquent une transformation profonde de l’organisation des entreprises.

Il y a donc des rôles, des évènements et des processus à créer, supprimer et à modifier et le Scrum Master doit provoquer ces changements.

Plutôt que de délivrer une méthode, une succession de processus à appliquer dans une grande majorité des cas, ce chapitre invite à comprendre les bases de la conduite du changement, les motivations et les freins au changement.

Pour induire efficacement un changement, il faut au préalable comprendre pourquoi un individu effectue une action précise ou applique un processus particulier :

Il n’existe aucune autre raison qui ne tirerait sa cause d’un de ces trois énoncés.

Il n’y a donc qu’un seul moyen efficace de provoquer un changement durable : trouver quel est l’intérêt personnel que peut avoir un interlocuteur à adopter un nouveau processus. Plus le processus antérieur est ancré...

Les relations hiérarchiques

Excepté l’anarchisme, toute organisation sociale a tendance à ordonner ses interactions et ses relations de manière hiérarchisée et souvent pyramidale, on parle de structures sociales. La résilience de ces structures en strates étant très forte, les changements sont souvent empreints d’une forme de brutalité : une révolution.

Comme toute organisation sociale, une entreprise est composée de strates hiérarchisées entre lesquelles se tissent des liens de subordinations.

Avec Scrum, il n’y a aucun lien de subordination entre les membres de l’équipe Scrum, mais chaque membre de l’équipe a un lien de subordination avec un manager dans l’organisation. Au chapitre Le management participatif, nous avons abordé les phénomènes de pression et de contrôle existant et ceux vers lesquels il est préférable que l’organisation s’oriente. Il peut être utile de le relire avant de poursuivre ce chapitre.

Lorsque les relations hiérarchiques reposent naturellement sur un esprit de collaboration, les managers appliquent déjà un style de management participatif. La collaboration avec leurs subalternes est basée principalement sur un rapport de confiance, de respect et s’oriente parfois plus vers une relation amicale que réellement hiérarchique. Dans ce contexte, il n’y a parfois aucun changement à provoquer.

À l’opposé, lorsque les relations hiérarchiques reposent sur un triangle dramatique ou triangle de Karpman - victime, persécuteur, sauveur...

La constitution et le management des équipes

Dans la plupart des cas, le management doit constituer une équipe (Essential Scrum, Kenneth S. Rubin, chapitre 13, pages 227-228 Fashioning Teams) par rapport à des enjeux de délais non négociables. Il faut que des ressources soient disponibles maintenant et pour une durée approximativement déterminée. Qui plus est, il faut que ces ressources disposent de certaines compétences techniques particulières : un savoir-faire. Parfois, ce travail est effectué en urgence, car un « chef » a décidé que le projet devait commencer immédiatement. Il n’y a alors ni objectifs clairement identifiés, ni vision ou stratégie, et très peu de partage d’informations.

En l’absence de transparence, l’inspection est difficile, et l’adaptation sera fortement réduite. En l’absence d’une vision projet, la sélection des membres de l’équipe est difficile et la performance de l’équipe sera fortement réduite.

Cette absence de transparence initiale amène le management à constituer des équipes qui ne pourront pas être autonomes. Il manquera toujours une ressource. Les membres de l’équipe changeront régulièrement. La performance globale de l’équipe sera fortement réduite. Le management prend rarement conscience qu’il a lui-même créé les conditions propices à l’échec.

Faire prendre conscience de ces aspects aux managers est parfois long et le Scrum Master y parviendra plus efficacement en s’appuyant sur des faits mesurés de manière empirique, plutôt qu’en s’appuyant sur « c’est écrit dans le guide Scrum ».

Il est indispensable que tous les acteurs partagent une vision commune des enjeux du projet, de son périmètre réel, des objectifs qu’il doit atteindre et des contraintes existantes. Sur cette base, le management peut effectuer des arbitrages plus efficaces. Peut-être est-il préférable de reporter de quelques semaines la date de lancement d’un produit afin de pouvoir disposer de ressources disposant de savoir-faire plus appropriés à la nature de celui-ci...

La vision du produit

De nombreux Scrum Masters considèrent que la vision du produit est portée par le Product Owner et lui seul et toute l’organisation doit respecter les décisions du Product Owner.

Il ne faut pas prendre cette déclaration du guide Scrum comme un ordre, mais plutôt comme une invitation à collaborer. Ce n’est que lorsque le Product Owner et les décideurs de l’organisation définissent ensemble la vision du produit, ou bien lorsque la vision du Product Owner est alignée sur celle de l’exécutif, qu’il est possible de respecter cette directive du guide Scrum.

Le Product Owner peut prendre des décisions opérationnelles en toute autonomie et elles seront respectées seulement si sa vision du produit est largement partagée par les décideurs de l’organisation. Tant qu’il n’y a pas un réel partage de la vision du produit, il existera des conflits. Là encore, c’est un problème de transparence, sur la vision produit.

D’ailleurs, la phrase qui suit cet extrait du guide Scrum invite le Scrum Master à travailler avec le Product Owner, l’équipe de développement et les autres parties impliquées afin de déterminer si les artefacts sont complètement transparents.

Le pipeline de production

Un pipeline de production désigne historiquement tous les logiciels et toutes les solutions que l’équipe de développement utilise pour transformer les éléments de son Backlog de Sprint en un incrément fini. Il s’agit en général de l’environnement de développement intégré (EDI), des solutions de contrôle de source, du logiciel d’intégration, des outils de test, etc.

Changer ces outils implique bien sûr l’équipe de développement, mais également des managers, car même lorsque l’organisation est particulièrement agile, il est difficile d’imaginer que chaque équipe puisse librement choisir son EDI.

Là encore, l’empirisme est le meilleur allié du Scrum Master pour aider l’équipe à améliorer ses conditions de travail. Aller voir un manager pour lui demander l’autorisation de déployer un nouveau logiciel dans l’organisation parce que ça fait plaisir aux développeurs repose exclusivement sur un rapport affectif. Aller voir un manager en lui démontrant que sur 140 points de vélocité par Sprint, l’équipe a identifié qu’il existe 20 points correspondant à des tâches récurrentes à faible valeur ajoutée qui pourraient être...

Établir une stratégie

Souvenez-vous que pour aider l’organisation à mieux adopter Scrum, vous utilisez les mêmes pratiques que le Product Owner. Vous devez donc identifier des objectifs et avoir une vision.

Posez-vous la question suivante : « Pourquoi cette organisation cherche à adopter Scrum ? ». Pourquoi pas Kanban ou SAFe ? Quel objectif l’organisation cherche-t-elle à atteindre ? Si vos actions vont à l’encontre de cet objectif, quelle que soit leur pertinence, elles seront vouées à l’échec.

Si vous ignorez les raisons réelles ayant conduit les dirigeants de l’entreprise ou du service à s’orienter vers Scrum, alors :

Lorsque la notion de valeur est acquise comme une donnée fiable, alors il est possible de communiquer plus efficacement et de poser des jalons sur votre stratégie. Mais surtout, vous pouvez commencer par mesurer ! Une fois que la notion de valeur pour l’entreprise est claire...

Procéder pas à pas

À l’instar du Product Owner, le Scrum Master doit rechercher ce qui apportera le plus de valeur, pas pour le produit, mais pour l’équipe Scrum et pour l’organisation.

Toutes les entreprises sont régies par la même règle très simple : s’il n’y a pas de résultat, il n’y aura plus d’investissements. Cette règle s’applique d’un point de vue financier, mais vaut aussi pour les efforts, l’implication, le temps passé.

Idéalement, le Scrum Master devrait disposer d’indicateurs de performance, admis comme fiables et représentatifs par la majorité des parties prenantes, dès le début de sa mission. Si ce n’est pas le cas, alors il faut les créer le plus rapidement possible et s’assurer qu’ils fassent consensus. Ce n’est qu’à partir de ces indicateurs que le Scrum Master pourra inspecter et adapter sa planification du déploiement de Scrum.

À partir d’une mesure initiale, le Scrum Master peut proposer des adaptations en fonction de son travail d’inspection et en se focalisant en priorité sur les éléments qui peuvent accroître significativement ses indicateurs de performance. Si l’entreprise souhaite accélérer les délais de mise sur le marché de ses produits...