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

Exemple d'engagement sur une itération

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

Exemple d'engagement sur une itération 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 :-)