En finir avec le stand-up ?

Le stand-up, ou scrum meeting, quelque soit le nom que vous lui donniez, est un élément prépondérant du framework Scrum (et d’autres approches agiles également). C’est lui qui permet de maintenir le cap de l’itération et de s’assurer que tout reste dans les clous de ce qui a été prévu en début de Sprint et de faire des choix ou des actions correctrices le cas échéant.

Vous connaissez sans doute le principe : à heure fixe chaque jour, les membres de l’équipe se rassemblent, souvent devant leur Scrum Board. C’est un rendez-vous court d’une dizaine de minutes (c’est pourquoi tout le monde reste debout) et chacun répond à 3 questions :

  • Qu’ai-je fait hier ?
  • Qu’ai-je l’intention de faire aujord’hui ?
  • Quelle problème ai-je rencontré ?

Tout est dans l’efficacité. Qu’est-ce qui pourrait mal tourner ?

De l’équipe à l’individu

Scrum insiste beaucoup sur la notion d’équipe et l’auto-organisation. C’est la raison principale pour laquelle il n’y a pas d’autre rôle qu’équipier au sein de l’équipe de développement. On doit travailler ensemble pour traiter une User Story et c’est ensemble que l’on escompte atteindre l’objectif de Sprint.

Et soudain, au stand-up, c’est à l’accomplissement individuel que l’on s’intéresse. Pas à la user story si on y a travaillé à 3, mais à la part que chacun y a pris. Une bonne façon d’induire les comportements individualistes dont on voulait se débarrasser en premier lieu. Plus souvent, cela conduit les équipier à s’approprier individuellement des items de backlog. Autant pour l’esprit d’équipe !

Mais ce n’est pas fini.

Les auteurs de Scrum nous suggèrent aussi de mettre à jour le reste à faire des tâches. En heures. Nous nous éloignons encore un peu plus du regard vers l’objectif de sprint. De la valeur ou de l’impact, nous portons maintenant notre attention sur la quantité de travail.

Du Scrum praticien au Scrum Zombie

La mise à jour du reste à faire induit aussi une autre logique : celle de la justification. Finalement notre logique du reporting, celle que nous avions sorti par la porte, est de nouveau rentrée par la fenêtre. Une logique encore agravée par les fameuses 3 questions. Car la première d’entre-elle est : « qu’ai-je fait hier ? ». Comme il s’agit de la première question, ce sera celle à laquelle on accordera le plus de temps et d’attention. Pourtant ce point est purement informatif, et ce sont bien les deux autres questions qui doivent nous aider à prendre des décisions et à nous organiser. Ce devrait être le but premier du stand-up. cette adhésion aveugle à une consigne est aussi la manifestation d’un autre phénomène : Le Scrum Zombie.

Le Scrum Zombie dévoile sa face hideuse lorsque la forme prends le pas sur le fond. Ses lieux de manifestation favoris sont la rétrospective et le stand-up. En focalisant sur la routine et la tyrannie du chronomètre, l’équipe finit par perdre de vue le contenu lui-même :

  • Quel intérêt offre l’information sur ce que j’ai fait ? En quoi cela va aider un de mes équipier à prendre une décision ? Cela va-t-il leur permettre de me donner un feedback qui va m’aider ?
  • Les informations sur les problèmes que j’ai rencontré ou sur ce que je compte faire peuvent-ils influer d’une manière ou d’une autre sur l’adaptation tactique de notre plan d’action ? Cela peut-il aider mes collègues à me proposer leur aide, ou à moi-même de proposer la mienne ?

Quand pour la dernière fois avez-vous pensé à l’une des questions ci-dessus en prenant la parole lors du stand-up ?

C’est bien, vous utilisez le stand-up pour synchroniser l’information au sein de l’équipe. L’information échangée a de la valeur. Hélas, même là le stand-up peut dégrader la qualité de l’interaction au sein de l’équipe !

Quand le stand-up retarde la circulation de l’information

Pour certains, le stand-up est le moment réservé pour parler avec les collègues afin de ne pas déranger ceux-ci durant la journée. C’est plutôt une bonne idée : ne pas déranger ses collègues et ne pas perturber leur concentration pour une information qui peut attendre.

Mais toutes les informations ne peuvent pas attendre. Il y a des choix de conception qui peuvent impacter ce que font vos coéquipiers si ils dépendent du module sur lequel vous travaillez. Certains refactoring assez larges entrainent des modifications qui ne sont pas anodines pour vos voisins. Vous avez pu obtenir une information importante pour l’ensemble de l’équipe et qui remet en cause un de vos postulats. On pourrait trouver bien d’autres exemples.

Dans les cas que nous avons cité, attendre pour informer le reste de l’équipe est le meilleurs moyen pour générer du gâchis et du délais, sans parler de la frustration générée…

Bref le stand-up se transforme parfois en mécanisme pour traiter l’information en mode batch au sein de l’équipe. C’est exactement l’effet inverse de ce que nous souhaitons obtenir.

Alors le stand-up, c’est mal ?

Nous n’avons même pas évoqué le stand-up détourné, par exemple comme outil de pouvoir. Même utilisé dans son but premier, le stand-up peut avoir des effets contre-productif. Mais qu’essayons-nous de faire réellement avec le stand-up, au-delà du folklorique petit cercle ?

L’un des principes majeurs de Scrum, c’est « inspect and adapt ». Le stand-up est notre boucle de feedback journalière, comme je l’avais déjà évoqué. C’est un point de synchronisation qui nous permet d’adapter continuellement notre plan d’itération à une maille qui n’est pas plus longue qu’une journée. Et ce mécanisme est réellement important.

Pourrait-il prendre d’autres formes ? Sans doute. Déjà, lorsque les situations sont tendues il n’est pas rare de voir des équipes opérer spontanément des stand-up deux fois par jour. Des équipes très matures peuvent aussi développer leur propre protocole de resynchronisation au fil de l’eau, rendant le stand-up inutile.

La forme la plus simple à mettre en oeuvre du protocole de synchronisation reste le point journalier. Quand il opère son rôle de synchronisation et d’adaptation du plan d’itération, il est une pratique importante de n’importe quelle approche agile. Mais pas quand la forme prends le pas sur le fond et qu’il se transforme en une pantalonnade ou en reporting.

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Tout est incroyablement plus simple avec les User Stories. L’utilisateur évoque une possibilité ? Hop ! Une User Story ! Une idée autour d’un café ? En voilà une autre !

Plus besoin de gros document, simplement de me balader avec mon calepin sous le bras ! Hélas, cette simplicité est trompeuse. En nous débarrassant d’un artéfact lourd et compliqué, j’ai nommé le célébrissime IEEE 830-1998, les créateurs des User Stories voulaient laisser la place au vrai travail de spécification : l’observation du terrain, la collecte des informations, les conversations constructives, l’exploration des alternatives. Décider ce que l’on doit faire est souvent un véritable travail d’abnégation, ou du moins il devrait l’être.

La simplicité du formalisme des User Stories est trop souvent interprété comme une licence à la superficialité. Pourtant le corpus de connaissance existe, encore faut-il aller le chercher !

La littérature traitant des spécifications est riche de dizaines d’années de publication d’excellente valeur. Oui, d’excellente valeur. Tout cela a souvent été interprété à tord au sein des projets classiques comme la nécessité d’écrire de lourds et nombreux documents se paraphrasant entre-eux (et souvent eux-mêmes).

La spécification agile a fait table rase du passé et de ses enseignements. Table rase d’un formalisme qui a fini par prendre le pas sur le contenu.

Mais est-ce vraiment le cas ?

Template Zombies

Dans l’ouvrage qui leur sont consacrés [Cohn04], Mike Cohn nous propose une formulation aujourd’hui devenu le standard de rédaction des User Stories.

“En tant que xxx, je veux yyy, afin de zzz”

Le template a comme vertu première d’obliger à capturer les éléments importants. C’est bien le cas ici. Cette approche est surtout nécessaire aux débutants comme le relèvent Tom DeMarco et ses co-auteurs [DeMarco+08]. Mais elle vient aussi avec un travers important, où la forme prends le pas sur le fond : c’est le « template zombie ». Gojko Adzic nous en donne un bon exemple [Adzic13] :

“As a user, I want to register in order to log in”

Ah oui ! Etre obligé de me logger et devoir m’enregistrer pour ce faire, j’ai vraiment hâte… D’autres sont des tâches afférentes au travail de développement. Par exemple :

“En tant que développeur, je veux automatiser le processus de déploiement, afin de mettre à disposition l’application plus rapidement et plus souvent”

Bien sûr, cela doit certainement être fait, mais qu’est-ce que cela a à voir avec le produit ? Cela a surtout à voir avec le dogmatisme qui veut que tout ce qui figure dans le plan de sprint soit sous forme de User Story. Si votre motivation est d’être conforme au processus, félicitations : vous faites un projet non-agile en utilisant des techniques agiles !

Dans le même ordre d’idées, nous pourrions évoquer les « stories techniques », mais j’ai déjà écrit sur ce sujet il y a quelques temps.

On peut accuser une certaine paresse, ou une indolence à donner un véritable sens aux user stories. Mais il n’y a pas que cela.

More rules, more pain…

