Pour toutes les équipes qui ont choisi Scrum comme base méthodologique (et elles sont très nombreuses), il arrive forcément un moment où ce cadre est mis à mal. Le monde bouge, il est impossible de vivre dans un état stable durablement. En tous cas, ce n’est pas ce que j’observe dans mes accompagnements.
Je constate parfois que certaines équipes se retrouvent “coincées” dans une façon de travailler qui ne leur correspond pas, malgré leur volonté initiale de suivre Scrum.
Nous n’avons pas encore d’études qui montrent les impacts (positifs et négatifs) des adaptations de Scrum sur la qualité des produits et le bien-être des équipiers. En attendant qu’elles soient produites un jour, je partage dans cet article trois éléments de contexte qui mettront à mal votre Scrum (tôt ou tard), même si vous êtes très matures sur ce framework agile.
1. L’instabilité des demandes
Être agile ne signifie-t-il pas, entre autres, être capable de s’adapter ? Oui… mais en Scrum, attention ! Pour être plus précis, il faut examiner de quel type d’instabilité il s’agit.
Je ne parle pas de l’instabilité naturelle des demandes, celles qui proviennent des utilisateurs, des clients internes ou même de l’équipe elle-même. Une équipe qui fonctionne en Scrum a bien sûr son Product Owner qui recueille ces demandes, les organise dans le backlog et les planifie pour la prochaine itération, n’est-ce pas ? Dans de nombreux contextes organisationnels, le flux de demandes en entrée n’est pas anticipable ni prévisible, et c’est tout à fait normal et logique.
Scrum est conçu pour avoir des itérations qui répondent à un objectif et qui se déclinent en un certain nombre d’éléments. L’enjeu du sprint planning est de garantir une stabilité pendant la période de l’itération à venir. Cependant, toutes les variations qui apparaîtront en cours d’itération sont autant de risques de mettre à mal le concept même d’itération Scrum.
Beaucoup d’équipes s’interrogent sur la gestion des bugs en cours d’itération, notamment celles qui ont des produits en production avec des utilisateurs. Il paraît fou de répondre à une urgence par “Désolé, nous sommes en Scrum, votre demande sera planifiée au mieux à la prochaine itération dans 2 semaines”. Il y en a qui ont essayé… et qui ont eu des problèmes 🙂
Cependant, cela ne signifie pas que Scrum ne peut pas gérer les urgences et les variations de demandes en cours d’itération. La stratégie simple est de prévoir un peu de marge dans l’itération. Si votre équipe commence à planifier “ce mou” en cours de planning d’itération, restez vigilant. Si cette proportion augmente, vous êtes simplement en train de planifier l’incertitude. Dans ce cas, à quoi vous servent les itérations ? Nous venons de tomber sur un paradoxe.
Ces équipes gagneraient à faire évoluer leur référentiel méthodologique vers une approche plus agile, comme par exemple Kanban.
2. La variabilité des effectifs
C’est un phénomène facile à observer dans les sociétés de services (ESN) ainsi que dans les organisations en pleine croissance. Le principe est simple : les équipes sont composées de membres qui ne sont pas disponibles à 100 % de leur temps. Si vous avez déjà suivi une bonne formation Scrum, vous savez que la méthode préfère les personnes dédiées pour fonctionner efficacement.
Cependant, ce n’est pas le cas chez vous. Pour y parvenir, il faudrait déplacer des montagnes : transférer l’expertise sur plusieurs personnes, recruter, convaincre la direction et les ressources humaines, revoir l’organigramme, etc. Face à ces défis, il est facile de se décourager. Pour certaines équipes utilisant Scrum, la contrainte d’avoir des membres qui vont et viennent au gré de leur agenda reste donc présente.
Mettez-vous à la place de ces personnes multitâches. Scrum devient alors une méthode extrêmement lourde : réunion quotidienne (tous les jours, c’est le principe), planification, démonstration (ou plutôt revue), rétrospective. Si ces personnes sont également rattachées à des entités hiérarchiques différentes, le sentiment d’appartenance à l’équipe sera faible, voire inexistant.
J’observe également ce phénomène pour les profils plus experts. Ils sont précieux dans une organisation et ont pour vocation de partager leur expertise avec les équipes dans le meilleur des cas. Cependant, en étant multitâches, ils deviennent également des dépendances. Sans eux, le travail avance plus lentement.
Scrum s’appuie sur des rôles qui sont censés fonctionner ensemble et qui se retrouvent lors des rituels. L’un des prérequis de Scrum est donc de travailler à partir d’une équipe. Sans ces rencontres partagées, la notion d’équipe s’effrite et les avantages de choisir une telle méthode disparaissent.
Si l’organisation accepte que les membres multitâches entraînent une perte de performance pour les personnes, alors Scrum sera moins efficace mais au moins vous serez serein. À l’inverse, il faudra peut-être abandonner Scrum, car ce type de dispositif agile ne permet pas d’atteindre la performance souhaitée.
3. Les fortes dépendances
C’est sans doute le phénomène le plus naturel et celui qui génère le plus d’émotions fortes. Prenons un exemple : l’équipe A est dépendante du travail de l’équipe B. Souvent, cela se traduit par l’équipe A étant bloquée par l’équipe B. Imaginons que l’équipe A a choisi de fonctionner en Scrum, mais pas l’équipe B. Les rythmes des deux équipes sont donc désynchronisés.
Pendant la planification d’itération, l’équipe A, qui fonctionne en Scrum, va imaginer le travail qu’elle peut réaliser sur l’itération à venir et elle pourra peut-être même planifier la dépendance à l’équipe B. Le problème de dépendance ne sera visible que si l’équipe B ne fournit pas le travail attendu par l’équipe A au bon moment, ce qui arrive assez souvent, n’est-ce pas ? L’équipe A va donc :
- Attendre l’équipe B. Plus elle attend, plus la frustration de ne pas être satisfaite grandit
- Ne pas terminer une partie du travail qui était prévue pour l’itération.
- Reporter la responsabilité du retard sur l’équipe B.
- Perdre en capacité de planification, car l’équipe A ne maîtrise pas les délais de l’équipe B.
Tous les plannings poker, les calculs de vélocité ou les mesures par les burndowns ne changeront rien. La dépendance sera toujours plus forte que les outils.
Une solution simpliste serait d’affirmer qu’il faut supprimer les dépendances. Cette injonction, quoi qu’intéressante intellectuellement, ne trouvera pas d’écho à court terme dans la plupart des cas.
À nouveau, tout est question de mesure. Si votre équipe est bloquée ponctuellement par une dépendance externe, vous pourrez sans doute surmonter ce moment. Si les dépendances sont systématiques et ont des impacts négatifs sur les relations inter-équipes ou inter-services, c’est peut-être qu’il y a un aspect de votre équipe Scrum qui vous manque : la pluridisciplinarité.
En synthèse
J’aime Scrum et je continuerai à promouvoir cette méthode qui brille par sa simplicité de construction. Toutefois, pour bénéficier de tous les avantages d’un tel modèle, il est important de prendre conscience de l’état actuel de votre organisation.
S’orienter vers Scrum se construit pas à pas, jour après jour, avec tous les acteurs de l’équipe et ceux qui l’entourent. Un bon accompagnement au changement, qu’il soit mené par votre Scrum Master ou par un coach agile, doit s’adapter à la réalité humaine et opérationnelle.
Parfois, les contraintes sont trop fortes et il est plus intéressant pour l’équipe de ne pas adopter Scrum. Ce n’est pas un aveu d’impuissance, c’est plutôt à mon avis le premier signe de maturité d’une équipe.
