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.

Note de lecture : Serial Communications, A C++ Developer’s guide, par Mark Nelson

Note : 7 ; Bien que désormais obsolète (car concerne surtout Windows 16 bits), reste intéressant sur les principes de gestion des ports série.

Tant que je suis dans les antiquités…en voici une tout à fait honorable ! Certes ce livre a perdu une grande partie de son intérêt, d’abord avec l’arrivée du Windows 32 bit et de TAPI puis des infrastructures et librairies qui rendent aujourd’hui transparente les vicissitudes des protocoles de communication.

Cet ouvrage nous permet, aujourd’hui encore, de nous ressourcer sur la mise en œuvre des communications à bas niveau, là où les caractéristiques du matériel ne peuvent être ignorées ! Mais la bête est imposante : ce sont 600 pages qui se présentent à nous sur ce seul sujet, le tout en 11 chapitres ! Le premier d’entre-eux rappellera des souvenirs aux plus anciens d’entre nous, il aborde l’interface RS 232 C sur 64 pages. Tout y passe, depuis la norme du connecteur, la signification des signaux et les protocoles de transmission modem. L’électronique sous-jacente, les fameux UART sont évoqués, mais leur gestion fera l’objet d’un chapitre à part. Finalement les protocoles d’échange de fichier (Kermit, ZModem, etc.) clôturent le chapitre. C’était en quelque sorte le tour du propriétaire.

Le chapitre 2 s’articule autour de la définition de la classe C++ RS232 ; il s’agit d’un wrapper abstrait sur lequel peu de méthodes concrètes « intelligentes » sont implémentées. Essentiellement les fonctions de lecture et écriture. C’est un bel exemple de mise sous forme de classe d’un protocole, car tous les signaux de la norme apparaissent sous forme de méthodes virtuelles. A part cela le chapitre est peu passionnant, essentiellement constitué de listings.

Ce sont près d’une centaine de pages qui sont dédiées au chapitre 3, dévolu à l’implémentation de RS232C sur l’UART 8250. Toute la première partie expliquant le fonctionnement de l’UART est réellement très intéressante même si je regrette le peu qui est consacré au 16550, certes nettement moins rependu à l’époque, mais nettement plus intéressant. Hélas la seconde moitié du chapitre est de nouveau consacré à de fastidieux listings bien peu expliqués…

Le chapitre 4, shared interrupt device rompt la monotonie avec seulement 25 pages. Il est consacré à l’accès aux ports COM dans l’architecture PC via les 2 interruptions qui leurs sont dédiées (pour 4 ports en principe accessibles). Le code du handler et les principes de gestion sont clairement appréhendés. Des informations par ailleurs rares dans la littérature, pour ne pas dire plus.

C’est à un périphérique plus exotique qu’est consacré le chapitre 5 : le Digiboard ! C’est donc une nouvelle sous-classe de RS232 qui nous attend. Un chapitre dont je soupçonne qu’il tenait à cœur à l’auteur, mais qui n’a pas retenu mon attention.

Plus intéressant pour moi, mais hélas plus légèrement traité, le chapitre 6 nous propose une nouvelle sous-classe de RS232, mais cette fois en s’appuyant sur les primitives disponibles dans le BIOS. Seul 30 pages y sont consacrées et l’auteur aurait pu faire plus d’effort pour développer plus clairement les interruptions du BIOS et leur exploitation.

Au chapitre 7, le FOSSIL driver se voit lui aussi consacrer une trentaine de pages. La profondeur de traitement est à peu près la même que pour l’implémentation BIOS. Mais j’avoue encore une fois que l’aspect exotique de cette norme fait que le chapitre n’a pas retenu mon attention.

Nouvelle alternative au chapitre 8 : une implémentation sur les API Windows. Près de 50 pages sont noircies sur le sujet. Cela paraît mieux, mais à l’époque où ces informations étaient vitales pour moi, la profondeur des informations restait bien insuffisante. Mais au moins le livre fournit des informations d’exploitations de ces APIs, choses pratiquement indisponibles par ailleurs en 1993 !

Le chapitre 9 est long de 40 pages. C’est un changement, car on quitte la couche RS232 pour s’attaquer à la gestion des modems, avec les fameuses normes V24, V32 et autres et bien sûr le protocole Hayes. La question est bien traitée et fort clairement. C’est probablement la meilleure source d’information que j’ai pu croiser sur la question.

Au chapitre 10, on s’attaque aux transferts de fichier, avec les protocoles XModem, YModem et ZModem. La question ne m’intéresse guère et j’ai du mal à avoir un avis sur le chapitre. Le sujet semble bien traité et le listing de fichier une fois encore un peu longuet.