On dit qu’une story doit être petite, de manière à tenir dans une itération ou à être une « survivable experiment » [Adzic+14]. De manière à avoir du feedback plus rapidement aussi, bien sûr, l’un des moteurs de l’agilité. Mais plus de focus, c’est aussi moins de contexte et moins d’invitation à aller le chercher. C’est ainsi que l’on finit par se retrouver avec des User Stories de ce genre :

“En tant qu’analyste financier, je veux un export Excel, afin de manipuler les données comme je le souhaite”

Autant pour la qualité de l’analyse. Et ce n’est pas fini. Nos stories doivent aussi être INVEST. Une bonne idée de manière générale, mais que dois-je faire si certaines de mes stories ne sont effectivement pas indépendantes ? Est-ce si grave ?

Que se passe-t-il si ma User Story consiste à explorer des options ? Dois-je rejeter cette user story car justement, je ne serais pas capable de l’estimer … ou même de la tester ?

L’approche agile doit en principe nous aider à faire face à l’inconnu ou aux idées novatrices. Au lieu de cela, nous nous engageons gaillardement dans une voie qui cherche à éliminer tout risque, à prétexter que notre story n’est « pas prête », bref à aseptiser gentiment notre beau projet.

Alors, doit-on en finir avec ces User Stories ?

Dans son livre, Jeff Patton [Patton14] nous rappelle la véritable nature d’une spécification : créer de la compréhension partagée. Les «  3 C » (carte, conversation, confirmation) nous rappellent que la carte est l’élément le moins important, simplement un « jeton pour une conversation ». Le template de des User Stories a insidieusement déplacé notre attention sur les cartes, et plus précisément l’élément situé au milieu. Ce dernier représente la solution, ironiquement c’est celui qui devrait constituer la marge de négociation du « INVEST » !

Au template, je préfère les 3 questions que nous suggère Jeff Patton (encore lui) : Qui ? Pourquoi ? Quoi ? Et précisément dans cet ordre, avec le « quoi » à la fin !

Enfin, si les User Story remettent l’église au milieu du village en redonnant aux interactions l’importance qui leur est dû, elles ne doivent pas occulter la nécessité de développer des savoir-faire, d’appréhender d’autres techniques permettant la compréhension du contexte et des enjeux, ou supportant l’acquisition d’information. Certaines de ces techniques viennent de la communauté agile, d’autres viennent d’autres domaines comme l’UX ou le « requirements management » que nous avons déjà évoqué.

Bien comprises, les User Stories véhiculent réellement l’état d’esprit agile à ce que nous appelons spécifications (à défaut d’un autre nom plus adapté) : se focaliser sur ce qui compte réellement. Mais il s’agit juste d’un point de départ, à compléter et renforcer comme nous le faisons avec nos pratiques d’ingénierie.

Références

[Adzic13] : Writing “As a User” does not make it a user story ; Gojko Adzic ; http://gojko.net/2013/09/30/writing-as-a-user-does-not-make-it-a-user-story/

[Adzic+14] : Fifty Quick Ideas to Improve your User Stories – Gojko Adzic & David Evans – Leanpub 2014 – ASIN : B00OGT2U7M

[Cohn04] : User Stories Applied, for agile software development – Mike Cohn – Addison Wesley / Signature series 2004 – ISBN: 0-321-20568-5; EAN: 978-0-321-20568-1

[DeMarco+08] : Adrenaline Junkies and Template Zombies ; Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson & Suzanne Robertson

[Patton14] : User Story Mapping – Jeff Patton – O’Reilly 2014 – ISBN : 978 1 491 90490 9

Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

La liste des stories que nous réalisons durant le sprint doit être considéré comme notre contrat de fourniture : voilà ce que nous avons fait, voici où nous en sommes. L’un des mécanismes essentiels en contexte agile est le feedback. La simple déclaration énoncée ci-dessus est sans valeur si je suis dans l’incapacité de la constater et de donner du feedback dessus. Et pour donner ce feedback, il nous faut la connaissance de l’acteur concerné.

Régulièrement, hélas, je vois arriver ces fameuses « user stories techniques ». La justification que j’obtiens alors est : non mais là c’est technique, on a besoin de le faire ! J’ai alors droit à des merveilles du genre :

  • Stocker les donner fournisseur.

Ne souriez pas, c’est très fréquent. Mon exemple est d’ailleurs loin d’être le pire. Je vous épargne le classique « développer la couche de persistance »…

Un second effet de ces user stories techniques peut aussi se constater en planning meeting

La user story technique et le planning meeting

C’est donc conjointement à des user stories plus classiques que ces « stories techniques » se présentent en planning meeting.

image

Mais si les user stories classiques sont traitées assez efficacement, leurs homologues techniques necessitent environ 4 fois plus de temps (bien que je ne l’ai pas mesuré précisément).  Sont en cause :

  • Une difficulté à cadrer la solution, car la finalité n’est pas claire. Il manque le contexte.
  • Impuissance à déterminer le périmètre de la story. Quand celle-ci sera-t-elle terminée ? Quels sont les tests d’acceptation ?

Même avec 4 fois plus de temps, le découpage en tâches et l’estimation s’avèrent moins satisfaisants. Même si vous n’êtes pas fan du découpage en tâches et des estimations, il n’en reste pas moins que ceux-ci s’avèrent symptomatiques de la compréhension de l’item.

Mais voilà : c’est du travail technique, ce n’est pas fonctionnel. Est-ce vraiment le cas ?

Remettre la story technique dans son contexte

Basculer de la user story technique à leurs équivalents fonctionnels est moins difficile qu’il n’y parait de prime abord. Il s’agit surtout de se poser les bonnes questions :

  • Pourquoi a-t-on besoin de faire cela ? Que se passe-t-il, ou qu’est-ce qui se passe mal, si on ne fait pas cela ?
  • Dans quel contexte cela sera-t-il utilisé ?
  • D’un point de vue externe, comment saurais-je que le système possède cette propriété ou cette capacité supplémentaire ?
image

Cette liste n’est pas exhaustive, et vous pourrez facilement imaginer d’autres questions de la même eau. Le but est simple : remettre l’item technique dans un contexte fonctionnel. Dans le cas que nous avons énoncé plus haut (stocker les données fournisseur), à la question « qu’est-ce qui se passe mal si on ne fait pas cela », la réponse est : on ne peut pas communiquer ces informations si le système s’arrête entre leur acquisition et la transmission. Je pourrais vous le souffler à l’oreille, mais cette réponse nous permet assez facilement d’en déduire une user story fonctionnelle…

Et mon refactoring, alors ?

Eh bien c’est vrai, le refactoring, ce n’est pas fonctionnel (apparemment).  Doit-on le rejetter, l’ignorer ? Bref, le développeur doit-il se débrouiller et caser ça à l’heure du déjeuner ?

Bien sûr que non ! Mais ce n’est pas non plus une raison pour produire une « user story technique ».

N’oubliez pas que le mainteneur du système (donc le développeur) est aussi un utilisateur du système. Tout comme le sont les ops et les exploitants chargés de déployer et d’assurer le bon fonctionnement du système en production, soit dit en passant. En tant que mainteneur, vous pouvez demander à rendre un type d’évolution plus facile, de pouvoir prendre en charge de nouveaux périphériques ou de nouveaux algorithmes plus efficacement. Vous pouvez souhaiter que les évolutions ou les corrections soient localisées à un seul composant.

image

Bref, vous pouvez exprimer des besoins qui une fois remis dans le contexte d’un objectif, peuvent être discutés avec le Product Owner. Et vous pouvez même produire des critères d’acceptation ! Certes, ce ne seront pas des tests d’acceptation (on reste iso-fonctionnel, n’est-ce pas ?), mais on peut évaluer l’atteinte de ces critères ne serait-ce que qualitativement. N’oubliez-pas :

Tout ce qui a besoin d’être mesuré peut être mesuré d’une manière qui est de toute manière supérieure à pas de mesure du tout !

Maintenant, c’est trop gros !

Vous avez basculé dans l’usage ? Bien. Et maintenant vous vous rendez compte que votre story a pris de l’embonpoint, car elle intègre maintenant le contexte d’usage ! Je vous entend : c’est justement pour cela que vous aviez fait une story technique, pour que ce ne soit pas trop gros.

Il faut alors passer à la cure d’amaigrissement. Mais pas en réalisant un morceau du mécanisme après l’autre, en faisant des tranches plus fines de ce mécanisme.

image

Faire des tranches fines dépasse le cadre de ce post. Cela reste une compétence clef à acquerir pour le développement agile, en particulier pour le Product Owner. Je vous recommande à ce titre l’exercice du Carpaccio pour aiguiser votre savoir-faire.

A emporter

Peut-être un jour devrais-je faire face à une story technique que je ne saurais pas mettre dans un contexte d’utilisation. Pour l’instant tout va bien. Si vous faites face à cette difficulté, tentez l’exercice !

Reprenez les questions évoquées dans ce post. Au besoin, enrichissez-les des vôtres. Reprenez vos User Stories techniques et mettez-vous à 2 ou 3 autour d’une table et basculez votre story technique dans l’usage qui en est fait.

Soirée « en finir avec… » organisée par le French SUG

