Quand je me promène sur le web, que je lis les articles, les nouvelles, les réflexions des uns et des autres sur l’Agilité, je pourrais en arriver bien vite à m’imaginer qu’il s’agit d’un monde merveilleux où tout est beau et tout le monde est gentil. Après tout, Agilité rime quasiment toujours avec “Bienveillance”, probablement le mot le plus galvaudé de cette dernière décennie.
N’importe quel Coach Agile ou Scrum Master se rendra vite compte que pour autant, les gens ne sont pas toujours “faciles”. Ce sont des humains après tout et en tant que tels ils développent parfois des marottes et des obsessions qui peuvent rendre le plus simple exercice de Scrum délicat.
Une expérience vécue
Par exemple, une des équipes Scrum décide de ne pas estimer pendant le Sprint Planning. Leur choix semble arbitraire et vous avez beau coacher, questionner, sonder, interroger, essayer de comprendre, remettre en perspective, expliquer les bénéfices et inconvénients, rien n’y fait. Ça les emmerde profondément, ils n’y voient aucun intérêt. Et là comme vous avez lu le dernier Guide Scrum qui rend les estimations optionnelles et que vous êtes fan du mouvement “No Estimates”, vous me dites : Et alors ? En quoi est-ce un problème ?
Et je vous répondrais volontiers que ça n’en est pas un, sauf que dans le cas présent :
- Certains tickets sont estimés et d’autres pas, pour un même Sprint, ce qui dénote un certain chaos dans le processus de Sprint Planning et un manque de cohérence dans les idées des équipiers. C’est aussi un point que le Scrum Master devrait éclaircir avec eux (estimer ou ne pas estimer ?)
- Le management ne rêve que de graphiques et de projections basées sur la vélocité (une terrible erreur, mais ce n’est pas le propos ici). Les vieilles habitudes ont la vie dure et l’Agilité n’est pas encore bien comprise. Pour eux, laisser des trous dans les estimations c’est comme renverser du goudron sur leur boule de cristal. Ça les perturbe beaucoup.
Une solution
Le coaching des uns et des autres, les appels à la transparence, etc. ne peuvent parfois pas tout résoudre, ou en tout cas pas dans un temps suffisamment court…Coachs Agiles et Scrum Masters ne sont après tout pas des magiciens…Comment donc apaiser les tensions et satisfaire tout ce monde là ? Une solution s’impose : l’atelier Extreme Quotation. Pourquoi ? En substance, vous allez faire d’une pierre trois coups :
- Vous allez réaliser toutes les estimations nécessaires en un temps record. Vous allez couvrir un, deux, trois Sprints ou plus. Libérés de ce qu’ils considèrent comme une corvée, vos développeurs vont pleurer des larmes de bonheur, c’est certain.
- Le ou les managers vont pouvoir arrêter les tranquillisants. Ils auront enfin leurs précieux chiffres pour se rassurer.
- Vous allez secouer/réveiller un peu l’équipe l’espace de quelques minutes (moins d’une heure) car l’exercice est rapide et très dynamique.
Evidemment, nul besoin d’être dans cette situation pour recourir à l’Extrême Quotation, c’est un exemple de contexte. L’atelier est utile dans de nombreux cas, sachant qu’il permet une économie de temps considérable. Du temps gagné, pendant lequel les développeurs sont alors occupés à faire ce pour quoi ils ont été embauchés au départ : développer, trouver des solutions, résoudre des bugs, tester, etc.
Comment se passe l’atelier, en pratique ?
Comme tout atelier, l’Extreme Quotation se prépare. Vous trouverez de nombreuses explications sur le web, la plupart prenant pour exemple un cadre physique : l’atelier se fait dans une salle. Pour ma part je l’ai réalisé en visioconférence, et nous avons utilisé l’outil StoriesOnBoard (sur les conseils du Product Owner), bien adapté pour ce type de travail.
Préparation
Lors de la première étape, vous allez demander à votre Product Owner de préparer toutes les stories/tickets que vous souhaitez estimer (l’idée est que ça peut monter jusqu’à 100 stories mais à vous de voir, ça peut être plus ou moins). Il faut les trier, et leur adjoindre une description basique si ce n’était pas déjà fait. Idéalement, vous pouvez même aider votre PO à faire ça lors d’une session d’affinage du backlog.
Dans l’application, vous allez également préparer autant de colonnes vides que nécessaire. Chacune correspond à une estimation. Si vous utilisez la suite de Fibonacci pour estimer, ça vous donnera les colonnes 1,2,3,5,8,13 ou plus selon vos habitudes. Si vous faites partie des originaux qui utilisent des tailles de t-shirt c’est pareil (mais ça ne plaira pas à votre manager).
Astuce 1 : prévoyez une colonne “?” pour les tickets qui vous laisseront perplexes.
Astuce 2 : prévoyez deux “stories étalons”. Une qui vaut 1 ou 2 et une story qui vaut 13. Histoire de rafraîchir la mémoire de tous sur ce qui constitue un développement complexe et ce qui n’en est pas un.
Règles
Vous donnez ensuite rendez-vous à votre équipe, vous vérifiez que toutes les webcams sont allumées, que tout le monde est bien coiffé et de bonne humeur, et vous expliquez les règles en 5 minutes maximum :
Les développeurs auront un maximum de 10 minutes pour positionner chaque ticket dans la colonne qu’ils estimeront être la bonne, en fonction de la complexité de la tâche (et non du temps, les règles du Planning Poker s’appliquent toujours). Ils vont devoir comparer chaque ticket.
Lors de ce premier tour d’estimations :
- Le Product Owner et le Scrum Master n’estiment pas (sauf s’ils jouent aussi un rôle technique bien-sûr)
- Si vous avez des doutes, placez le ticket dans la colonne supérieure (5 ou 8 ? vous choisirez 8).
- Si vous n’arrivez pas à estimer une story, placez la dans la colonne “?”. Mais ça doit rester un dernier recours, limitez la à 3 tickets. Trop de stories dans cette colonne révèlent un problème de clarté ou de découpage…
- Le silence est de mise c’est la priorité. Le Product Owner peut malgré tout répondre aux questions, s’il y en a, de la manière la plus consise possible. C’est pour cela que la description de chaque story est brève. Qui plus est, vous êtes chronométrés.
- Ne réflechissez pas trop, le processus doit être dynamique et spontané, presque instinctif.
- Les histoires vont bouger d’une colonne à une autre. Les uns déplaceront peut-être le ticket des autres pendant le tour, c’est sans importance. Cela fera l’objet d’une discussion ultérieure si besoin.
Présentation
Le Product Owner passe rapidement en revue les différentes stories dans un temps maximum de 15 minutes. A lui de voir s’il souhaite passer en revue l’ensemble des tickets ou plutôt présenter ceux qui méritent selon lui une attention particulière.
Premier tour
Lancez le premier tour et attendez que les tickets se stabilisent. En ce qui me concerne, les tickets ont arrêté de bouger bien avant la fin du temps réglementaire, pourtant déjà court.
Second tour – Discussions – Ajustements
Ceci fait, il est temps de poser des questions et de déclencher des discussions. Vous avez le choix :
- soit vous questionnez et laissez les développeurs ajuster leurs estimations dans la foulée,
- soit vous discutez avant de lancer un nouveau tour de “jeu” pour réviser la position des tickets.
Dans mon cas c’est la première option qui s’est imposée naturellement.
Pendant cette phase, facilitez :
- Chacun a-t-il vérifié toutes les stories ?
- Sur quels tickets êtes-vous encore en désaccord ?
- Chaque ticket est-il clair pour tout le monde ?
- Que tous ceux qui pensent que c’est fini lèvent la main !
Et voilà ! Ce n’est pas plus compliqué que cela. Ça nous a pris en tout et pour tout 30 minutes. C’est tellement rapide et efficace que c’en est presque embarrassant, mais c’est aussi ça, la magie de l’Agilité ! Je rappelle aux distraits le 10me Principe du Manifeste Agile :
“La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”
A bientôt !