Le dernier chapitre du volume va s’intéresser à l’émulation de terminal. Le thème remplit 60 pages et ne semble guère passionnant tel qu’il est traité ici. On est beaucoup dans l’explication de texte du listing, fort peu sur la déconstruction du problème.

L’auteur a développé une petite librairie de classes multiplateformes, multi-modems et multi contrôleurs qui, ma foi, m’a bien fait de l’usage à son époque. Le livre gravite entièrement autour de cela ce qui rend parfois le propos un peu rébarbatif et les listings ennuyeux. Mais le volet technique est très affuté et ce fut très clairement la meilleure source d’information sur bon nombre de sujets qui y sont traités. Difficile de faire valoir une pertinence après presque 25 ans, pourtant le volume mérite d’être conservé à titre d’archive !

image

Référence complète : Serial Communications : A C++ Developer’s guide – Mark Nelson – Prentice Hall / M&T Books 1992 – ISBN : 0-13-011776-1

Serial Communications: A C ++ Developer's Guide : A Comprehensive Guide to Writing Serial Communications Applications Using Object-Oriented Techniqu

https://www.goodreads.com/book/add_to_books_widget_frame/1558512810?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Beyond Budgeting, avec Bjarte Borgsnes

En ce début Avril, le Lean Kanban France nous conviait à une rencontre avec Bjarte Borgsnes, le pape du Beyond Budgeting, si je puis dire. Tout d’abord, je dois saluer l’initiative de Samuel Retière qui a fait l’entremetteur entre le LKFR et la Société Générale pour rendre possible cette rencontre. En effet, Bjarte était en visite à la SG, non seulement il a su tirer parti de l’opportunité pour monter cette rencontre, mais celle-ci a pu être hébergé dans les locaux de la banque.

image

Seconde chose à noter, le LKFR qui jusqu’ici limitait son activité à la conférence du même nom qui a lieu chaque année à l’automne, se met à organiser des rencontres en soirées. D’autres sont d’ailleurs à suivre.

Beyond Budgeting

Bjarte n’est pas venu seul. D’autres intervenants sont au programme. A commencer par Anders Olesen, l’actuel directeur du Beyond Budgeting Institute !

image

Le Beyond Budgeting, c’est à la fois le nom d’un réseau et d’un modèle de management. Ce n’est pas non plus quelque chose de nouveau, car le Beyond Budgeting Institute existe depuis maintenant 15 ans !

Le Beyond Budgeting Round Table est une émanation de cette organisation, dont le but est de rassembler les organisations mettant en œuvre le Beyond Budgéting, de permettre et organiser le partage d’expérience.

Bjarte Borgsnes

Il y a un problème avec le management. Les organisations qui font la transition vers l’agilité ont besoin que change la posture du management. Le Beyond Budgeting est un moyen pour cela.

L’orateur nous propose une métaphore, celle des feux de circulation. Dans cette situation, la performance du système est entre les mains du programmeur (ou du managers, dans le cas présent). Son intention est bonne, mais hélas il n’est pas sur place. C’est un management basé sur les règles.

Le rond-point est sensé être plus efficace. Ici, on cherche à créer les conditions d’une bonne performance. C’est ce dont les entreprises agiles ont besoin : créer plus de « self-direction ». Le beyond budgéting s’oppose au management traditionnel orienté vers les systèmes statiques et la « théorie X » de McGregor (le contrôle) en étant orienté vers les systèmes dynamiques et la « théorie Y ».

Le contrôle est en fait de l’illusion de contrôle. Avoir l’information n’est pas synonyme d’être capable d’influencer. La transparence est un meilleur levier. L’exemple que nous donne Bjarte est assez connu : la gestion des notes de frais.

Chez Roche, plutôt que fixer des règles ou des limites aux notes de frais (cela me rapelle « cherchez les bottes » dans Liberté & Cie), on rend toutes les notes de frais de tout le monde (jusqu’au sommet de la pyramide) visibles à tout le monde (jusqu’en bas de la pyramide). Cela a fait baisser les coûts liés aux déplacements sans qu’il soit nécessaire d’édicter la moindre règle…

Le Beyond Budgeting combine 3 idées majeures :

  • Pas de budget.
  • Pas de cible budgétaire
  • Transparence totale

Il y a 12 principes sous-jacent. Comme le dit Bjarne, c’est assez volumineux, mais on n’est pas obligé de tout faire en même temps !

Gouvernance et transparence

Valeurs : rassembler les personnes autour d’une cause commune, pas d’un plan central.

  • Gouvernance : Diriger au travers de valeurs partagées et d’un jugement éclairé, et non par le biais de règles détaillées ni de régulations.
  • Transparence : L’information doit être ouverte et transparente ; Ne pas la contrôler ni en restreindre l’accès.