Ca y est, je l’ai : Ma soirée mégalo à moi ! En effet, le 29 Janvier nous nous retrouverons sous l’égide du French Scrum User Group pour une soirée exceptionnelle « en finir avec… ».

Pourquoi une telle soirée ? Tout d’abord pour fair écho bien sûr à la série de post que je vous ai asséné depuis maintenant 3 étés, et que vous retrouverez encore quelque temps. Ensuite et surtout pour réfléchir ensemble à nos pratiques agiles : les comprendre et savoir les remettre en cause !

En effet, nous tenons pour acquis la nature agile des pratiques identifiées comme « bonnes pratiques ». Qu’en est-il réellement ? Quelle est la nature et l’objectif fondamental de chacune d’entre-elles ? S’inscrivent-elles vraiment dans notre système de valeur ou s’en éloignent-elles au contraire sous pretexte de compromis à un environnement aux antipodes de ce que nous voulons faire ? Notre acceptation inconditionnelle même de ces pratiques s’inscrit-elle dans un état d’esprit agile ? Mais là, je crois que nous avons déjà la réponse…

Si ma prose vous interpelle, rejoignez-nous le 29 Janvier ! Aucune promesse ne sera faite sur ce que vous pourrez en retirer, car cela dépendra largement de ce que vous saurez y apporter !

Soirée « en finir avec… » organisée par le French SUG

Taylorisme et travailleurs du savoir

Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

image

Le modèle Cynefin [2] est une illustration de la théorie de la complexité. Ce n’est pas le seul modèle développé à cet égard. L’usage premier de ce modèle est de montrer le dynamiques de transition entre les différentes zones. Pourtant, ce n’est pas ce à quoi il va nous servir aujourd’hui. Nous allons l’utiliser pour catégoriser nos contextes projet !

Le domaine simple (évident)

La relation de causalité est directe, évidente. Dès lors la solution s’impose d’elle-même. C’est pourquoi nous sommes dans le domaine des « best practices » : on peut déterminer la meilleure solution à un problème donné. La déclinaison la plus connue de cette approche de « bonnes pratiques » est le management scientifique du travail, qui se traduit par la décomposition d’un travail en tâches élémentaires optimisées. Nous reviendrons bientôt sur ce sujet.

Le domaine compliqué

Toujours sur la base de la relation de causalité, on estime ici que cette relation de causalité nécessite une analyse ou une expertise pour pouvoir être établie à priori. C’est le domaine des « bonnes pratiques ». La solution au problème n’est donc pas nécessairement unique ! On s’offre un éventail d’options restreintes pour traiter notre problème. Cette déclinaison correspond assez bien à Unified Process qui supporte une forme de customisation [5] par rapport au contexte, permettant cette notion d’options.

Le domaine complexe

Il est en rupture avec les deux précédents, car ici, le lien de causalité ne peut être établi à priori, mais seulement observé à postériori. Nous sommes donc dans le domaine de l’approche empirique et des phénomènes emergents utilisant une boucle de feedback.

Nous sommes dans le « sweet spot » de l’agilité : les territoires inconnus se prêtant à une approche exploratoire.

Le domaine chaotique

Ici, il n’y a aucune corrélation entre cause et effets. Ce domaine induit de purs comportement de réponse aux situations. Nous sommes dans des environnements type « guérilla urbaine » qui ne sont plus le domaine de prédilection de l’agilité.

Le cadre du management scientifique du travail

Le « management scientifique du travail », vous en avez tous entendu parler. Mais peut-être pas sous ce nom. Peut-être êtes-vous plus familier avec le terme « Taylorisme » ?

Dans les grands traits, le management scientifique du travail [3] divise les responsabilités entre deux groupes :

  • Les managers dont le rôle est d’analyser et de dicter la façon de faire le travail
  • Les ouvriers qui doivent suivre à la lettre les instructions (selon le propos de Taylor « ils sont trop stupides pour savoir comment bien travailler » !)

Replacé dans le contexte de la fin du XIXème siècle, à une époque où le travail des ouvriers avait une nature hautement mécanique, cela a du sens. Je vous choque ? Pourtant le Taylorisme fut une avancée majeure pour permettre la production de masse (qui n’existait pas avant) et a permis la révolution industrielle. Aujourd’hui même, les biens de consommation que nous ne saurions nous passer sont presque là grâce au Taylorisme !

image

Quelle place le Taylorisme occupe-t-il dans le modèle Cynefin ? De mon point de vue, il s’agit indubitablement du quadrant « simple » (évident). On est réellement dans le domaine des « best practices, d’ailleurs Taylor parle bien de selection du « best movement » (p. 57) !

Toutefois, et cela a été ignoré par les successeurs de Frederick Taylor, il y a bel et bien des postulats au Management Scientifique du travail

Les postulats du Taylorisme

Ma lecture du texte de Taylor m’amène à penser que les postulats de base sont au nombre de 3. Allons-y !

Le travailleur est trop stupide pour savoir organiser son travail lui-même !

Vous êtes surpris (ou de nouveau choqués) ? En fait, je ne fais que répéter les propos même de Frédérick Taylor ! En fait il répète même cela à plusieurs reprises dans son livre. Il faut dire que l’humain n’était pas forcément le soucis principal de cet ingénieur.

Si le respect des personnes ne semble pas tellement présent, le texte ne laisse pas non plus penser que les travailleurs en question sont des genies…

Le besoin du travailleur se situe au niveau de la sécurité

Certes, on n’avait pas encore la pyramide de Maslow à l’époque, mais un point méconnu est pourtant tout à fait explicite dans le texte de Frederick Taylor : le partage des gains opérés entre le détenteur du capital, le travailleur et le consommateur !

Il faut se replacer dans le contexte de l’époque. Les travailleurs manuels luttent pour nourir leur famille, se loger et s’habiller. L’accomplissement de soi n’est pas leur problème du moment. Ils e situent bien au second niveau de la pyramide de Maslow

image

Ce que propose Taylor est une augmentation très importante de leur revenu [3], p. 46 allant de 80% à 100% avec une réduction significative de leur temps de travail (de 10,5 heures à 8,5 heures). Ce qui, chemin faisant, fait du travailleur un consommateur !

Curieusement, cette contrepartie a progressivement disparue chez les successeur de Taylor !

Le domaine adressé est celui du travail répétitif

Ce postulat n’est pas explicite. Mais il est implicitement présent tout au long du livre. Car l’auteur parle bien de « mechanical shops ». Il n’est fait mention nul part d’expérimentation portant sur du travail non répétitif ou du fait qu’un travail de reflexion puisse être assimilé à un travail répétitif. On trouve cependant une référence au travail de chirurgien, dont il est dit à juste titre que les opérations simples peuvent tomber dans le cadre du « management scientifique du travail ». Un raisonnement que l’on peut accorder à l’auteur … en gardant à l’esprit que l’on parle de chirurgiens du 19ème siècle !

La nature intrinsèque des méthodes classiques

Que l’on parle de cycle en « V » ou d’Unified Process, ces processus sont toujours abordés de la même façon : sous l’angle de ce qui est produit, par qui, comment … En fait tous ces processus peuvent être décrits par le biais d’un métamodèle ! C’est déjà ce que Ken Schwaber mettait en lumière en 1995 [1] !

Voici justement, à peine simplifié, celui d’Unified Process.

image

Même avec un processus accordant certains degrés de liberté, la logique reste bien là : on définit qui produit quoi, comment est-ce produit et dans quel contexte. Intrinsèquement, nous faisons la même chose que Taylor, il y a 130 ans, mais sans respecter aucun de ses postulats. Aucun !

Les approches agiles : une nature disruptive

Ce qui distingue les approches agiles (j’évite le terme « processus » à dessein) des autres, c’est justement de ne pas être construites sur un métamodèle, mais sur ce que nous appelons souvent la pyramide agile. Vous la connaissez très certainement, pardonnez-moi de la refaire figurer ici (et de l’expliquer).

image

Les valeurs : Ils figurent dans le manifeste agile et nous montrent la direction. C’est ce que j’appelle la « boussole agile ».

Les principes : Mise en musique du manifeste, les principes donnent des axes concrets sur les règles à suivre.

Les pratique : Boite à outil infinie (ou presque) à utiliser tel quel pour réaliser les logiciels, les pratiques nous donnent des aides, des façons de faire.

Point de métamodèle ici : on ne peut être émergent et prescriptif. On peut seulement fournir un cadre pour nous aider à aller dans la bonne direction !

Et alors ?

Retour au modèle Cynefin. Le Taylorisme n’est pas mauvais en soi. Il ne l’était surtout pas à l’époque. Mais justement le contexte doit être pris en compte : aucun des 3 postulats, ni le domaine d’application ne sont adaptés au développement du logiciel. Cela devrait nous laisser froid s’il n’existait pas une incarnation directe de celui-ci dans le monde informatique : c’est le micromanagement !

Las, les méthodes classiques s’éloignent quand même au moins un peu du micromanagement. Néanmoins, l’observation sous l’angle du métamodèle nous montre que le paradigme est le même !

Une approche moderne du développement logiciel doit satisfaire :

  • Les besoins des personnes, qui se situent aux niveaux 3 à 5 de la pyramide aujourd’hui.
  • La nature émergente, non prédictive du travailleur du savoir qui a d’avantage besoin d’une boussole que d’un marionnettiste !

