Engagez-vous ils disaient...
15 oct. 2012 Olivier Azeau En français 13
Air du temps ou coïncidence, je suis tombé sur deux billets traitant de l'engagement des développeurs :
Tout d'abord, dans le Bouzin Agile : Développeurs mettez vos couilles sur le billot.
L'engagement est la liste des Users Stories que l'équipe pense développer durant l'itération. [...] l'engagement permet quelque chose de très important à mes yeux : de placer la barre à une certaine hauteur et de comparer à la fin de l'itération ce qui a été réalisé
Et le jour suivant chez Coacher une équipe agile : Obtenir l’engagement de l’équipe.
on sait combien dans une démarche agile, la notion d’engagement sur le résultat du sprint est un élément-clé [...] Comment obtenez-vous l’engagement de tous les coéquipiers sur le nombre de story points ou le nombre de user stories, bref, sur le périmètre défini ?
J'ai un peu de mal à partager ces points de vue.
« L'engagement, c'est un mur conçu expressément pour que l'on fonce dedans. »
A vrai dire, je ne me suis jamais vraiment préoccupé de cette notion d'engagement. L'équipe dans laquelle je travaille a toujours plus ou moins eu un certain sens du travail à accomplir et des attentes de nos utilisateurs.
C'était vrai jusqu'à l'automne 2010 où une release s'est relativement mal passée. L'engagement était au coeur du malaise. Les développeurs, implicitement engagés, ont tenté vainement de livrer tout ce qui avait été, à leurs yeux, "promis", quitte à prendre quelques libertés avec les bonnes pratiques.
Alors on pourra toujours argumenter que l'équipe n'était pas prête à assumer cet engagement, qu'elle n'avait pas la maturité nécessaire pour concilier travail bien fait et engagement sur un périmètre. On pourra trouver toutes les raisons du monde pour dire que l'engagement c'est bien mais que, évidemment, il faut <insérer ici votre pratique favorite qu'il ne faut jamais abandonner>.
Tout ça pour quoi ?
Quel bénéfice réel tire-t-on d'une promesse sur un contenu sachant qu'il y a des pratiques plus prioritaires et non négociables ?
Pour ma part, je ne vois qu'un seul "avantage" : la possibilité de blâmer ceux qui n'ont pas tenu leur promesse.
Si on considère les trois variables coût-délai-contenu, on sait que lorsque deux d'entre elles sont fixées, la troisième ne peut qu'être mesurée ou espérée. Or, définir un engagement, c'est vouloir fixer, par des moyens détournés et avec une certaine bassesse, la variable contenu quand le coût et le délai sont déjà fixés.
Même l'argument "mais c'est pour le bien de l'équipe pour qu'elle réfléchisse à la façon de faire mieux" ne tient pas : soit on fait confiance aux gens pour qu'ils donnent le meilleur d'eux mêmes, soit on ne fait pas confiance.
« Le sage trouve mieux son compte à ne point s'engager qu'à vaincre. »
La petite mésaventure que je mentionnais un peu plus haut m'aura au moins permis de faire avancer une approche différente en me donnant l'occasion de supprimer les itérations pour aller vers un développement plus fluide.
Finies les itérations, finies les durées fixes, finis les engagements sur un contenu d'itération. L'équipe se focalise sur les deux ou trois éléments de backlog produit actifs à un instant donné et si un engagement lui est demandé, c'est de faire chaque jour de son mieux pour que ces éléments soient réalisés.
Mais, alors, me direz-vous, si l'équipe ne s'engage plus comment pourrais-je leur mettre la pression à cette bande de bons à rien savoir à quelle date telle ou telle fonctionnalité sera livrée au client ?
La planification, c'est à dire le fait de prédire quels élements seront réalisés ou pas pour une date donnée ne devrait pas être demandé aux développeurs. D'ailleurs, cela ne devrait être demandé à aucun être humain car aucun d'entre eux n'a les moyens de faire cette prédiction.
Chez nous, on a adopté une technique où on laisse une machine nous donner des probabilités de livraison en fonction des temps de réalisation observés sur les éléments passés[1]. A l'usage, les prévisions que nous obtenons sont correctes (et même meilleures qu'en faisant intervenir des humains) tout en ayant fait baisser la pression inutile qui pèse sur les épaules d'une équipe que l'on pousserait trop à s'engager.
Ceux qui voudraient avoir un peu plus de détails sur ce qui a changé dans notre équipe du fait de cette transition méthodologique, je leur propose de venir le jeudi 25 octobre à Agile Tour Toulouse pour "Deux ans dans le flux"...
Notes
[1] la description détaillée de cette technique sera le sujet d'un billet ultérieur
Ton billet et les 2 billets mentionnés m'ont pas mal fait réfléchir.
Et je comprends ton point de vue, et même y adhère.
Mais en prenant un peu de recul, la discussion porte sur l'engagement sur un périmètre, à faire quelque chose pour une date donnée. Mais je pense qu'il y a d'autres formes d'engagement et qu'il ne faut pas toutes les bannir.
Depuis 1 an que je me suis mis au rugby, je pense avoir compris le sens du mot équipe. Et pour continuer l'analogie, en tant qu'équipe, on ne prendra pas l'engagement d'aller marquer un essai ou de ne pas en prendre mais on fera tout pour. Et chacun sait dans l'équipe que tous les autres ont la motivation nécessaire pour y arriver. Ça rejoint ta notion de confiance.
En revanche, s'il n'y a pas d'engagement à obtenir un résultat, il y a un engagement au sein même de l'équipe, vis-à-vis de ses autres coéquipiers, pour toujours aller les soutenir et ne pas les laisser dans la galère, à s'arracher pour aller couvrir un coéquipier qui se serait fait déborder, sans broncher.
Dans une équipe, c'est le couple "Confiance/Engagement vis à vis des autres" qui détermine sa maturité, à mon sens. Et je pense que l'un ne va pas sans l'autre.
L'engagement demandé sur une itération est un moyen de forcer les personnes de l'équipe à s'engager les unes par rapport aux autres, mais ce n'est pas forcément le meilleur, je suis d'accord.
Oui Jérôme, je suis d'accord avec la nécessité d'un engagement. J'ai même écrit dans le billet :
"si un engagement lui est demandé, c'est de faire chaque jour de son mieux pour que ces éléments soient réalisés"
Cela correspond à ce que tu décris pour le rugby. Faire de son mieux pour que le produit se réalise, petit à petit, cela signifie aller aider le collègue qui est en galère sur un bug, ne pas se tenir en retrait pendant que les autres élaborent la meilleure façon d'avancer, etc.
Tout ça est bien différent de l'engagement illusoire sur un résultat attendu.
A mon avis, le problème en amont est souvent le contrat qui stipule des obligations de résultat alors qu'au sein de l'équipe on s'engage davantage sur les moyens.
Le problème n'est pas tant l'engagement en lui même que la notion pervertie de l'engagement amenée par les objectifs chiffrés dans des contextes ou ils ne sont pas adaptés (ici le développement de produits trop complexes pour obtenir une vraie prédictibilité).
C'est l'éternel problème de la tenue des (fausses) promesses d'un modèle (cycle en V, théorie X, objectifs chiffrés, maitrise des couts), dans un modèle complètement différent (agilité, théorie Y, meilleur effort, retour sur investissement maximum).
Tant qu'on aura pas trouvé comment établir une collaboration saine et confiante entre client et fournisseur, les agilistes seront contraints de dépenser une part de leur énergie à trouver des palliatifs (ne pas faire de forfait en donnant l'impression de faire du forfait) et pas à faire avancer leurs produits.
@greg,
Le problème va plus loin que le contrat. Je suis à peu près certain que nombre d'agilistes conscients des travers induits par les contrats de forfait persistent à croire que l'engagement à l'itération reste une bonne chose.
@antoine,
idem. Le problème est plus profond que cela. Même en "agilité, théorie Y, meilleur effort, retour sur investissement maximum" on peut se retrouver dans des situations impossibles.
Un "engagement volontaire" de la part de quelqu'un qui ne subirait pas de pressions objectifs chiffrés/maîtrise des coûts ne vaut pas mieux.
Ton billet m'a fait fortement réagir, limite bondir :)
A quoi sert l'engagement ? c'est une bonne question, mais ta réponse me parait simpliste.
même si j'entends bien le discours sur l'équipe qui fait de son mieux, je l'ai vécu, je l'ai senti ... nous partageons bien que l'engagement reste un élément clé de la motivation et de l'amélioration continue.
Mais surtout, sans engagement, pas de vision et cohérence du sprint et donc pas de démonstration ... finalement pas d'engagement, pas de Scrum ... et c'est la conclusion à laquelle vous êtes parvenus sur votre projet.
Si nous partageons la conclusion, nous ne partageons pas l'analyse.
Retour à Scrum, mais côté PO
1) en tant que PO, l'engagement de l'équipe me permet de savoir ce que je vais pouvoir démontrer à mon client à la fin d'un sprint ! Allons nous pouvoir démontrer un ensemble cohérent ?
L'équipe n'est pas mature ? il vaut mieux qu'elle s'engage sur un périmètre restreint, l'utilisation d'un buffer peut être utile au démarrage ... les clients aiment bien avoir de bonnes surprises.
2) et parce que j'aime bien répondre aux questions par des questions :
Si il n'y a pas d'engagement à quoi vous servent les daily meeting ? ça va ? bien et toi ? merci
Cela m'intéresse de savoir quelle a été votre réaction lors de votre petite mésaventure ? :
Quand avez vous su que vous ne tiendrez pas l'engagement ? (traduction Scrum : à quel Daily Meeting)
L'avez vous clairement affiché ?
Quelles bonnes pratiques ont été mises de côté ?
supposition : la bonne pratique qui est de remonter et partager un doute sur l'engagement a très certainement été la première à avoir été mise de côté non ?
C'est dommage car remonter ce doute c'est respecter un principe de transparence très cher à l'agilité, cela aurait pu permettre de revoir à la baisse le périmètre du sprint avec le PO ... ou bien arrêter le Sprint, faire un état des lieux et repartir sur de bonnes bases .... mais ce bon à rien de PO n'aurait pas comprendre, c'est cela ? :)
3) Comme je l'ai dit, nous partageons la conclusion : si il n'y a pas de nécessité de démonstration client à la fin de chaque itération, le Kanban est une bonne solution ... mais là encore je ne partage pas du tout la non maitrise que vous semblez afficher de votre flux : les probabilités de livraison peuvent être estimées bien évidemment, de même que les durées de livraison peuvent être réduites (et plus qu'on ne le croit), mais cela revient à maitriser son flux et à avoir la volonté de l'améliorer, et qu'on le veuille ou non, c'est une forme d'engagement (Kanban parle de classes de service si je me rappelle bien). Note : l'engagement Scrum se fait aussi sur des estimation collectives prenant comme étalon des éléments qui ont été réellement réalisés.
4) Ne pas vouloir s'engager en Scrum revient à ne pas vouloir améliorer son flux en Kanban, l'équipe fait de son mieux mais elle pourrait mieux faire si elle y réfléchissait ... c'est juste dommage
5) était ce une équipe qui avait l'habitude de se reposer sur ce qu'un chef de projet lui planifiait ? elle n'a pas souhaité saisir l'opportunité de maitriser son engagement avec Scrum et maintenant son engagement repose maintenant sur une machine ... c'est bien pratique.
Scrum ne pousse absolument pas à trop s'engager ! il pousse à s'engager au plus juste, mais pour cela il faut une équipe qui se prenne en main. Attention, je n'ai pas dit que c'était aisé !
6) Que se passerait il, maintenant que vous êtes dans le flux, si le même problème arrivait maintenant (celui de la release qui se passe mal) : pensez vous réellement que le fait d'être dans le flux a résolut votre problème ? je ne le pense pas : que se passera t il quand une prévision générée par une machine ne sera pas vérifiée ? les mêmes vieux démons viendront vous hanter :) cette bande de bon à rien n'est même pas fichue de nous livrer le bouzin à temps, alors que la magic machine à estimer nous avait dit que c'était bon !
@fxMaq J'ai l'impression que tu réduis l'engagement à la possibilité de s'améliorer... Je ne vois même pas le rapport.
Prends un élève à l'école, sa note maximale peut être de 20 sur 20. Va-t-il s'engager à avoir 20 ? 16 ? au moins 10 ? Quel intérêt à ça ? Il va s'engager à faire de son mieux et, s'il n'a pas 20, voir pourquoi et s'améliorer pour la suite.
Dans le développement, j'espère que tu ne vas pas chercher à t'améliorer juste parce que tu n'as pas atteints ton objectif ? Si tu prends un engagement faible comme tu le préconises parfois, alors tu risques d'atteindre tes objectifs. Quelle en est la conséquence ? Tu ne chercheras pas à t'améliorer ?
Si tu souhaites faire des itérations, tu feras la démonstration de ce qui aura était développé. Quel besoin de devoir l'annoncer avant ?
Personnellement, je pense que l'engagement est un vrai faux problème. C'est un besoin pour les gestionnaires au mauvais sens du terme dans mes mots. C'est d'ailleurs à mon avis une nécessité pour justifier leur existence. En effet, tout le travail d'un gestionnaire de projet (un chef de projet dit-on) ne consiste qu'à vérifier que les engagements seront respectés. Du coup, lorsqu'il y a des problèmes, on révise les engagements... on ne s'était peut-être pas bien compris...
@Jerome si l'engagement est un engagement d'être un co-équipier, soit, mais je dirais que c'est la base. Sinon, tu ne joues pas en équipe. Mais quel joueur va mettre ses couilles sur le billot sur la victoire ? On sait tous très bien que tout ne se déroule pas toujours comme souhaitait...
@sfui : je me suis sans doute mal exprimé : si je devais réduire l'engagement à quelque chose, ce serait bien pour pouvoir afficher ce que l'on veut démontrer en fin de Sprint, ça c'est le but. Le meilleur moyen c'est l'équipe auto-organisée et responsabilisée.
Ta métaphore sur l'élève ne fonctionne pas du tout : pour que cela fonctionne il faudrait que l'élève élabore avec le prof, le contenu de l'interrogation et la façon de noter.
Évidemment qu'il viserait alors le 20/20 : cela correspond à 100% des US sur lesquelles l'équipe s'est engagée qui sont validées par le PO. Même si l'équipe a fait de son mieux, si elle n'a pas 20, j'espère bien qu'elle va chercher à s'améliorer ...
Je ne préconise absolument pas d'engagement faible, car cela revient à ne pas s'engager ... je dis juste qu'avec une équipe non mature, en attendant la maitrise, c'est préférable pour la confiance.
Si tu ne vois pas quel est le besoin d'annoncer le périmètre d'une itération, c'est que tu n'as jamais du devoir mobiliser des personnes déjà bien occupées par ailleurs par leur propre travail à venir te donner du feedback lors d'une démo.
pour la fin de ton message, je ne comprends pas pourquoi tu parles de gestionnaires ... l'engagement c'est entre l'équipe et le PO ... il n'y a pas de "gestionnaire" dans cette histoire. Avec Scrum, l'équipe s'auto-organise et est responsabilisée ... elle doit maitriser son engagement et doit savoir identifier au plus vite qu'il ne sera pas tenu, non pas pour se faire taper dessus, mais pour expliquer une adaptation de son engagement ou faire disparaitre le problème qui l'empêche de le tenir.
Le risque quand une équipe ne veut pas s'engager, c'est justement que quelqu'un cherche à les y forcer.
Dans Scrum, tout est lié, les imbrications sont multiples, pas évidentes à appréhender, mais elles existent, vouloir mettre l'engagement sur le billot ne serait pas sans conséquences.
@fxMaq,
Je retiens une seule phrase qui, à mon avis, est très significative : "Si tu ne vois pas quel est le besoin d'annoncer le périmètre d'une itération, c'est que tu n'as jamais du devoir mobiliser des personnes déjà bien occupées par ailleurs par leur propre travail à venir te donner du feedback lors d'une démo."
Effectivement, pour ma part, je n'ai pas à "mobiliser" d'autres personnes car le logiciel que nous développons est tellement attendu par ces autres personnes que, pour elles, prendre un peu de temps pour l'installer et y jeter un coup d'oeil est la chose la plus naturelle du monde. De même, je n'ai pas à demander l'engagement des développeurs car faire de leur mieux et s'améliorer est aussi pour eux une seconde nature.
Pour le reste (la maturité supposée de l'équipe, les bonnes pratiques mises de côté ou pas, les vieux démons qui viendront nous hanter ou pas), je ne vois même pas quoi répondre tellement ces considérations sont éloignées de notre quotidien...
Alors peut-être avons-nous (l'équipe et les divers stakeholders) atteint un certain niveau de maturité qui nous permet de ne pas avoir à perdre du temps avec "l'engagement" ou "la mobilisation" ? Je commence à le croire.
Est-ce que cet engagement ou cette mobilisation ou toute autre forme d'agilité" à la carotte et au baton" sauvera les autres équipes ? J'en suis de moins en moins sûr...
@Oaz : vous avez beaucoup de chance. Je m'étonne juste que les personnes qui attendent tellement votre logiciel n'aient aucune nécessité de connaitre la disponibilité de telle ou telle fonctionnalité ... était ce aussi le cas il y a 2 ans ?
Quant à la maturité de l'équipe, je ne connais pas votre équipe et je ne voulais porter aucun jugement, je me suis juste basé sur ta phrase : "l'équipe n'était pas prête à assumer cet engagement, qu'elle n'avait pas la maturité nécessaire", 2 ans après évidemment que la maturité doit être arrivée à un très bon niveau, les questions du daily doivent être plus du genre : que vais apprendre aujourd'hui, ou qu'ai je envie de partager ...
Si vous n'avez aucun essoufflement, aucun problème a garder la motivation de chacune des parties prenantes, du feedback qui vient tout seul ... profitez en ... et pourvu que ça dure :)
@fxMaq, extrait du Scrum Update 2011 http://www.scrum.org/Portals/0/Docu...
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting.
De mon coté j'ai arrêté il y a longtemps de parler d'engagement pour parler de planning d'itération.
@Oaz : j'attend avec impatience ta description de votre process d'estimation, j'ai rien compris à ton lightning talk à l'Agile Tour Bordeaux ;) et je ne serais pas à Toulouse :( mais j'ai l'impression que ça ressemble à des choses que je veux essayer alors je suis très curieux !!!
@pgrange : facile de jouer avec les mots, surtout avec un morceau de citation privé de sa partie la plus importante : "The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint."
On ne parle pas de "commitment" mais de "forecast" => et c'est bien ce dont je parlais, on doit se poser tous les jours la question, la projection change d'ailleurs tous les jours, et je persiste à dire que le but pour l'Equipe est bien de pouvoir indiquer ce que l'on va pouvoir démontrer / délivrer à la fin de l'itération.
Après on a toujours le droit de se tromper, mais plus on est transparent plus c'est facile à expliquer.
en cherchant un peu, j'ai trouvé un article de Robert Galen sur la disparation du mot commitment : http://www.projecttimes.com/robert-...
Je pense que c'est un point de vue qui nous réunira :)