Des équipes responsables

  • But : Placer des but moyen-terme ambitieux, pas de buts court-terme fixes.
  • Récompenses : Baser les récompenses sur les performances relatives et non sur l’atteinte d’objectifs fixes.

Planning et contrôles

  • Planning : Faire du planning un processus continu et inclusif et non un évènement annuel imposé par le hiérarchie.
  • Coordination : Coordonner les interactions de manière dynamique et non au travers de budgets annuels.
  • Ressources :  Opérer l’allocation de ressources « juste à temps », et non « au cas où ».
  • Contrôles : Baser le contrôle sur une boucle de feedback fréquente et rapide, pas sur des écarts de budgets.

A l’image du manifeste agile, ce sont de grandes recommandations, et non des recettes.

La question du budget est bien évidemment au centre du Beyond Budgeting. Quelle est sa finalité ? En fait, elle n’est pas unique, elle est plurielle :

  • Fixer une cible
  • Établir un prévisionnel
  • Permettre l’allocation de ressources.

Pour Bjarte Borgsnes, cette vision budgétaire étriquée porte nombre de défauts.

Tout d’abord, les 3 dimensions citées ci-dessus doivent être décorrélées. Ce sont 3 données différentes.

Le processus budgétaire annuel est un non-sens. Une entreprise n’est pas ouverte un seul mois par an !

Les mesures seules ne valent rien. La façon dont nous délivrons la valeur a autant d’importance que ce que nous délivrons.

L’évaluation doit être holistique, ce qui n’est pas facile.

La transparence est un moyen de régulation beaucoup plus puissant que le contrôle, il fait appel à l’auto-régulation. Mais cela ne signifie pas pour autant avoir une posture naïve.

Jean-Michel Segui

Notre second orateur nous parle de l’adoption du Beyond Budgeting chez Schneider Electric. Disons simplement que ce n’est pas la PME de quartier, avec 25 milliards de CA et 70000 employés !

Tout d’abord 2 constats :

  • Le management du groupe se plaint de la lourdeur du processus budgétaire.
  • Il y a des réflexions sur les objectifs, qui sont fixés « en descendant », chaque strate de l’organisation ayant la responsabilité de reformuler ces objectifs à son niveau.

Le processus budgétaire doit faire 7 choses (j’ai oublié la 7ème) :

  • Fixer une cible
  • Établir un prévisionnel
  • Permettre la Planification
  • Fourbir un plan d’action
  • Planifier des actions
  • Gérer les récompenses

Il y a 2 phases dans ce processus : une phase stratégique et une phase opérationnelle.

La phase stratégique se déroule en 2 temps :

  • Le programme d’entreprise (sur 3 à 5 ans) issu de la direction générale et représentant l’engagement de l’entreprise par rapport au marché, mais sans un grand niveau de détail.
  • La stratégie opérationnelle, plus détaillée mais sans être exhaustive.

La phase opérationnelle concerne les objectifs que se donnent les départements, qui donne lieu à des itérations avec la direction sur 6 mois. Ces objectifs se déclinent jusqu’au objectifs individuels. Ils s’expriment sur plusieurs axes tels que :

  • La satisfaction client
  • L’augmentation du chiffre d’affaire
  • L’augmentation du cash

Le prévisionnel est géré séparément de l’objectif. Il fait l’objet d’une vision glissante à 5 trimestre (le carnet de commande couvre lui 3 à 4 mois).

Il m’a semblé que nombre d’éléments restent très conventionnels dans la façon dont Schneider Electric à mis en œuvre le Beyond Budgeting. C’est sans doute lié à une logique grand groupe difficile, voir impossible à casser et une logique marché / actionnariat qui va elle, complètement à l’encontre. Mais on voit qu’un certains nombre d’éléments vont dans le bon sens, comme la définition des objectifs par les entités qui en sont responsable.

En conclusion

Les grands principes du Beyond Budgeting s’inscrivent dans la mouvance du Stoos Network. Ce meetup me permet surtout de prendre la mesure de ma méconnaissance du sujet, et de me souhait de la combler…

ScrumDay 2015 : Scaling Dilemna, par Mary Poppendieck

Quand nous étions petits, nous étions fantastiques ! Maintenant que nous sommes plus gros … nous avons cessé d’être fantastiques. En fait, on ne communique plus aussi bien.

Quels sont les problèmes ?

  • La coopération
  • La complexité
  • L’état d’esprit
  • Le focus

Ce sont ces 4 points que Mary Poppendieck va développer dans sa keynote de ce second jour du ScrumDay.

Coopération