Et vous, vous ai-je convaincu ?

Ressources

[1] : The Scrum Development Process – Ken Schwaber – OOPSLA 1995

[2] : The Cynefin model : http://en.wikipedia.org/wiki/Cynefin

[3] : The Principles of Scientific Management – Frederick Winslow Taylor

[4] : Agile and iterative development, a manager’s guide – Craig Larman

[5] : The Rational Unified Process, an introduction, third edition – Philippe Kruchten

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Au fait, quelle est la durée de ce meeting ? Ken Schwaber nous parle d’une durée de 8 heures pour un sprint de 30 jours ! Personnellement, un tel marathon dépasse mes forces et de très loin. Heureusement, bien que les créateurs de Scrum clament la même durée de Sprint depuis 20 ans, je ne connais personne planifiant des sprints aussi long. Mais même ramené au pro-rata à 2 semaines, une durée de 4 heures me semble excessive !

Hélas, il n’y a pas que la durée qui ne va pas. Ce serait même plutôt le moindre de nos soucis. Commençons donc notre travail de dépeçage.

A faire pour le prochain Sprint

La première partie du planning meeting est, nous dit-on consacrée à l’exposé de ce qui est attendu pour le prochain sprint [4]. C’est vrai que je préfère comprendre mon sujet avant de m’y attaquer. Je crois pouvoir dire sans trop me tromper qu’il en va de même pour la plupart d’entre-nous. Par contre, il y a autre chose que je me sens incapable de faire : c’est donner une réponse sur la manière d’entreprendre la réalisation une fois l’explication terminée !

J’ai besoin de réfléchir à ce que l’on vient de me dire, de poser des questions, ruminer à nouveau, en discuter, échanger sur les alternatives, etc. Ca ne nécessite pas des semaines et des mois, ni même beaucoup de charge, mais un peu de délai, disons quelques jours. Me trouver bloqué dans une salle pour mener le processus de bout en bout ne me convient pas. C’est pourquoi je préfère séparer les choses en deux.

image

Débarrassé de la discussion fonctionnelle, le planning meeting ne contient plus que le plan d’action du sprint, il est donc deux fois moins long (on passe de 4 heures à 2 heures pour un sprint de 2 semaines, parfois même moins). Et on n’y évoque donc que les sujets auxquels on a été initiés.

Nous reviendrons bientôt sur cette question du plan d’action. J’aimerais pour l’instant évoquer la discussion fonctionnelle que j’ai séparé du planning meeting proprement dit.

Goodbye, Product Owner…

J’ai un peu culpabilisé quand j’ai pour la première fois proposé de séparer la discussion fonctionnelle : j’avais l’impression de faire une suggestion sur la base de mon inaptitude à explorer complètement un sujet en séance ! Très vite, je me suis cependant aperçu que les membres de l’équipe avaient le même inconfort que moi. D’autres discussions avec des confrères et autres relations m’ont appris que cette gêne était bien plus répandue que je ne le pensais, pour ne pas dire généralisée.

C’est donc avec bonheur que je me suis mis à faire des points d’exploration fonctionnelle (parfois plusieurs) quelques jours avant le planning meeting. Avec quand même deux sujets d’insatisfaction :

  • Explorer tous les sujets d’un sprint, c’est quand même du boulot, surtout si on veut le faire correctement.
  • Une fois que nous avons analysé les user stories, on a parfois tendance à ne plus voir le Product Owner durant tout le sprint.

La réponse à ces deux sujets est commune. Mais je voudrais avant tout affiner le second point : Pourquoi parfois ne parle-t-on plus (ou en tout cas moins) au Product Owner durant le sprint ? Après tout, Scrum nous dit bien que l’équipe de développement et le PO doivent collaborer ! A qui est-ce la faute [5] ?

La faute n’en incombe à aucune des parties spécifiquement. Elle incombe plutôt au processus. En balayant tous les sujets en amont, on instille insidieusement l’idée que nous avons vu tout ce que nous avions à savoir sur le sujet et que nous pouvons vivre notre vie chacun de notre côté pour la durée d’une itération !

Ah oui ! Et aussi, incidemment, nous avons transformé notre sprint en un mini cycle en « V » [6] !

Voyons maintenant le sujet sous un autre angle en tentant de réponde au premier point énoncé plus haut.

La promesse d’une conversation

Quand on balaye tous les sujets d’un sprint, ça fait pas mal de boulot, disais-je. Non seulement cela, mais on discute vraiment très en amont de user stories qui seront traitées vers la fin du sprint !
Mais au fait, c’est quoi exactement une user story ?

Si l’on se réfère à ce que disait l’extrême programming où ce concept a été créé, la user story est « la promesse d’une conversation » [7]. C’était facile, c’est le titre de la section !

Et l’idée de cette promesse, c’est de parler de cette user story « juste à temps », pas de traiter un « stock de discussions ». Interagir autour de cette user story juste à temps présente plusieurs avantage, et aussi au moins un inconvénient que nous verrons plus tard :

  • L’exploration de chaque user story devient un travail plus concis. Plus la peine de programmer de grande pleinières !
  • On aborde chaque user story que préalablement à sa réalisation, le sujet reste frais dans notre esprit et les informations ne se sont pas encore estompées.
  • Puisque l’on retarde le moment où l’on explore le sujet, on bénéficie de tout ce que l’on a appris entre temps. Comme les sujets ont tendance à être traités au sein d’un même sprint, il y a une bonne chance pour que cet acquisition d’information nous bénéficie effectivement.

Il y a bel et bien un inconvénient, cependant : Si l’on doit fourbir notre plan d’action lors du planning meeting (vous savez, la moitié du planning meeting que nous avons conservé jusqu’à présent), cette approche ne convient pas, car nous n’aurons pas évoqué les user stories avant d’avoir à en faire le découpage en tâches !

Le choix est cornélien. Rassurez-vous, nous avons un autre problème inhérent au volet « plan d’action » de notre planning meeting !

Le planning meeting, un plan d’action ?

Nous sommes parés concernant la connaissance fonctionnelle de nos user stories. Allons-y, découpons tout ça en tâches pour faire le plan de notre itération [8]. Comme nous sommes agiles, nous saurons aussi nous adapter, bien entendu. Sauf, que l’on se demande bien comment, car nous avons tous coulé dans le béton à l’instant !

En y regardant de plus près, notre problème d’adaptation se situe même à deux niveaux :

  • Pouvoir adapter le contenu du sprint (donc les stories) à l’objectif du sprint. C’est vrai, nous n’avons pas parlé d’objectif de sprint jusqu’à présent. Un peu de patience, ça va venir.
  • Permettre d’explorer et pouvoir décider de la manière dont on conçoit un pan du système pendant que l’on travaille dessus.

Arrêtons-nous un instant sur ce dernier point. Implicitement, le planning meeting induit que nous devons décider tôt, au moins dans les garndes lignes, la conception d’une fonctionnalité à réaliser. C’est ce qui sous-tend le découpage en tâches des fonctionnalités. Or parfois, même cette décision est difficile à arrêter tôt. Parfois encore, nous avons plusieurs options à notre disposition [9], pourquoi devrions-nous opter pour l’une d’entre-elle à un moment où nous n’avons pas suffisamment d’informations à notre disposition pour décider [10] ?

image

Vous l’aurez peut-être compris, en nous obligeant à fixer nos choix tôt, le planning meeting va à l’inverse de ce que le Lean nous enseigne. En fait, il va aussi à l’encontre de la notion de conception émergente inscrite dans les principes agiles !

Ce n’est hélas pas fini, il y a plus grave ! Ce qui est vrai à l’échelle d’une user story l’est aussi à l’échelle supérieure : l’objectif de sprint !

Vers une planification orientée objectifs

La version 2013 du Scrum Guide reconnait l’importance de la notion d’objectif de sprint [11]. Il n’est pas seulement évoqué au sein du planning meeting, il l’est aussi au niveau du stand-up : il est maintenant la boussole qui nous permet des réajustements ! De mon point de vue, il s’agit d’un pas important dans la bonne direction, celle de la finalité du produit construit.

Maintenant, il faut que le reste du framework Scrum soit en harmonie avec cette idée !

Le plan d’action que nous dresserons lors du planning meeting sera en accord avec l’objectif de sprint, n’en doutons pas. Mais qu’advient-il des nouvelles idées qui naissent de la réalisation des premières fonctionnalités ? Que fait-on des nouvelles options qui germent au grée de la réalisation ? C’est vrai, initialement Scrum nous assène que tout changement ne peut être pris en compte que dans le sprint suivant ; au sein du sprint courant, on va en ligne droite et on ne change rien ! Mais justement, focaliser le sprint sur la finalité plus que sur la fonctionnalité, c’est accepter l’adaptation en cours de sprint et remettre en cause la nature irrévocable de ce qui est décidé en planning meeting.

image

Maintenant que nous avons remis en cause le plan d’action du planning meeting, que nous reste-t-il ? Au moins la synchronisation entre le PO et l’équipe, certes, mais quoi d’autre ?

Il n’y a pas qu’une façon de faire notre planning meeting

