Devez-vous utiliser Scrum ? (les prérequis de Scrum)
J’ai récemment mené quelques audits et on me posait notamment la question de la pertinence de Scrum dans le contexte audité.
L’exercice m’a forcé à formaliser les prérequis de Scrum, à être capable d’expliquer et illustrer dans quel contextes Scrum est-il adapté ou non.
Dans cet article, je partage avec vous ces éléments qui permettent de déterminer si vous avez raison ou non d’utiliser Scrum !
Les prérequis d’un Scrum fluide et facile
L’excellence technique
☐ Une approche et des pratiques de développement qui mènent à la qualité intrinsèque (built-in quality), en construisant la qualité dans le produit plutôt que de la vérifier après coup.
☐ La dette technique est sous contrôle : celle existante est connue, la nouvelle est prise avec une véritable stratégie.
☐ L’équipe de développement constitue la force vive de l’équipe Scrum : ses membres prennent la parole et sont écoutés par le reste de l’organisation. Ils prennent les décisions techniques et les décisions produit ne sont pas prises sans leur accord.
L’autonomie à accomplir sa mission
☐ L’équipe est pluridisciplinaire avec toutes les compétences nécessaire pour construire le produit de bout en bout. L’équipe de développement est composée d’au moins 3 membres.
☐ On laisse l’équipe acquérir les compétences et expertises dont elle a besoin. On laisse l’équipe prendre le temps ou faire les démarches nécessaire.
☐ Les membres de l’équipe ne sont pas partagés, à temps partiel sur plusieurs équipes. Ils peuvent participer à des communautés transverses ou aider ponctuellement d’autres équipes en tant qu’expert, mais cela reste toujours secondaire à leur équipe Scrum.
La capacité à s’auto-organiser
☐ L’équipe de développement n’est pas composée de plus de 9 membres.
☐ L’équipe est stable : c’est avant tout la volonté de ses membres qui en altère la composition et non pas l’organisation. L’organisation affecte les équipes comme des éléments atomiques, plutôt que d’affecter individuellement les personnes.
☐ L’équipe est pilotée par des objectifs et non par des périmètres. Ces objectifs sont collectifs, d’équipe, et pas liés à des individus de l’équipe.
☐ Plus globalement, l’équipe évolue dans une organisation avec une culture de l’auto-organisation et du lâcher-prise.
☐ Un certain nombre des membres de l’équipe font preuve de leadership. Il y a plusieurs leaders. Ces leaders sont reconnus en tant que tel par leurs pairs dans l’équipe et non pas choisis par l’organisation.
La construction d’un produit
☐ L’équipe dispose d’une vision forte qui donne du sens et pilote le backlog produit.
☐ Les parties prenantes sont fortement impliquées. En particulier, ils sont présents aux Sprint Reviews.
☐ Le produit construit par l’équipe est en phase de développement, et non pas en phase de maintenance pure ou de support. Le support et la maintenance du produit est normale et bienvenue, mais le produit est toujours en développement continu.
☐ C’est bien l’équipe, ou du moins l’organisation, qui décide de l’avenir du produit et non pas le ou les clients. Une requête client n’est rien d’autre qu’une contribution utile aux décisions produits. Ce n’est pas le client qui décide de ce que deviendra le produit.
Pourquoi Scrum fonctionne mal ?
Au vu de ces pré-requis, les organisations essaient souvent d’appliquer Scrum dans des contextes inadaptés. Voici les cas les plus courants.
Absence d’excellence technique
L’équipe n’a pas été formée aux pratiques de développement permettant l’agilité, ou les moyens nécessaires à sa formation continue lui sont refusés — en particulier en termes de temps et de liberté.
D’une manière générale, l’organisation n’accorde pas l’importance nécessaire à l’excellence technique. Les choix techniques sont peut-être remis en question par des personnes qui sont pourtant moins compétentes, ou du moins plus éloignées du travail à faire. Souvent aussi, la pression est mise sur les équipes pour qu’elles délivrent plus et plus vite ; la qualité n’est pas importante.
Lorsque cela arrive, le résultat peut être catastrophique. Essayer d’être agile, en changeant la direction du produit toutes les quelques semaines, fait généralement empirer la situation si les pratiques de développement ne permettent pas de gérer ces changements facilement et sans risque au quotidien.
Sans excellence technique, l’agilité fait plus de mal que de bien.
Structure en pôles de compétences plutôt qu’en équipes stables
Les membres d’équipe sont des ressources, qu’on change d’équipe en fonction des besoins projets. Les équipes ne sont pas stables.
Souvent aussi, certaines personnes sont partagées entre plusieurs équipes.
On voit également une difficulté à laisser les personnes apprendre les compétences qui leurs manquent, puisqu’on préfère assigner la personne idéale sur tous les projets en même temps, plutôt que de faire monter en compétence les équipes qui manquent de la compétence donnée.
Dans ce type d’environnement, la plupart des éléments de Scrum vont être flottants : les estimations, les planifications, les objectifs, la dynamique d’équipe… Le résultat pourra difficilement être qualifié de Scrum.
Lâcher-prise difficile
Les directeurs, les managers, ou les autres départements (marketing par exemple) ont un pouvoir de décision centralisé dans l’organisation, et il n’est pas naturel pour eux de le partager. Il peut être question de décisions produit, ou de décider de l’organisation des équipes.
Sans surprise, dans ce type d’environnement, l’auto-organisation est difficile voire impossible à mettre en place.
Le résultat ne peut, au mieux, qu’être un Scrum de façade où les éléments du framework sont appliqués de manière mécanique.
Approche produit pilotée par le client
Le produit est piloté par les demandes clients. Quelle qu’en soit la raison, ce n’est pas réellement l’entreprise qui décide de l’avenir du produit mais les clients.
Voici une autre manière de voir la situation : le client n’achète pas le produit mais le temps des membres de l’équipe. Soit directement et contractuellement, soit indirectement en dictant le contenu du produit.
Il est important de réaliser que cette situation, si elle n’est pas intrinsèquement problématique, va par contre entrer en conflit avec Scrum : Scrum n’est pas prévu pour ce type de projet.
En pratique, une équipe Scrum dans cette situation va rencontrer beaucoup de difficultés à définir ses objectifs d’itération, le sens produit du backlog produit sera compliqué à structurer, et en cascade c’est tout le sens du travail de l’équipe qui devient flou. Quant au rôle de Product Owner, il devient dans ces conditions inutile ou inefficace. Pire encore, le Product Owner pourrait alors se comporter en chef de projet ou en manager et vouloir dicter à l’équipe de développement comment faire son travail.
Aussi, en l’absence d’un véritable focus produit, les indicateurs se rabattent généralement sur des mesures de productivité plutôt que de mesurer la valeur crée pour le client ou pour le business.
En général ce type de situation mène là aussi à un Scrum de façade. On va retrouver la nomenclature de Scrum mais pas les dynamiques d’équipe.
Devez-vous utiliser Scrum ?
Si ces prérequis ne sont pas satisfaits, ou que vous êtes dans une des situations que je viens de décrire où Scrum fonctionne mal, vous faites face à un choix :
Faut-il abandonner Scrum ou créer un environnement favorable ?
Il n’y a pas de réponse absolue. La bonne réponse est directement liée à la vision de l’avenir de votre entreprise :
- Ces éléments de contexte sont normaux, intrinsèquement liés à votre domaine, ou vous avez décidé de ne pas les changer. Il faut apprendre à vivre avec et probablement abandonner Scrum.
- Ou alors, au contraire, vous voulez faire bouger la situation. Dans ce cas l’application de Scrum va permettre de vous guider en pointant du doigt les manquements.
Scrum en tant que baromètre agile
La plupart des prérequis de Scrum listés ci-dessus sont des bonnes idées quoi qu’il arrive, Scrum ou pas Scrum :
- L’excellence technique n’est pas vraiment négociable, quel que soit le contexte.
- L’autonomie à accomplir sa mission d’une équipe est un de ses meilleurs leviers de performance. Contrairement à ce que dit notre intuition, l’essentiel du temps n’est pas perdu à travailler sur les sujets pointus demandant une forte expertise, mais en communication, en interactions et en passage de bâton. Le modèle d’une équipe apte à prendre en charge une mission de bout en bout prend le contre-pied de cette intuition et permet de réduire significativement les délais de production de valeur. Cela n’est pas spécifique à Scrum.
- La capacité à s’auto-organiser est un fort levier de création de valeur. Ainsi, la décentralisation des décisions est au cœur du Product Management et plus globalement dans les méthodes agiles. C’est aussi en s’auto-organisant qu’une équipe découvre et conçoit les manières les plus efficaces de travailler. C’est également le meilleur moyen de permettre à chacun de plus s’épanouir. Là encore, ces gains ne sont pas spécifiques à Scrum.
- La construction d’un produit permet de se focaliser sur ce qui compte vraiment, et de donner beaucoup de sens au travail, et donc de permettre aux équipes de s’épanouir tout en générant plus de valeur. Encore une fois, ce point n’est pas spécifique à Scrum.
Notons tout de même que ce dernier point, sur la construction d’un produit, est le plus contextuel de tous. Dit autrement :
- Il n’y a pas vraiment de raison à ne pas viser l’excellence technique, l’autonomie à accomplie sa mission et la capacité à s’auto-organiser
- Par contre, il y a de très bonnes raisons à préférer la construction d’un produit mais cela n’est pas toujours possible
Sauf si vous êtes dans le cas de figure où il n’est pas pertinent d’opter pour la construction d’un produit, vous avez tout à gagner à mettre en place les prérequis de Scrum. Et cela, que vous appliquiez Scrum ou non.
Cependant, Scrum pourrait être votre meilleur atout pour vous aider à mettre en place cet environnement favorable.
Utilisez Scrum comme un baromètre : si c’est compliqué, difficile, douloureux ou pas épanouissant, alors c’est qu’il reste du travail à faire sur cet environnement.
Utilisez Scrum dans votre stratégie de transformation, comme un outil qui va révéler les problèmes et forcer à améliorer l’environnement.
L’alternative à Scrum : Kanban
L’autre option est de simplement considérer que cela ne correspond pas à votre contexte.
Soit, comme évoqué plus haut, vous n’êtes pas dans un contexte propice à la construction d’un produit.
Ou alors, tout simplement, vous considérez qu’il est trop difficile ou coûteux de mettre en place l’environnement favorable. Ce n’est pas en soi un mauvais choix dès lors qu’il est assumé et fait en pleine conscience.
Dans tous les cas, une bonne alternative à Scrum est Kanban, qui est beaucoup plus léger et flexible que Scrum.
Là où Scrum va s’effondrer en l’absence d’une approche produit, Kanban va trouver d’autres leviers pour fluidifier le fonctionnement de l’équipe. Là où Scrum va s’effondrer en l’absence d’une équipe stable et autonome, Kanban va aider à cadrer les rôles et responsabilités de chacun, tout en forçant à l’amélioration continue du système si cela ne suffit pas.
Besoin d’aide pour juger de la pertinence de Scrum dans votre organisation ?
N’hésitez pas à me solliciter si vous aimeriez appliquer ce type de canevas à votre équipe ou à votre organisation, ou pour réfléchir à comment améliorer son fonctionnement. Ce sera un plaisir de vous aider !
✉️ E-mail : contact@jp-lambert.net
Si vous êtes curieux de savoir à quoi ressemblent les rapports d’audit que je mène, je peux aussi partager des versions anonymisées. Ecrivez-moi !
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma future newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.
À bientôt 😊
