Définition du Scrumbut v2
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 qui sous-estimées peuvent mettre la mise en place du Scrum en péril.
Nous avions déjà fait un article complet sur ce sujet l’année dernière. Je vous propose alors une nouvelle série de Scrumbut que j’ai pu rencontrer sur l’année 2017 qui pourrait bien vous servir.
Pour commencer, je peux vous proposer d’aller revoir l’article de l’année dernière sur ce sujet : Le Scrumbut est un combat continuel
Des Daily du Command & Control
Dure vie pour les Daily Scrum car il est vrai qu’elle peut vivre de nombreuses difficultés au sein de nos structures. Mais qu’est-ce qu’une Daily du Command & Control ?
Certains Product Owner (PO) se pensant être les grands patrons de l’équipe ce qui est une véritable erreur, va exiger de chaque personne, un compte rendu de ce qui a été réalisé ; ceux-ci n’hésiteront pas d’ailleurs à questionner chaque membre avec de nombreuses questions inutiles en Daily. La Daily Scrum devient alors une séance de Commande & Control.
On peut même voir ce PO dire des choses telles que : « ok, mais on est d’accord que tu auras plié ça dans la journée hein »… Ce type de comportement doit impérativement disparaitre de cette Daily Scrum.
Pour rappel, la Daily Scrum n’est pas un moment de reporting pour le Product Owner ; il n’a pas à intervenir sauf peut être exceptionnellement en cas de besoin d’annoncer une urgence éventuelle (certains contextes l’imposent malheureusement).
Le Product Owner n’est pas le patron de l’équipe mais le responsable fonctionnel uniquement. N’hésitez pas à lui rappeler cela si ce Scrumbut vous arrivait. Parfois dans certains cas, il faut même lui demander de ne plus participer à la Daily Scrum car sa présence n’est en aucun cas obligatoire.
Voici deux articles importants sur lesquels vous pouvez vous fier si besoin de sources fiables :
Que fait un Product Owner de ses journées ?
Faire une bonne Daily Scrum
Le Scrum Master à 50% par équipe
J’ai vu cette pratique se faire mais je l’ai pas trouvée efficace bien au contraire. Dans les structures qui veulent se transformer, on s’aperçoit vite qu’il est indispensable d’avoir un vrai Scrum Master à temps plein.
Le fait de le partager dans des équipes rarement colocaliser dans le même openspace lui rend la tâche très compliquée ; il n’est plus présent à 100% pour observer le bon fonctionnement de l’équipe. Pire encore, on peut souvent lui demander de réaliser d’autres choses transverses pour la structure ce qui fait qu’il est rapidement débordé.
J’ai vu d’excellents Scrum Master totalement perdre le fil en gérant deux équipes tout en s’ajoutant d’autres sujets transverses ; cela se répercute directement sur les équipes qui peuvent si elles ne sont pas très matures, totalement se perdre en cours de route.
Je ne peux que conseiller de bien s’assurer que l’équipe n’ait pas besoin d’un Scrum Master à temps plein mais cela selon mes expériences de 2017 ne représenterait que 2% des équipes Scrum. Demandez conseil auprès d’un coach agile qui saura mieux vous aiguiller sur les choix à prendre. En général, on conseille de mettre un Scrum Master à temps plein.
On ne montre pas le produit au client, c’est stratégique…
C’est malheureux mais j’entends encore des discours politiques autour des produits : « c’est la politique de la boite, on fait le projet en scrum et on le fera tester quand il sera intégralement terminé ». Il n’y a aucun intérêt à cacher un produit à vos utilisateurs clés et bien au contraire cela va à l’encontre d’un produit créé avec des méthodes agiles.
Pour aller même plus loin, on ne parle plus de gestion de projet mais plutôt de gestion de produit… La différence peut paraître minime au premier abord mais cela rappellera régulièrement qu’on se focalise sur le produit et non sur le projet pour créer notre produit avec les méthodes agiles.
Le fait de faire des petites itérations a pour but justement de le tester souvent et rapidement. Faire tester le produit permet de s’assurer que nous allons dans la bonne direction ou de rectifier celui-ci si le besoin s’en fait ressentir. Il ne faut donc surtout pas exclure nos utilisateurs clés sous prétexte que c’est politiquement pas possible.
Sachez que mettre du Scrum doit également amener à une transformation des mentalités. Mettre du Scrum histoire de mettre du Scrum dans des entreprises habituées au waterfall voire cycle en V sans même penser à amener une culture agile n’a aucune chance de fonctionner correctement. Amenez l’ensemble des acteurs autour du produit à comprendre la nouvelle culture qui se met en place pour ne plus à avoir à entendre : « politiquement on ne peut pas se permettre ».
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.
Le Product Owner absent ou peu présent
Ce Scrumbut est tellement classique dans les grands groupes que de nombreuses personnes pensent que ce concept d’externaliser le Product Owner est normal. C’est bien évidement faux, le Product Owner doit être un membre à part entière de l’équipe.
On peut même voir des personnes dites « Product Owner » (PO) qui vont seulement dire ce qu’elles veulent à des Proxy Product Owner qui vont faire tout le boulot autour du produit ; ce dernier devra juste respecter la priorisation du dit PO.
Remettons les bons mots sur les bons rôles et dans ce cas le Proxy PO est en fait le PO et le PO est en fait un stakeholder (partie prenante).
Si vous êtes dans le cas de ce type de Product Owner sans avoir de Proxy PO, je vous conseille fortement de vous trouver un bon Proxy Product Owner sinon le projet rencontrera de nombreux obstacles.
On doit gérer toutes les urgences tout le temps
Cette situation est très complexe car elle empêche toute organisation de se mettre en place. Quand les équipes ne veulent pas arrêter de traiter tout le temps les urgences, le coach agile ne pourra jamais mettre un Scrum de qualité.
Il est très difficile de l’accepter pour ce type d’équipe, mais arrêter de traiter toutes les urgences qui prennent 80% du temps des équipes IT permettra enfin de structurer le travail. Si ces équipes ne font pas l’effort de changer et continue de prendre toutes les soit disant urgences en compte, aucun nouveau projet ne pourra se mettre en place… Plus grave encore, les urgences sont souvent faites rapidement ce qui augmente constamment le legacy de l’équipe.
Si vous voulez faire un Scrum de qualité, acceptez de changer et de ne plus traiter toutes les urgences (pas si urgentes) ; pour cela, l’équipe devra accepter un nouveau processus de priorisation qui amènera peu à peu l’équipe sur la voix de livraisons de meilleures qualités.
Conclusion Scrumbut V2
Comme vous le voyez, il existe de nombreux Scrumbut dont certains que je n’ai pas cité ici ; cela viendra sûrement dans un prochain article. N’hésitez pas à me partager vos Scrumbut afin qu’on les partage avec l’ensemble des lecteurs de ce blog.
Soyez le premier à commenter