Comme souvent, la réponse sera : ça dépend ! Cela dépend de la part d’inconnu que recèle intrinsèquement le projet. Par exemple, à quel point le projet est innovant, mais pas seulement.

Si l’on proclame, et je le fais, que la réalisation d’un projet en agile se justifie d’autant plus qu’un projet est innovant, n’oublions tout de même pas que l plus grande part de nos projets informatiques ne le sont que faiblement : il s’agit en très grande partie de logiciels de gestion. Les besoins d’adaptation de ce type de logiciels sont à la marge et surtout au niveau de détails (ergonomie, règles de gestion, etc..) mais rarement au niveau des grandes fonctions. Dresser un plan d’action complet du sprint lors du planning meeting a pleinement du sens dans ce contexte. C’est même confortable.

A l’autre bout du spectre se tiennent les intrépides explorateurs [12] : ils recherchent le nouveau paradigme, veulent créer l’océan bleu d’un marché à créer de toutes pièces [13] ! Construire un plan de sprint devient contre-productif. Ce dont on a besoin là, c’est d’une direction à suivre à court terme, d’hypothèses à vérifier et d’options à explorer. Le planning meeting devrait graviter autour de cela. Le Daily meeting peut alors devenir une réunion de réajustement du planning meeting, où sont éliminées les hypothèses non vérifiées, sélectionnées les options les plus intéressantes, etc..

Les variantes situées entre ces deux extrémités restent à inventer, lorsqu’elles ne l’ont pas déjà été.

Alors le planning meeting, c’est mal ?

Sortir du planning meeting avec les post-it de stories et de tâches, et pouvoir les afficher sur le Scrum Board mural, je dois avouer, j’apprécie cela ! Tout le monde peut voir durant l’itération où l’on en est, rien qu’en observant le volume de post-its déplacés à droite par rapport à ceux restant à gauche. La plupart du temps, le burndown n’est même pas nécessaire. Comme nous l’avons dit plus haut, cela signifie que le sprint est assez linéaire et plutôt sans surprise !

image

Alors oui, dans ce cas le planning meeting, plus ou moins comme prévu dans Scrum a du sens. Doit-on en conclure que cette cérémonie n’a plus de sens quand le niveau d’incertitude augmente ? Certainement pas ! Mais il faut en adapter le format.

Que penser alors du « mode Kanban » qui bascule complètement le fonctionnement de l’équipe en flux tiré, rendant toute forme de planning meeting sans objet [14] ? J’ai tendance à trouver que dans le cas du développement de produits au moins, une certaine forme de planning meeting fait défaut. Si Kanban excelle à établir le SLA d’une équipe de développement, il lui manque quelque chose pour établir le cap, synchroniser l’équipe et le demandeur à intervalle régulier autour du cap pour favoriser la collaboration entre les acteurs autour du produit. Un planning meeting orienté « roadmap produit » au sens que lui donne l’Impact Mapping [15] pourrait jouer ce rôle, par exemple.

Donc oui, j’aime bien le planning meeting, mais un planning meeting « lean » adapté à la typologie du projet et non une vision rigide, voir tayloriste, de celui-ci !

Ressources

[1] : Agile Software Development with Scrum – Ken Schwaber & Mike Beedle – Prentice Hall / series in agile software development 2001 – ISBN: 0-13-067634-9 ; p. 46

[2] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3 ; p. 94

[3] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 8

[4] : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3 ; p. 338

[5] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3 ; p. 40

[6] : Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today – Dave West – Forrester 2011 ; p. 9

[7] : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6 ; p. 28

[8] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4 ; p. 157

[9] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[10] : Leading Lean Software Developemnt – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[11] : The Scrum Guide – Ken Schwaber & Jeff Sutherland – Scrum.org 2013 ; p.10

[12] : The People’s Scrum, Agile ideas for revolutionary transformation – Tobias Mayer – Dymaxicon 2013 – ISBN : 978 1 937 965150 ;p. 49

[13] : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M

[14] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[15] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

En finir avec les estimations ?

Poker, Fibonacci et stock

Aujourd’hui j’aimerais parler d’estimations. D’estimations agiles, bien sûr. Elles n’ont rien à voir avec les estimations classiques. Ou du moins, pourrait-on le croire. Voyons cela !

L’un des points marquants souvent évoqué est que l’estimation n’est pas faite par une seule personne, mais par l’ensemble des membres de l’équipe, afin de bénéficier de la sagesse de la foule. En fait, l’estimation collective est utilisée depuis longtemps dans les approches classiques et est connue sous le nom de wideband Delphi. Il est vrai toutefois que la technique est sous-utilisée, beaucoup de chefs de projets préférant « optimiser » le temps nécessaire aux estimations ou ignorant simplement cette technique !

L’autre élément majeur est l’utilisation d’estimations relatives, décorellé d’une estimation en charge. Une approche déjà utilisée dans le Function Point Analysis. Ici l’approche agile se distingue par l’utilisation d’une échelle de précision adaptative qui a donné lieu aux fameux jeux de carte du planning poker

image

Il reste 2 points à soulever : un point de divergence et un point de convergence avec les approches classiques.

Tout d’abord la divergence. Les approches type Cocomo et FPA tentent d’estimer en comparant les sous-éléments techniques des briques à réaliser. Les briques elle-même étant plutôt de taille importante, d’où la nécessité d’opérer une subdivision. Les approches agiles travaillent aussi par comparaison, mais elles s’évertuent à subdiviser l’élément fonctionnel. Il n’est alors plus nécessaire de décomposer celui-ci en sous-éléments techniques. Bien sûr l’approche agile s’appuie sur le postulat que la solution qui sera retenue va être proche de celle utilisée pour la fonctionnalité référents. Mais cela ne va pas aussi loin que dans le cas d’une décomposition technique qui vérrouille complètement les postulats techniques !

Maintenant la convergence. Il y a bel et bien quelque chose que l’approche classique et l’approche agile appréhendent à l’identique : toutes deux s’efforcent d’évaluer une charge ou une complexité (mais est-ce si différent ?) d’un ensemble de choses à réaliser.

Finalement, la logique de l’estimation agile telle que nous la connaissons ne diffère guère de l’estimation classique : on nous demande de réaliser des pans de fonctionnalités pour lesquelles on nous demande d’estimer si c’est gros ou si c’est petit… Une question qui devrait nous donner à réfléchir concernant une approche où l’on prétend maximiser la valeur ! On dirait plutôt que nous voilà cernés dans une discussion pour optimiser la main d’oeuvre, ce n’est certes pas la même chose. Il est vrai que les prétentions « d’hyperproductivité » de Scrum vantées par Jeff Sutherland n’aident pas tellement à changer le focus du discours…

Ce qui ne va pas dans cette approche

Il y a un certain paradoxe à travailler en itérations « time-boxée » afin d’optimiser la valeur produite à chaque itération, et estimer la taille des fonctionnalités à délivrer.

D’un côté, le découpage temporel de la planification contraint le temps afin de permettre la mesurer de valeur par unité de temps. Mais de l’autre côté, la manière dont nous appréhendons les tâches nous conduit à focaliser la discussion sur la charge et le plus souvent à trouver des options pour la réaliser à l’économie. L’estimation agile ne nous invite pas à :

  • Rechercher la partie réellement porteuse de valeur dans une fonctionnalité présentée.
  • Découper une fonctionnalité en ensemble élémentaires d’apprentissages et d’hypothèses.
  • Rechercher comment obtenir du feedback le plus rapidement possible sur l’hypothèse la plus importante.

La logique estimative ne nous aide pas tellement dans notre quête de la maximisation de valeur. Mais cela ne s’arrête pas là. Elle est aussi un handicap sur plusieurs sujets :

  • En associant (comme Scrum le fait) l’estimation et l’engagement.
  • En donnant prédominance à la logique de coût et en autorisant de fait celle-ci à devenir un vecteur de priorité.
  • En nous enfermant dans une logique de périmètre (et les fermetures de choix associés).
  • En permettant une logique des « gros morceaux » qui reporte une partie des responsabilités sur l’équipe de développement.

Enumérés ainsi, ces sujets paraissent certainement un peu mystérieux. Ils ne vont pas le rester longtemps, il est temps de nous y attaquer !

Estimation et engagement

Je me suis longtemps battu contre l’idée qu’une estimation n’était pas un engagement. Dans les projets classiques, j’ai beaucoup illustré ce propos avec le cône d’incertitude [1], bien que cette représentation folklorique ait été ensuite un peu secouée par Laurent Bossavit [2].

image

Cette représentation met l’accent sur un facteur important : l’interval de confiance est plus large quand on a peu d’éléments sur le sujet, il se resserre ensuite progressivement en même temps que notre capacité d’extrapoler sur ce sujet s’améliore. Bien sûr, cet effet est beaucoup plus marqué pour les projets classiques et plus spécifiquement pour les projets non itératifs.

Je pensais m’être débarrassé de l’interprêtation « estimation = engagement » avec les projets agiles. Apparemment, pas tout à fait. Car si l’on commence un planning meeting scrum par des estimations, il se termine le plus souvent par une bonne vielle règle de trois qui nous donne l’engagement de l’équipe en fonction de sa vélocité. La traduction française de « commitment » qui peut donner engagement ou implication n’aide pas tellement quand on prend le premier choix. Par ailleurs, les derniers textes sur Scrum ont pris conscience de ce travers et préfèrent parler d’engagement (ou implication) sur l’objectif.

