Définition du Scrumbut
Si ce terme n’est pas encore connu en France, ce terme est pourtant très fréquent pour l’ensemble des coaches Agile qui tentent de mettre du Scrum en place. On parle de Scrumbut pour « We use Scrum, but » ; pour faire simple, le Scrum amène souvent à des problématiques fortes plus ou moins connues ; elles sont sous-estimées et peuvent mettre la mise en place du Scrum en péril.
Les classiques du Scrumbut
Vous avez déjà mis en place du Scrum ? Vous ayez fait parti d’équipes qui ont vécus la mise en place du Scrum ? Alors, vous aurez pu rapidement voir que le Scrum ne convient jamais à 100%.
Il est très fréquent que les équipes qui mettent du Scrum sans coach vivent rapidement les cas que je vais énumérer ci-dessous. En général, les coaches connaissent les pièges et tentent d’éviter ces grands classiques.
Daily Scrum trop longues
Il arrive de voir des Daily Scrum qui durent prêt de 45 minutes alors qu’on ne doit pas dépasser les 15 minutes. Cela rend la Daily Scrum souvent improductive et devient presque un soucis pour l’ensemble des équipes (voire des dirigeants qui ne la comprennent encore moins).
Certains vont proposer d’en faire plus qu’une seule par semaine… Grossière erreur bien évidement. La Daily Scrum est indispensable car elle permet une transparence et une inspection de qualité. Dès que vous voyez un dysfonctionnement, n’attendez pas pour agir.
Mais comment agir alors ? Un coach Agile rappellera au Scrum Master qu’il doit impérativement savoir dire les choses : « dites ce que vous avez fait, ce que vous allez faire aujourd’hui et les alertes éventuelles par contre ne rentrez pas dans les détails » et avec un grand sourire. Les équipes pourront sans soucis se réunir plus tard pour parler de certains détails si nécessaire, mais il ne faut pas prendre du temps sur la Daily pour faire cela. Ce n’est pas si simple à dire mais c’est indispensable de le faire pour qu’elle porte vraiment ses fruits.
Si vous avez de véritables difficultés, vous pouvez tenter de mettre en jeu un chronomètre en divisant le temps par personne. Introduire ce type de technique comme un jeu est souvent plutôt bien pris par les équipes. Il ne suffira que de quelques séances pour que les choses se remettent en ordre.
Scrumbut : les rétrospectives servent à rien
Mon dieu qu’on entend régulièrement au bout de quelques sprint dans les équipes non accompagnées. C’est vraiment un grand classique des Scrumbut que nous pouvons rencontrer. J’ai souvent vu aussi ce phénomène arriver très vite dans les équipes Scrum qui tentent d’avoir un « Scrum Master intégré » qui du coup ne prend pas le temps de gérer les rétrospectives.
La rétrospective n’est pas un simple SWOT pour définir des améliorations ; si cela intéresse les équipes lors de la première séance, ils sont désintéressés dès la deuxième car ils n’ont pas vu toutes les améliorations se mettre en place. Croyez-vous qu’il est possible en un Sprint de tout améliorer ? Bien sûr que non donc répéter ce processus une deuxième fois n’a pas de valeur aux yeux des équipes. Mais comment faire ?
La rétrospective est un véritable bijou pour les Scrum Master. Elle permet en effet d’en tirer des axes d’amélioration mais aussi d’y voir si les équipes se parlent, se comprennent, sont proches et si elles sont motivées. Il faut que le Scrum Master fasse une rétrospective différente à chaque Sprint et qu’elle ne soit pas trop conventionnelle. Certains Scrum Master dégénérés (c’est un vrai compliment) amènent parfois leur équipe à l’extérieur pour faire des ateliers originaux.
Page à lire : Nos rétrospectives
Article : L’art de la rétrospective
Si le Scrum Master n’arrive pas à rendre sa rétrospective attractive et non monotone, il faut qu’il se fasse accompagner d’un coach Agile pour bien comprendre comment les animer. La rétrospective est le meilleur moyen de prévoir les futurs soucis que peut rencontrer les équipes : démotivation, blocages éventuels… Dès que la rétrospective sera agréable et vue comme un vrai outil de mesure par les équipes, elle ne sera plus le Scrumbut des équipes.
* Pour information, je déconseille fortement un Scrum Master intégré (généralement en développeur) ; ce rôle est bien plus difficile qu’il n’y parait et le Scrum Master a besoin de 100% du temps pour faire un travail de grande qualité. A mi-temps, le Scrum Master devient quasiment inutile.
Scrumbut : les managers me rajoutent des tâches
Cette ScrumBut est également un grand classique dans les équipes Scrum en France ; elle aurait même tendance a bien énerver les équipes en place qui viennent de se lancer en Scrum pour tenter de retrouver une organisation de travail perdu depuis pas mal de temps.
Pas de panique, il existe des solutions à ce problème très connu des nouvelles équipes Scrum. Par contre, il faudra être très patient car pour enlever ces mauvaises habitudes ça prend beaucoup de temps. Le Scrum Master et le Product Owner vont devoir beaucoup travailler ensemble pour tenter d’arrêter cette pratique.
Pour ma part, j’aime beaucoup la technique du « Impediment » (perturbation) pour travailler sur ce phénomène problématique à l’avancement des projets. Cela consiste a bien mettre en avant les demandes qui n’étaient pas prévues mais que vous ne pouvez pas encore refuser pour X raisons. En général je mets un gros [IM] en rouge sur mon Post’it pour bien montrer que la demande est arrivé en cours de Sprint.
Cela n’est souvent pas suffisant pour redonner une conscience aux managers qui viennent perturber vos Sprint ; donc le Scrum Master et le Product Owner n’hésiteront pas à présenter le pourcentage de perturbation de chaque Sprint sous forme d’un Donuts (présenté lors de la Review par exemple) ; je considère que la review est faites avec les présences des clients sinon l’impact est évidement maigre.
Si cela ne suffit pas, n’hésitez pas à faire apparaître les conséquences de ces « Impediment » selon le contexte de votre entreprise sans faire dans la provocation :
- affichage du taux de perturbation sur votre board
- rappel des décalages d’éventuels plannings dus aux Impediment…
N’hésitez pas à faire appel un coach Agile qui saura vous aider à combattre ce Scrumbut ; c’est pour moi l’un des plus complexes à gérer.
Des Scrumbut moins visibles
Il existe un infini de Scrumbut mais il y a une solution pour chaque Scrumbut comme vous pouvez le deviner. Voici certains Scrumbut qui sont moins classiques mais qui posent de vrais problèmes.
Mon Scrum Master est un Chef de Projet
Parfois le rôle de Scrum Master est très mal compris ; on voit certaines personnes se définir comme Scrum Master et Chef de Projet. C’est évidement impossible car ce sont deux rôles en opposition en réalité.
Il est impératif dans ce cas de bien faire comprendre le rôle de Scrum Master à la personne et de lui faire peu à peu oublier ce rôle de Chef de Projet ; souvent, la personne a du mal à lâcher ce rôle car elle représente une sorte de pouvoir hiérarchique.
Il faut impérativement changer peu à peu cette personne en tentant de combattre les éventuelles frustrations de ce changement ; cela peut se faire en montrant les apports de ce changement ou malheureusement changer de personne si cela semble totalement impossible avec le temps. Un Scrum Master qui se veut chef de projet empêchera une équipe Scrum de fonctionner correctement.
Dans ce type d’équipe on voit d’ailleurs souvent les équipes reporter le travail au Scrum Master et non à l’équipe lors de la Daily Scrum. Il faut limite que le Scrum Master ne vienne plus à Daily quelques temps afin de changer cette habitude très révélatrice.
Un Scrum Master est un rôle très important ; il est difficile à prendre en main mais il est un élément essentiel au bon fonctionnement d’une équipe Scrum.
Des développeurs prennent de l’avance
Ça parait fou à lire comme ça mais si un développeur prend de l’avance, on se retrouve vite dans du Scrumbut. Quand le travail est terminé l’équipe doit tenter d’améliorer le travail en cours ; elle ne doit pas entreprendre de prendre de l’avance sur la suite du programme.
Dans certaines équipes, on peut rapidement se retrouver dans cette problématique ; j’ai déjà vu des Scrum Master qui refusaient de renoter une User-Story lorsqu’elle était reprise le Sprint suivant. Aucune règle n’interdit de renoter une user-story ; je vous conseille de le faire surtout si elle a bien été entamée lors le Sprint précédent. Vous reporterez la note la plus haute lors de vos différents reportings sans soucis.
Si vous renotez mais que l’équipe a en effet été plus rapide que prévue dans le Sprint, le Scrum Master doit montrer à l’équipe qu’elle peut améliorer le travail en cours ou profiter de ce temps pour mettre certains axes d’amélioration demandés précédemment par l’équipe en place (si elle a la capacité de le faire).
C’est très difficile à faire accepter mais il faut vraiment éviter de rajouter des tickets à un Sprint ; cela n’est pas si positif que ça pourrait paraître à la base. En fait, on peut y voir un surmenage du à une période de stresse intense, un travail à rallonge d’un soir… Dans ces cas précis, on ne ferait qu’empirer la situation. La stabilisation est très importante pour l’état de santé d’une équipe Scrum.
Une démo ne fonctionne pas
L’écran bleu de Microsoft est devenu légendaire dans le monde de l’informatique et on parle même d’un « effet démo ». Si cela peut faire rire une première fois, il faut se méfier de ces effets démos. en effet, lors de la mise en place du Scrum (dans les 1 an qui suivent), ces démos loupées auront des conséquences importantes aux yeux des commanditaires : « est-ce que le Scrum ne fait pas de la livraison de produits instables ? ».
Si un « effet démo » arrive une première fois, n’attendez pas pour réagir ; faites le maximum pour que la démo suivante se passe à merveille. Il faut vraiment renverser la tendance car cela peut en effet rapidement devenir un Scrumbut. Le Scrum Master et le Product Owner devront faire ce qu’il faut pour que la démo suivante fonctionne à merveille.
Je me permets de parler de ce cas car il est souvent sous-estimé et pourtant il peut être désastreux.
Pas de roadmap ou projets irréalistes
En Scrum, on oublie souvent cet aspect mais il faut de vraies roadmap. Sans roadmap, une équipe est souvent perdue et prendra ça comme le résultat du Scrum (ce qui est totalement faux) ; Cependant ce Scrumbut sera un vrai problème car ne poussera pas les équipes à se motiver.
Le Scrum permet bien évidement de faire des roadmap complète grâce à des calculs de complexités ; si le Scrum contrairement à d’autres méthodes tolérera que la roadmap puisse changer ou prendre du retard, il permet de créer des roadmap réalistes et complètes.
Le Scrum ne permet pas de faire des projets irréalistes ; donc ne tentez pas de proposer des projets que les équipes ne pourront jamais faire. Une équipe a besoin de savoir qu’elle atteindra des objectifs réalistes et qu’elle pourra être fière d’avoir atteint un but atteignable. Si vous proposez un projet irréaliste, l’équipe saura dès le début que le but à atteindre est impossible ; et les conséquences seront une productivité plutôt basse.
Une vraie roadmap et des projets réalistes sont souvent l’une des premières raisons d’obtention d’équipes sur-vitaminées par la motivation.
Sachez qu’un projet irréaliste amène souvent à la mise au placard du projet dans son intégralité. Je vous laisse imaginer la motivation des équipes ainsi que la productivité qui en découle après un tel désastre.
D’autres Scrumbut ?
Il existe d’autres Scrumbut que nous rencontrons en tant que coach agile. Je referais un article très prochainement pour vous en citer d’autres ; j’en profiterai pour vous indiquer les solutions à mettre en place.
C’est en connaissant en amont les Scrumbut les plus courants qu’on arrive souvent à les éviter. Ce que je vous accorde, c’est qu’on apprend en rencontrant les Scrumbut et qu’on ne les trouve pas si terrible quand on les évite ; mais vous en rencontrerez d’autres que vous pourrez nous partager en retour d’expérience.
2 Rétroliens / Pings