Engagement sur des itérations par l'exemple
Par Cyrille » 15 octobre 2012 (22:54) - Scrum - Méthodes agiles
Le billet "Développeurs mettez vos couilles sur le billot" a au moins eu le mérite de faire un peu de bruit 
Alors au lieu de refaire un nouveau billet expliquant pourquoi je milite pour l'engagement des itérations et "risquer" d'être mal compris, voici un exemple sur ce que nous avons fait sur un projet, le tout en image.
Le contexte
Un projet de développement X avec Y développeurs (en régie), nous sommes à l'itération 82, les itérations font 2 semaines.
Nous sommes à la version Z qui sera déployée à la fin de l'itération 84.
Dans cette version, nous avons 11 fonctionnalités (indiquées A à K).
Les fonctionnalités ne sont pas toutes spécifiées et bien sûr de nouvelles Users Stories apparaissent au fil des itérations.
Les fonctionnalités A,D, E et J ont été identifiées par l'équipe comme plus grosses que B,C,F,G,H,I, et K.
L'engagement de l'itération 82
Comment cela se lit
En orange sont présentées les Users Stories terminées durant les itérations 79 à 81.
En rose, l'engagement de l'équipe pour l'itération 82, en j'aune 83 et en blanc 84.
Fonctionnellement cela donne ceci :
- Nous allons avancer sur la fonctionnalité A durant l'itération 82 et nous pensons la finir durant l'itération 83,
- Les fonctionnalités B,C et D sont terminées et peuvent être intégralement testées,
- Nous pensons commencer la fonctionnalité E, mais nous pensons qu'elle sera terminée pour l'itération 84,
- La fonctionnalité F devrait être terminée pour l'itération 83,
- Les fonctionnalités G et H vont être commencés sur cette itération, mais ne seront pas terminées,
etc...
Une fois que l'on a affiché ce schéma, on entend ce type de questions (du PO, Métier) :
- Cela représente combien de jour un carré ?
- Vous ne pouvez pas déplacer les carrés de H pour terminer G ?
- Et pourquoi vous ne terminez pas G, il ne reste qu'un carré ?
Il n'y a qu'une seule ligne de conduite :
- Un carré est une unité abstraite qui représente grossièrement l'avancement d'une fonctionnalité,
- Cet engagement est la prédiction de ce que nous (équipe) pensons réaliser sur l'itération 82 (en rose),
- Cette "planification" prend en compte les priorisations du métier ainsi que les contraintes techniques,
- Cet engagement n'est fourni qu'à titre représentatif, il ne saurait remettre en cause la capacité ou la motivation d'un ou de plusieurs membres de l'équipe,
- Cet engagement n'est pas un document contractuel : vous pouvez lire en tout petit "Photo non contractuelle :-)".
Comment nous avons construit ce document
C'est la phase la plus délicate et ce qui a fonctionné avec cette équipe ne fonctionnera peut-être pas avec une autre car vous aurez peut-être raté votre communication.
- Etape 0 : je liste les fonctionnalités de la version, les numéros des itérations, j'imprime (10 feuilles) et je prépare 3 feutres fluo,
- Etape 1 : je scotch la feuille dans l'open space, à un endroit visible de tous, je réunis l'équipe,
- Etape 2 : je demande "Quelles sont les fonctionnalités terminées ?" et je colorie B, C et D,
- Etape 3 : je demande "Quelles sont les fonctionnalités commencées et ou pensez-vous que nous en sommes ?", et on arrive à des choses comme il reste quand même un peu de boulot sur la fonctionnalité A, disons 2 carrés, on a avancé mais très légèrement sur E mais c'est vraiment à la marge...
- Etape 4 : La plus difficile : "Que pensez-vous que nous arriverons à développer sur cette itération ?" et là vous vous taisez et vous écoutez quand vous êtes arrivés à un consensus vous coloriez en rose : nous pensons finir A, finir la consultation de E, avancer sur G et H.
- Point important : En tant que facilitateur, vous ne devez jamais juger ou commenter ce que disent les développeurs, par contre vous devez identifier tous les obstacles que vous entendez (on ne peut pas bosser là-dessus car on n'a pas ....), logiquement vous êtes au courant de tous ces points de blocage mais vous pouvez en découvrir de nouveaux.
- Etape 5 : Refaites la même chose avec l'itération 83 (ça va encore vous coûter 1 ou 2 feuilles),
- Etape 6 : Maintenant poser la question : "Est-ce que vous trouvez que les itérations sont équilibrées ?" (ne pas oublier de rappeler tous les évènements comme les congés, formations, jours fériés...). L'équipe peut avoir envie de faire quelques modifications.
- Etape 7 : Remerciez l'équipe, prenez une photo et NE DITES RIEN.
Oui ne dites rien
Vous allez être frustrés lorsque vous allez faire le coloriage, vous aurez envi de colorier le dernier carré de H, mais NE LE FAITES PAS.
Ceci est l'engagement de votre équipe, vous devez apprendre à faire confiance à toutes les personnes de l'équipe, si vous modifier quelque chose qui ne vient pas de l'équipe :
- Vous leur imposez un rythme,
- Vous leur manquez de respect : vous pensez qu'ils ne sont pas capables de s'engager seuls sur ce qu'ils pensent réaliser,
- Et donc vous leur montrez que vous ne leur faites pas confiance.
La séance de coloriage est très ludique, elle permet à l'équipe d'avoir le même niveau d'information. Parfois certains membres de l'équipe découvrent qu'une fonctionnalité est terminée, et oui la communication est parfois difficile même avec les personnes qui sont à quelques mètres de vous
Et maintenant, laisser agir et rendez-vous à la fin de l'itération.
Le résultat à la fin l'itération 83
L'itération 82 a été terminée et nous avons refait le même exercice pour l'itération 83 :
- La fonctionnalité A n'a pas été terminée pour une raison technique (ce point a fait l'objet principal de la rétrospective de l'itération 82),
- Nous avons terminé G et presque terminé H,
- Et nous avons fini la consultation de C.
Oui certaines fonctionnalités n'ont pas été terminées mais d'autres le sont ou bien elles ont plus avancé que prévu.
En conclusion
L'engagement de l'équipe de développement n'est pas un engagement millimétré ni même chronométré.
L'engagement de l'équipe n'est pas discutable même si c'est tentant de vouloir "challenger" l'engagement de l'équipe : Ne le faites pas.
Cette feuille est affichée sur un mur bien visible, elle permet à tous les acteurs du projet de savoir où en est l'équipe de développement.
Par tous les acteurs j'entends :
- Les développeurs,
- Mais aussi le PO, qui sait ce qu'il peut tester, qui sait ce quelles Users Stories et quels tests fitenesses il doit rédiger,
- Ainsi que tous les autres acteurs qui gravitent autour du projet (Manager, métier, ingénieurs systèmes,...)
Il n'y a aucune raison d'utiliser ce document pour blâmer l'équipe ou leur mettre une quelconque pression durant l'itération.
Ce document est la feuille de route de votre équipe et vous constaterez qu'ils feront ce qu'il faut pour atteindre l'objectif.
Acceptez que certaines itérations seront plus légères que d'autres car il y aura des tâches techniques mais cela est important pour votre produit : le refactoring est un investissement et comme tout investissement le retour peu être plus ou moins long.
Notez qu'il n'y a aucune couille accrochée sur ces documents
Évaluer ce billet
4/5
- Note : 4
- Votes : 1
- Plus haute : 4
- Plus basse : 4
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Je ne sais pas trop quoi dire des informations présentes dans ce billet tellement cela va au delà de la notion d'engagement.
Le truc qui m'a le plus marqué, c'est la question potentielle de PO "Vous ne pouvez pas déplacer les carrés de H pour terminer G ?"
L'équipe dont il est question ici évolue visiblement dans un environnement où le PO n'a même pas le droit de prioriser les user stories comme bon lui semble... A partir de là, le reste ne peut être que vicié.
Cela me conforte dans l'idée où ces développeurs "s'engagent" pour de mauvaises raisons. Apparemment, ils ont besoin de se justifier sur le fait qu'ils ne livrent pas dans l'ordre où le PO voudrait mais que, pour des raisons "techniques" donc obscures dont on ignore tout ils phasent leur développement d'une certaine manière. Du coup, l'engagement semble agir comme un antalgique (un truc qui masque la douleur mais ne soigne rien du tout) : "tu as vu ? on 'engage quand même à livrer ça dans la prochaine itération donc au bout de 2 itérations tu l'auras ta fonctionnalité G"
Bref, pour moi, cette équipe n'est pas agile. Elle déguise son waterfall avec des itérations en acceptant, entre les itérations, un changement (limité ?) sur les user stories qui composent une fonctionnalité.
Je trouve que tu prends des raccourcis, le PO ne peut pas modifier donc le projet est en Waterfall.
La conclusion est simple : "L'engagement dans Scrum, ça faisait déjà discuter en 2007"
http://www.aubryconseil.com/post/20...
http://agilitateur.azeau.com/post/2...
J'espère avoir l'occasion de continuer ces échanges de vive voix
Bonjour,
Je suis d'accord avec la vision de l'engagement défendu par Cyrille. Le PO définit et priorise les User Stories fonctionnelles (en plus de définir les critères d'acceptation et les objectifs des sprints, en autres), mais c'est bien l'équipe de développement qui indique ce qu'elle est en capacité de réaliser dans l'intération et donc ce sur quoi elle peut s'engager.
Dans scrum il ne faut pas voir l'engagement comme un acte contractuel ou comme un "engagement de responsabilité" en cas de non réalisation de toutes les stories affectées à une itération ( la nous sommes dans un anti-agile primaire), mais comme une indication (en plus de la volonté) de ce que l'équipe peut raisonnablement réaliser dans le temps d'une itération.
L'engagement d'une équipe n'a rien à voir avec les priorisations du PO. Le PO priorise et indique ce qu'il voudrait voir réaliser dans une itération et l'équipe indique jusqu'à quelle storie elle est en capacité de répondre aux objectifs. Dans le cas contraire, le PO risque de charger la mule avec le risque que tout ne soit pas réaliser dans les temps, que l'équipe se démotive car ayant l'impression qu'on lui force la main et que tout cela casse la communication et la confiance entre les acteurs.
Bravo pour ton billet Cyrille, qui a au moins le mérite de mettre le doigt sur un sujet important, souvent trop sous estimé.
Hello Couthaïer,
> L'engagement d'une équipe n'a rien à voir avec les priorisations du PO
L'équipe essaye de s'aligner au mieux sur la priorisation du PO, le rien à voir est à mon avis un peu fort.
Cyrille
Le PO priorise et l'équipe indique jusqu'où elle peut aller, on est bien d'accord !
Mais donc, si le PO priorise toutes les User Stories de la fonctionnalité G avant la moindre User Story de la fonctionnalité H, l'équipe doit les traiter dans cet ordre là.
Dans un tel cas, un développeur ne doit pas s'attaquer à la moindre US de H avant d'avoir fini G.
D'où ma réaction sur le "Vous ne pouvez pas déplacer les carrés de H pour terminer G ?"
Si les carrés représentent "grosso modo" le même effort, les 4 carrés de H que les développeurs embarquent dans l'itération 82 valent probablement au moins les 2 carrés manquant pour terminer G dans cette même itération.
Ce que je veux mettre en évidence, c'est que les priorisations du PO ne sont pas de vagues souhaits à l'échelle assez large d'une "fonctionnalité" : la moindre user story est priorisée par rapport aux autres et aucun développeur n'a le pouvoir de changer unilatéralement cette priorité !
Hello Olivier,
Les lignes G et H représentent des fonctionnalités, là où il y a une subtilité que j'admets ne pas avoir détailler c'est que chaque fonctionnalités possèdent des niveaux d'utilisation plus ou moins stables pour le PO, stable dans le sens fonctionnel, il se pose encore des questions sur l'intérêt de développer le dernier "carré" ou bien de nous demander de rajouter des nouvelles Users Stories.
Dans le projet la phrase n'est pas venu du PO mais d'une personne du métier qui n'avait pas cette information et je l'ai volontairement remise dans le texte pour marquer l'important de la NON négociation sur l'engagement de l'équipe.
L'équipe reçoit la liste au père Noël du PO, elle analyse ce besoin et présente une vision sur quelques itérations. Il y aura quelques discussions mais il faut garder une ligne de conduite.
Après il est important de comprendre les besoins du PO vis à vis des itérations :
- Le PO garde les itérations impaires,
- Le PO présente les itérations paires à des utilisateurs identifiées,
- Le PO présente la version à tous les utilisateurs.
Donc on peut penser qu'il y a des itérations plus importantes que d'autres d'un point de vu contenu, l'idéal étant de garder la cohérence du discours du PO vis à vis des utilisateurs.
Après le truc amusant que j'ai constaté est le suivant :
- quand on prend la liste des Users Stories priorisées
- et qu'on lui montre comment l'équipe s'organise,
Le PO veut modifier sa priorisation, il faut donc tout recommencer
Donc ce que je veux mettre en avant : "Ok la priorisation du PO est super importante mais le plus important reste de développer l'application et pas de passer des jours voire semaines à modifier les priorités des Users Stories".
Mais cela ne change en rien ma position sur l'engagement des équipes de développement
ok c'est trop subtil pour moi cette histoire d'itérations paires et impaires mais l'essentiel pour chacun est d'avoir un système qui fonctionne dans son environnement.
Et je suis bien évidemment d'accord sur la NON négociation.
D'ailleurs chez nous il n'y a plus d'itérations, ni d'estimations et il n'y a pas d'engagement mais il n'y a absolument rien de négociable : le PO priorise les élements de backlog produit et l'équipe les réalise dans l'ordre où ils sont priorisés et ça prend le temps que ça prend...
On discutera des itérations paires et impaires autour d'un verre
!
On a fait "sauter" les énormes réunions d'estimations, on cherche à savoir à la louche ce qui rentre dans l'itération (donc oui on ne mesure pas notre vélocité)
Fil des commentaires de ce billet
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
URL de rétrolien : http://www.bouzin-agile.fr/?trackback/246