Bref, l’estimation est bien l’outil de choix pour enchainer l’équipe au banc de rame. Il faut dépoter de la fonctionnalité, la valeur de cette charge (ou de cette complexité, peu importe) n’est pas le sujet. On est bien dans une logique à l’ancienne !

Quand c’est pas cher, c’est prioritaire !

Prioriser n’est pas un acte facile. Du moins en principe. C’est la ligne d’arrivé d’un processus intégrant des dimensions telles que stratégie d’entreprise, opportunités marché ou développement client. Il n’est pas rare que ces tableaux de bord soient flous voir inexistant. Pourtant il faut prioriser.

C’est souvent dans ces situations qu’intervient le « si je n’ai pas d’estimation, je ne peux pas prioriser ». Ce n’est pas illogique de chercher à prioriser en terme de ROI simplifié (valeur/coût). Mais ça l’est d’éliminer le terme valeur ou de normaliser en prétendant que « tout a la même valeur », signe que quelqu’un ne fait pas son travail…

A partir de là, le travail de priorisation devient une pantalonnade allant de « on va commencer par ça, c’est pas cher » au marchandage du type « je ne comprend pas pourquoi c’est si cher… ».

image

Là encore, on aboutit hélas parfois à des interactions qui ne sont pas vraiment différentes de ce que l’on faisait avant…

Une affaire de périmètre

L’estimation, qu’elle soit en charge ou en complexité, nécessite que l’on arrête un certain nombre de postulats. Ce faisant, on arrête très tôt dans notre processus de conception les options que nous aurons choisi. Du moins, on ne les fixent pas s’il s’agit d’estimations, mais si l’on parle d’engagement…

C’est bien dommage. Car l’adaptabilité devrait être un trait dominant des projets agiles ! En réalisation, cela passe par des pratiques telles que les options réelles [3] ou le « set-based design » [4], [5] et [6]. Ce n’est pas strictement impossible de changer son fusil d’épaule en cours de route, mais les discussions gravitant autour des estimations de taille rendent cela bien plus difficile…

Au-delà des estimations que l’on fait pour l’itération, il y a celles concernant la totalité du projet. Car le plus souvent il faut en passer par là. A moins que le projet fasse l’objet d’un financement récurrent ou qu’il soit en autonomie de financement (ce qui revient à peu près au même), les décideurs ont besoin de savoir quelles sommes devront être engagées sur le projet. C’est normal. Là encore, l’outil ad-hoc est l’estimation. Mais il y a quand même deux façons d’appréhender cela.

On peut faire ça à l’ancienne : on prend le backlog, on met des chiffres en face de chaque élément de backlog et c’est notre feuille de route. Bravo : notre enfermement dans des postulats vient d’atteindre un nouveau niveau. Nous voici prisonniers dans notre périmètre de réalisation.

image

Oh bien sûr on nous proposera « d’accueillir le changement » car on est dans un projet agile. Mais dès que le vent tournera, on verra resurgir le chiffrage initial. Dans ces conditions autant contrôler les changements à l’ancienne, via un « change control board ». De toute manière, de tout ceci émanent des effluves pas vraiment neuves. Et utiliser des cartes de planning poker pour cela n’y change rien !

L’autre méthode consiste à utiliser le chiffrage initial pour dimensionner une enveloppe de financement … puis oublier ce chiffrage pour concevoir et réaliser le produit de manière réellement émergente, en exploitant à chaque itération les connaissances acquises.

Découper, ça c’est votre affaire

Si les approches agiles et Scrum en particulier [7] promeuvent le découpage fin des fonctionnalités, elles ne mettent pas réellement en place de contraintes en ce sens, si ce n’est la taille des itérations ! Mon propos n’est donc qu’une fonctionnalité ne doive pas dépasser une itération (j’ai hélas vu des équipes mettre jusqu’à 3 itérations pour produire une « story » !), non ce découpage doit être fin, bien plus fin.

image

Mais ça ne vient pas tout seul.

En fait, sans la motivation appropriée, il est bien plus aisé au product owner de garder les fonctionnalités à grosse maille, souvent en arguant « qu’il faut tout, de toute façon ! ». Si c’est plus facile de découper pour l’équipe de réalisation, qu’ils le fassent ! Dans le registre lâche, j’ai même entendu parler de « détail d’implémentation » !

Je ne vais pas débattre ici des vertus du découpage des fonctionnalités pour les projets agiles. Mais la logique d’estimation de taille, si elle ne nuit pas ici, n’est pas non plus d’une grande aide.

Ma véritable estimation agile

Assez ronchonné sur les pratiques d’estimation ! Si mes récriminations doivent servir à quelque chose, c’est à comprendre ce que je veux obtenir d’une véritable pratique d’estimation « new style » !

  • Pouvoir me focaliser sur la valeur lorsque l’on évalue la priorité des fonctionnalités. Et pour cela, il ne faut pas que la question de la taille vienne brouiller les cartes !
  • Ne plus considérer le périmètre d’une application comme un ensemble de fonctionnalités à négocier, mais comme un (voir plusieurs objectifs) auxquels je subordonne des hypothèses qui sont autant d’options sur lesquelles je n’ai pas besoin de trancher à l’avance.
  • Et au passage revisiter la notion d’engagement, abandonner les réestimations de reste à faire…

Ouvrons le bal !

Size-boxing

Nous avons évoqué précédemment la technique de priorisation par le ROI. Un grand classique : V/C ; Ainsi à valeur égale, la fonctionnalité la moins couteuse est la plus valable. Sauf que nous avons aussi souligné le travers consistant à sortir la valeur de l’équation. C’est un travers que je comprend aisément : ce n’est pas facile à appréhender la valeur, sauf dans certains contextes précis, et guère plus facile à mesurer quand ce n’est pas directement ou pas uniquement rattaché à une valeur faciale. Nous reviendrons sur cette question de la valeur un peu plus tard.

La solution la plus simple pour éviter le travers est de sortir « C » de l’équation. Il ne reste donc plus que la valeur qui du coup ne peut plus être ignorée. Un seul moyen : standardiser la taille, ou tout au moins travailler avec des tailles de fonctionnalités à réaliser assez semblables ! L’estimation de taille n’est d’ailleurs pas porteuse de valeur en elle-même [8], elle ne sert qu’à nous donner une idée de notre capacité afin de mettre notre processus sous contrôle.

image

Ainsi, de même que nous planifions avec une contrainte de temps (notre itération), mous devrions estimer avec une contrainte de taille. Nos interactions deviennent alors :

  • Comment découper la fonctionnalité souhaité pour la faire tenir dans ma contrainte de taille ?
  • Comment m’organiser en équipe afin d’accommoder cette contrainte de taille ?
  • Quelles décisions de structuration et d’architecture dois-je prendre pour rendre cela possible ?

Subordonner le périmètre au « pourquoi »

Réfléchir à la question du périmètre produit en terme de liste de fonctionnalités et de ce qu’on y ajoute et/ou retranche n’est pas agile. Cela m’oblige à penser en terme de stock et m’en encombrer l’esprit. J’avais évoqué ce point lorsque j’avais parlé du backlog. A ce processus mental qui m’ancre dans mes anciennes idées, je préfère travailler à partir d’objectifs, évaluer et tester mes options relatives à ceux-cis, et itérer. Mais pour ce faire, nous devons nous libérer du mode de pensée qui lie ensemble le budget et la liste des fonctionnalités. Désolé Scrum, mais le « backlog estimé » en est justement l’illustration !

La valeur métier, c’est quoi ?

On le dit et on le repète : l’agile est fait pour se focaliser sur la valeur métier. C’est fort bien dit et en en a plein la bouche, mais c’est quand même rudement abstrait, surtout quand on ne peut pas directement lier le produit ou le projet avec une dimension financière.

Je sors un peu du cadre de mon propos, mais je ne pouvais pas non plus complètement éluder la question.

La valeur ce n’est pas (seulement) des considérations de ROI, il s’agit plutôt d’un cocktail qui intègre plusieurs ingrédients pour former un modèle de valeur [9]. Prenons celui-ci, par exemple :

image

Il s’agit en fait plutôt d’un métamodèle. Il vous invite à construire votre propre modèle, basé sur 3 dimensions :

  • La finalité : elle n’est pas nécessairement purement financière. Il peut s’agir de donner une visibilité ou une image à l’entreprise, de se donner une avance technologique ou de tester un nouveau marché.
  • Les considérations, qui sont les facteurs intrinsèques ou extrinsèques difficilement quantifiables mais influençant vos décisions.
  • Les coûts et bénéfices du projet.

Chaque modèle de valeur est unique, il combine et priorise les éléments construits sur ces 3 axes.

Pour y arriver

Finalement, c’est probablement l’élément le plus facile, car nous avons déjà amené une bonne partie des éléments de réponse.

Tout d’abord, ne plus se servir du budget pour contraindre notre périmètre, mais partir du pourquoi et subordonner le périmètre à ce pourquoi à l’aide d’outils comme l’impact mapping [10].

image