Quand l’entreprise grandit, on tend à l’organiser en silo. Et ça ne marche pas si bien que ça ! On peut prendre le problème dans l’autre sens, et mettre les fonctions (ou les fonctionnalités) en silo. Ce n’est guère mieux.

Bref, nous sommes plutôt doués pour fabriquer des silos, mais médiocre à franchir les franchir ! Ce que l’on cherche avec ces silos, c’est l’autonomie. Et elle apparait alors plus importante que la coopération. Coopération et autonomie apparaissent antinomiques : lorsque l’on travaille sur quelque chose de gros, on perd de l’autonomie. Si nous privilégions l’autonomie, la coopération est le facteur clé pour aborder la complexité, comme Yves Morieux le souligne dans sa conférence TED

Mary Poppendieck nous emmène vers les communautés auto-organisées et vers Elinor Ostrom qui identifie 8 règles de gouvernance des biens communs :

  • Définir une limite du groupe claire
  • Faire coïncider les règles gouvernant l’usage du bien commun avec les besoins et les conditions locales.
  • S’assurer que ceux qui sont affectés par les règles peuvent participer à la modification de ces règles.
  • S’assurer que le droit d’édicter des règles des membres de la communauté est respecté des autorités extérieures.
  • Développer un système, porté par les membres de la communauté, permettant de surveiller le comportement des membres.
  • Faire usage de sanctions graduées envers les violateurs de ces règles.
  • Donner accès à des moyens de résolution de problèmes à faible coût.
  • Une gouvernance à multiples niveaux.

Quelle taille de groupe est la plus pertinente ? C’est au nombre de Dunbar qu’évoque l’oratrice, celui évoqué dans le Tribal Leadership, et ses variantes :

  • Le cercle d’intimité : 3 à 5 personnes
  • Le groupe de sympathie : 7 à 10 personnes ; c’est la taille d’un groupe pouvant accomplir « quelque chose ».
  • Le groupe de chasse : de 30 à 70 personnes ; c’est la taille nécessaire pour construire un sous-système indépendant et indépendemment.
  • Le clan : de 100 à 150 personnes ; C’est la taille d’une compagnie, dans les organisations militaires.
image

Complexité

Pour aborder la question de la complexité, Mary Poppendieck nous parle de micro-services, en évoquant le livre de Sam Newman (que je n’ai pas encore lu).

Les micro-services fractionnent les ensembles complexes en petits systèmes indépendants (jusqu’à la base de données) qui ne font qu’une seule chose, mais bien. « small » est bien le mot d’ordre pour les micro-services :

  • Petit services qui font une seule chose, mais bien. Nous l’avons dit.
  • Petites équipes, capables de prendre en main un service, depuis la compréhension du besoin avec les équipes métiers, jusqu’au suivi en production, en passant bien évidemment par la construction et le déploiement. qui s’effectue indépendamment des autres briques du SI.
  • Petites itérations et petit coût de démarrage: de zéro à une première étape en 3 semaines !

L’aptitude à réaliser des microservices a des corolaires.

  • Pas de couplage avec les autres briques du SI (nous l’avons évoqué).
  • Automatisation extensive des opérations : tests, intégration, déploiement.
  • « canary release » qui permet de pré-tester le système en situation réelle.
  • Continuous delivery et aptitude a être toujours « prêt au déploiement ».
  • Equipes pluridisciplinaires.

Etat d’esprit

Le focus sur le projet a fait son temps ! Place au focus sur le produit !

Vous êtes focalisés sur « le métier » ? Ce n’est même pas un concept … et pendant ce temps on laisse filer le focus sur le client… Il faut changer de regard.

  • Passer du focus métier au focus client
  • Passer du gestionnaire de projet à l’entrepreneur leader.
  • Migrer du développement qui execute les commandes à une équipe proposant des réponses.
  • Ne plus faire des choix sur les planning, mais sur les marchés.
  • Abandonner la mentalité « centre de coût » pour un état d’esprit « centre de produit ».

Dans son livre Inspired, Marty Cagan localise la création de grands produits à l’intersection de la valeur, de l’utilisabilité et de la faisabilité ! Pour donner vie à cette vision, il faut 3 personnes d’agal statut, l’un d’entre-eux est le « product manager », qui n’est pas un Product Owner : son rôle n’est pas d’écrire des User Stories ou de concevoir la solution, mais d’être un canal direct avec le client.

Focus

C’est se focaliser sur les bonnes questions. Et comme l’a popularisé Simon Sinek, cela commence par « pourquoi ? ».

La bonne question n’est plus « comment maximiser la valeur » ? » mais « comment maximiser l’impact » et trouver les métriques qui nous montreront que nous allons dans la bonne direction. C’est l’essence même du Lean Startup.

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