Changer de logique d’estimation : plutôt que d’estimer la taille d’une fonctionnalité de périmètre donné, ré-orientons nos discussions pour estimer le périmètre des fonctionnalités afin de les faire tenir dans une taille donné, en gardant l’objectif dans notre ligne de mire ! C’est là un changement de paradigme fondamental, et il nécessite une façon de faire différente. L’occasion pour moi de développer cela un jour prochain, j’espère !

Changer de logique de processus. Kanban nous apprend à penser différemment: plutôt que de réfléchir en terme de stock, il nous conduit à penser en terme de « slot » de demandes disponibles qu’il suffit d’alimenter par ce qui est le plus prioritaire. Mais Kanban n’est pas une réponse suffisante quand on parle produit, car il focalise sur des questions de « capacité » et de SLA et non sur un objectif et la valeur, des aspects sur lesquels il est agnostique.

Doit-on arrêter d’estimer, comme peut le laisser croire (ou le laisser interpréter) le mouvement « no estimates » ?

Alors l’estimation, c’est mal ?

La réponse (aux deux questions précédentes) est : non ! Nous avons toujours quelque chose à estimer, mais il faut tourner cette estimation dans la bonne direction pour obtenir le résultat que nous voulons. Il faut estimer pour :

  • Individualiser les hypothèses et les relier à notre modèle de valeur.
  • Générer des idées et des options, fonctionnelles ou techniques.
  • Etre en mesure d’avancer par petits pas pour obtenir du feedback rapidement et mettre notre processus de développement sous contrôle.
  • Générer des interactions entre les acteurs du projet.

Nos estimations ne doivent pas nous conduire à :

  • Se débarrasser du problème sur l’équipe de réalisation.
  • Nous conduire à des marchandages entre les acteurs du projet
  • Nous enfermer dans une réincarnation du cahier des charges que l’on ne peut plier qu’à force de négociations.

La route est longue…

Références

[1] : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1 ; p. 37

[2] : The Leprechauns of Software Engineering – Laurent Bossavit – Leanpub 2013 ; p. 13

[3] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[4] : Leading Lean Software Development – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[5] : Lean Software Development, An agile toolkit – Mary Poppendieck & Tom Poppendieck – Addison Wesley / ASD series 2003 – ISBN: 0-321-15078-3 ; p. 38

[6] : Implementing Lean Software Development, From concept to cash – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series 2006 – ISBN : 0-321-43738-1 ; p. 160

[7] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 196

[8] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[9] : Stand Back and Deliver, Accelerating business agility – Pollyanna Pixton, Niel Nickolaisen, Todd Little & Kent McDonald – Addison Wesley 2009 – ISBN : 978 0 321 57288 2 ; p. 98

[10] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0

Autres Ressources

Bientôt l’été !

J’en fais déjà une tradition : le blog va passer en régime estival. Essayons d’en dire plus.

Mon activité

L’an dernier, je vous avais fait part de gros changements. Ce ne sera pas le cas cette année, heureusement ! En fait, j’ai plusieurs petits projets personnels en cours ou à venir pour lesquels je dois me ménager un peu de temps. Mais il ne sert pas à grand chose d’en parler tant qu’ils ne sont pas arrivés à maturité.

Pour préparer la rentrée

Oui, il faut y penser dès à présent ! Il y a bien sûr des conférences et principalement la série des agile tours ! Le programme n’est pas encore fixé, mais je vise 3 présences sur ce dernier trimestre pas plus. Il reste à déterminer sur quels évènements.

Sur le blog

Malgré les sarcasmes de mes confrères, je suis bien décidé à vous relivrer mes notes de lecture has been (je pense à Pablo et Alfred, principalement…). J’en ai un paquet à écouler, donc ce ne sera pas la dernière année. Dans l’ensemble il devrait s’agir de textes accusant une vingtaine d’année environ !

Toujours dans la séquence nostalgie, j’ai aussi quelques articles écrits il y a une dizaine d’année d’année. J’attendais une opportunité pour les replacer : ce sera fait !

En finir avec…

Ce n’est pas très logique de sortir ce genre d’écrits à l’époque où la fréquentation baisse, mais je récidive dans cette voie.
Ce sont 5 opus que je vous ai livré sur les deux années précédentes. Ont déjà subi mon traitement impitoyable :

Je vise 3 sujets pour cet été. Cela parait peu, mais ces posts me demandent vraiment beaucoup de travail et de recherche. L’an dernier, je me suis même limité à deux ! Je vous laisse deviner les sujets que je me prépare à aborder. Vous pouvez laisser un commentaire si vous avez une idée.

L’été commencera le 1er Juillet ! A très bientôt.

2.0, I me mine (opus 2013)

Comme je l’avais fait sur les deux années précédantes(donc 2011 et 2012), voici mon l’état de mon usage du Web 2.0

Cette année écoulée est marquée des révélations de Snowden. La NSA a transformé l’Internet en source d’information, bien d’autres pays sont sur la voie. Je pensais déjà à ce que je met sur le Web en terme d’information pouvant être espionnée. Il faut se faire à l’idée que ce ne plus une question de pouvoir l’être, mais de l’être vraiment.

De moins en moins à plus du tout

Yammer : J’utilisais peu du temps du SUG. Je ne fais plus partie du SUG, donc maintenant c’est “plus du tout” !

Quora : J’utilisais peu. Là il faut que je l’avoue tout net, j’ai fait une année complète sans y aller. Donc, termeiné ? On verra…

Diigo : J’étais parti avec pas mal d’enthousiasme sur cet outil de bookmarking. Au final, je me suis lassé de continuer son utilisation.

Producteev : C’était un peu mon outil GTD. Des détails ergonomiques un peu crispant ont fini par avoir raison de ma pugnacité. C’est bien dommage. Peut-être essaierai-je un outil concurrent ?

Ideascale : Je l’avais fait figurer ici car j’étais au bureau du SUG. Depuis que je n’y suis plus, mon usage en est devenu anecdotique.

Pas plus, pas moins … mais peu

Google Doc : J’aimais pas avant, j’aime toujours pas ! Je l’utilise pour partager des choses avec des collègues, mais c’est tout, et contraint et forcé !

Google plus : C’est surtout un outil de notification pour moi. Parfois je lis des posts dans certaines communautés… en fait, ce sont bel et bien les communautés que j’ai tendance à trouver pratiques.

github : Ca ne fait pas terrible de dire ça, mais j’utilise très peu github. Juste un peu les gist…

Stackoverflow : Il est et reste le site incontournable pour répondre à n’importe quelle question de développement. Même si c’est rare, je cntinue à en faire l’expérience !

Trello : Quelques boards personnels et quelques boards professionnels. Je garde un rythme modéré mais réel sur l’outil.

Meetup : Je n’administre plus le meetup du French SUG, mais je reste connecté à 3 ou 4 groupes qui y organisent leurs rencontres.

Slideshare : Là non plus, ce n’est pas un site que je fréquente régulièrement. Juste pour y poster mes présentations 4 ou 5 fois par an…

Disqus : J’ai connecté mon blog à Disqus. Mais pour être honnête, j’ai très peu de commentaire par ce biais. J’en ai bien plus par LinkedIn d’abord, et par Google plus ensuite !

Capitaine Train : La plupart de mes déplacements en train sont pris en charge par l’entreprise. Mais j’utilise bien volontier cet excellent service quand je dois le faire moi-même. Donc peut-être 2 fois par an ou quelque chose comme ça…

Viadeo : Le LinkedIn Français est un incontournable. On y accepte des contacts, j’y notifie les posts de mes blogs (ça ne semble pas porter beaucoup…). Et dans tout ça, mon profil n’y est même pas à jour !

LinkedIn : Si Viadeo est le LinkedIn Français, LinkedIn est le Viadeo international. J’entretiens avec beaucoup d’attention mes contacts. Et mes informations y sont à jour. L’un dans l’autre, je l’utilise un petit peu plus que Viadeo, également pour les notifications de post. Mais ce n’est pas mortel quand même…

Pas plus, pas moins … mais plutôt pas mal

Dropbox : Le stockage en ligne reste un de mes très gros usages. J’y stocke vraiment beaucoup de choses. Bref, usage quaotidien et intensif. Aussi bien “pro” que “perso” !

Evernote : Je suis toujours un utilisateur intensif de DropBox. Et même si cela ne se justifie pas toujours pas, j’ai désormais un abonnement Premium. Et aussi un Livescribe (sur lequel je ferais bientôt un post). Bref, je l’utilise quotidiennement : usage professionnel, personnel, brouillons de mes posts (y compris celui-ci), etc.

GMail : Il faut bien l’avouer, aujourd’hui pratiquement tous mes mails sont sur GMail. Autant pour la confidentialité…

Twitter : Il s’agit surtout d’un usage pro, qui tourne autour de la thématique de l’agilité. C’est aussi pour moi un outil de notification. Pour moi, le web “social” tourne presqu’exclusivement autour de Twitter. Bien que je ne sois pas un fondu des réseaux sociaux…

Tumblr : Mon volume de posts est disons … intéressant. Avec plus de 200 posts par an, on peut dire que c’est une plateforme que j’utilise intensivement !

Plus aujourd’hui qu’hier

Flickr : Depuis que j’ai fait l’acquisition d’un appareil numérique digne de ce nom (un Olympus Pen), mon volume de photo a bien grimpé. Notament lors des évènements pro. Je poste toutes mes photos pro sur Flickr, ne serait-ce qu’à cause du redimensionnement qu’effectue ce service pour faire rentrer mes prises de vues dans le blog. Ce redimensionnement est réellement d’excellente qualité.

Dashlane : J’ai pratiquement cessé d’avoir un même mot de passe pour plusieurs services. J’ai aussi arrêté les mots de pase triviaux. Tout cela grâce au coffre-fort électronique. Esérons que la confidentialité affichée soit réelle … et que le service dure très longtemps !

Issuu : J’utilise désormais exclusivement ce service pour partager des PDF sur mon blog (malgré un techno Flash…). Donc de plus en plus, que ce soit pour mes propres textes, ou d’autres du domaine public que je souhaite partager.

Les nouveaux venus

Goodreads : Le seul nouveau venu de l’année écoulée ! Goodreads permet de partager sa liste de lecture et de consulter celles des autres. Bref, tout ce que l’on a envie d’échanger sur la lecture !

Donc peu de grosses nouveautés pour cette année. En fait, j’ai même un peu fait le ménage. A l’année prochaine !

L’agilité, une question de feedback

J’avais évoqué, lors d’une présentation en 2012, la question du feedback et son rôle majeur en tant que moteur de l’émergence.

J’aimerais revenir sur ce sujet qui me tient à coeur et le développer plus avant ici. Je vais aussi tenter de lui donner, modestement, un petit éclairage historique.

Les boucles du feedback

Pourquoi focaliser sur le feedback ? En fait, nous pouvons interpréter une grande partie des pratiques d’ingénierie et de projets agiles sous forme de boucles de feedback imbriquées. c’est ce que j’avais fait lors de mon lightning talk sur l’émergence. En voici l’illustration.

La Boucle de feedback

Nous reviendrons sur cette illustration un peu plus tard. Car on peut aussi présenter ces boucles  de feedback autrement. Elles ne sont pas le fruit de ces 10 dernières années. L’émergence progressive de ces boucles de feedback a commencé il y a bien longtemps. Longtemps avant que l’on parle d’agilité.

Un regard historique sur les boucles de feedback

Compilation interactive

La plupart d’entre-vous n’avez pas connu cette époque, mais vous savez certainement qu’il fut un temps on l’on saisissait les programmes sur ceci

Punch Card

Chaque carte représente une ligne de code, plus exactement 80 colonnes de texte. Le processus est le suivant :

  • On écrit son programme sur papier.
  • Dès qu’on l’a rédigé (et vérifié, croyez-moi, c’est mieux), on va le saisir sur un terminal produisant une carte par ligne de texte.
  • On donne la pile de cartes au centre de calcul. Ce dernier va programmer sa compilation et son exécution. Ce ne sera pas pour tout de suite, probablement dans quelques jours.
  • Quand le job est passé … on vous donne le résultat … ou pas !

Une de mes anciennes collègues m’a ainsi racontée qu’elle a reçu un jour en retour sa pile de cartes entourée d’un élastique et d’une note rageusement libellée : “fait planter la machine !”. 

Une anecdote hélas probablement pas si rare que ça…

J’ai à peine connu cette époque. mais à mes début, j’empruntais un ordinateur de poche 2 jours par semaine. Je n’avais que ce créneau à ma disposition pour saisir et tester les programmes que j’avais écrit sur papier pendant le reste de la semaine. C’est un peu le même cas de figure.

Cette période est révolue depuis longtemps. Au début des années 80 nous sommes passé de la compilation batch à la compilation interactive. Ou à peu près. On est passé de délais de feedback de quelques jours à quelques minutes (et quelques heures dans le cas de gros projets)

Coloration syntaxique

Il y a certes eu de discrets essais sur des environnement confidentiels dans les années 80 et même avant, mais comme beaucoup j’ai découvert la coloration syntaxique avec un IDE mainstream : Borland C++, au début des années 90.

Je me souviens avoir assisté à la présentation de lancement de l’IDE. Le public a littéralement réagit à la seconde où le présentateur a dévoilé la fonctionnalité.

Coloration syntaxique

C’est le feedback sur la syntaxe d’écriture du programme que cette fonctionnalité adresse. Passer de quelques minutes, c’est à dire le délai entre deux compilations, à quelques secondes est une amélioration conséquente.

Complétion de code

De la coloration à la complétion, il n’y a qu’un pas. C’est le feedback sur notre implémentation que cette fonctionnalité adresse en nous proposant les méthodes disponibles.

Code completion

Vous allez me dire qu’il ne s’agit pas de feedback ici. Vous avez raison. C’est mieux, cette fonctionnalité anticipe le feedback, le rendant inutile. Disponible assez tôt dans les environnements Smalltalk, il faudra attendre la moitié des années 90 pour voir cette fonctionnalité se démocratiser.

Compilation continue

Egalement amorcé par Smalltalk, c’est dans Visual Age Java que j’ai vu pour la première fois cette fonctionnalité faire son apparition, vers la fin des années 90. Cette fois c’est la justesse grammaticale sur laquelle le feedback passe de quelques minutes à quelques secondes.

Agilité et feedback

J’ai dit que nous reviendrions sur l’illustration des boucles de feedback. Nous allons le faire. Mais pourquoi s’intéresser au feedback, en quoi ce mécanisme est-il important et si particulier à la pensée agile.

Parce qu’en tant qu’être humain, et même en fait en tant qu’organisme vivant, c’est notre principal mécanisme d’adaptation. Et l’adaptation au changement, ça figure quelque part dans notre manifeste agile, j’en suis pratiquement sûr…

La rétrospectives

Cette pratique n’est pas à proprement parler nouvelle. les rétrospectives de projets (alors appelés post-mortems) ont probablement plusieurs décennies d’existence. En quoi est-ce différent ici ? Pourquoi faire des rétrospectives plus souvent ?

Agile retrospective

La rétrospective est le mécanisme d’adaptation de notre processus. Un post-mortem de projet sert surtout à se lamenter, la rétrospective d’itération sert à adapter notre processus et nos pratiques agiles.

Cycles itératifs

J’entends souvent les équipes parler de “lotir” les itérations. C’est ce que l’on fait dans les processus itératifs. Seulement le lotissement n’a rien à voir avec l’adaptation.

Le cycle itératif agile utilise ce que l’on a appris de l’itération qui vient de se dérouler pour réévaluer les priorités et la pertinence des items figurant dans le backlog ou comme opportunité d’émettre de nouvelles idées, d’aller plus loin dans les fonctionnalités venant d’être développées.

Acceptance tests

Nouveau venu de nos pratiques agiles, le test d’acceptance nous permet d’avoir du feedback sur l’implémentation des stories, lorsqu’ils sont exécutés. Mieux encore lorsqu’on les écrit, ces tests d’acceptance donnent du feedback sur les user stories elle-même ! Ecrire des tests d’acceptance, c’est instancier les spécifications, lever les ambiguïtés, se décider sur les cas aux limites, générer de nouvelles questions.

Integration continue

Il y a un temps pas si lointain où l’intégration représentait une phase majeure, longue et risquée des projets. Le feedback sur le fonctionnement conjoint des différentes briques se faisait alors sur des cycles allant de 3 mois à deux ans.

C’est avec émotions que nous repensons parfois à ces périodes particulières des projets qui occupaient nos soirées et nos week-ends avec enthousiasme, au lieu de manger des chips et boire de la bière devant un match de foot…

Late integration

Avoir la température, non seulement sur l’intégration, mais sur la qualité du code et la couverture de test, cela fait aujourd’hui partie de notre quotidien. Next !

Tests unitaires

En parlant de quotidien, en voilà un sur lequel je ne vais pas non plus m’attarder : les tests unitaires nous donnent du feedback sur le fonctionnement du code : fait-il ce à quoi nous nous attendons qu’il fasse ? C’est aussi de l’acquis : next again !

Pair programming

On pense souvent au pair programming comme à une technique de collaboration. C’est vrai. Mais c’est aussi et surtout une technique de peer review en temps réel et en continue. Un feedback sur l’écriture de code et les choix de conception fait en temps réel.

Mais aussi …

Le feedback des pratiques agiles ne s’arrête pas là. Après tout, toutes ces techniques sont plus ou moins déjà identifiées comme des techniques de feedback.

Management visuel

Les projets agiles aiment s’afficher. C’est aussi une forme de feedback

  • De la part de chaque membre de l’équipe envers tous les autres.
  • De la part de l’équipe vers tous ceux qui souhaitent savoir ce qu’il s’y passe.
obeya

Lean startup et le validated learning

A plus grande échelle, le cycle agile peut servir à donner du feedback, non plus à l’échelle du projet, mais à celle du business. Lean Startup étend la portée des cycles de feedback au-delà du déploiement, jusqu’à l’usage du produit afin de vérifier les hypothèses produit : persévérer ou pivoter.

De la seconde à l’entreprise

L’agilité fonctionne en harmonie avec le feedback. Mieux, elle guide chaque action par cette simple interrogation : comment vais-je évaluer que je suis satisfait du résultat ? C’est la mise en oeuvre du PDCA de Deming depuis les cycles les plus courts jusqu’aux décisions les plus impactantes.