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 ?

Lire la suite

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 !

Lire la suite

Rendez-vous au Scrumday 2015 !

Le grand rendez-vous de la communauté Agile / Scrum

Que ce soit comme organisateur ou comme orateur, je n’ai encore jamais raté une édition du Scrumday ! Il en sera de même cette année. Mais c’est plutôt aux nouveaux venus que je m’adresserais cette fois-ci avec ma session Scrum Shu Ha Ri. J’avais donné celle-ci une première fois au Printemps Agile à Caen () il y a un an. Je l’ai produite une seconde fois en Anglais à Beyrouth au mois de novembre. Ce sera donc la 3ème fois que je produirais cette présentation. Non seulement ce sera probablement la dernière, mais pour ne pas trop me répéter, je ferais quelques retouches au contenu. Je devrais donc aussi faire évoluer l’article ( en conséquence…

En attendant, voici le teasing de cette session.

Scrum Shu Ha Ri
Passer à l’agilité ce n’est pas “faire de l’agile”, c’est être agile, devenir agile. Ce n’est pas une destination, mais un voyage. Scrum nous accompagne remarquablement sur les trois grandes étapes de ce voyage : le Shu, le Ha et le Ri.
Le Shu est apprentissage : appliquer correctement Scrum.
Le Ha est perfectionnement : Adopter des pratiques pour s’améliorer.
Le Ri est maîtrise : créer sa façon d’être agile en se guidant sur les valeurs de l’agilité.
Pour les nouveaux venus, cette session fera découvrir Scrum sous des jours différents au long des étapes qui constituent ce voyage.

Agile en grand !

C’est avec grand plaisir que je vois la session « Agile en grand » figurer au programme. Il s’agit d’un retour d’expérience sur le passage à l’agile du programme Linky ! Encore un REX allez-vous me dire ? Mais j’ai toutes les raisons de penser que la session que nous proposeront Jean-Hugues Hamelin et Nadim Elbaba sera bien autre chose que « encore un autre REX » !

J’accompagne aujourd’hui encore très activement ERDF sur l’agilification de ce projet sur le site Parisien. Ce sera donc un plaisir tout particulier pour moi d’y assister. Et dès maintenant je vous recommande de l’inscrire à votre programme de la journée.

Ah, une dernière chose !

N’oubliez pas que la seconde journée est consacrée à un open-space. J’ai l’idée d’y poursuivre l’aventure « en finir avec.. » à cete occasion. Mais je ne vais pas en dire plus !

Rendez-vous au Scrumday 2015 !

Soirée « en finir avec… »

Cela faisait déjà un petit moment que je pensais à ma petite soirée mégalo à moi. Oh, surprise, elle a fini par avoir lieu ! Nous nous sommes donc retrouvé ce Jeudi 29 Janvier chez Zenika autour de ce thème. Cette fois, ce ne sont pas les intempéries, mais une grève inopinée des transports qui ont eu raison de l’enthousiasme de 2/3 des inscrits. Heureusement pour nous le format d’atelier que nous proposions se prêtait bien à un groupe plutôt restreint, une vingtaine de personnes.

Bon, c’est ma soirée, c’est donc à moi de faire l’ouverture !

Pas de répit pour les braves, on enchaines avec les propositions et les choix de sujets !

Lire la suite

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

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.

En finir avec la démo ?

Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?

La démo, puisqu’il le faut…

La démo ? C’est bien !

Crowd waving

La démo, c’est vraiment bien !

La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.

Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !

Mais ce n’est pas le cas.

En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.

Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :

  • Ceux qui sont heureux d’aller à la démo.
  • Ceux qui appréhendent la démo.

En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.

La démo c’est cool, on va pouvoir montrer ce que l’on a fait !

Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.

Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !

J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :

L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?

Ce qui est considéré comme terminé doit correspondre à la “définition of done”.

Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !

Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.

Bonjour, je voudrais voir mon burndown chart

Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.

Illustrons cela par un bon vieux burndown chart.

Burndown Chart de la démo

Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.

Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.

En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !

Grâce à la démo, retrouves le charme oublié du “cycle en V” !

En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.

En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.

La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !

Cette pente glissante se traduit par deux symptômes étroitement liés:

  • Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
  • Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.

Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.

Continuous integration

Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.

Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !

Direction le tribunal

Parfois, la revue de Sprint, cela ressemble à ça :

Cours de justice

Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.

Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.

On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :

  • Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
  • Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
  • Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?

De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.

Revue de sprint ou réunion de spécification

“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.

Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.

Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.

Micro-démo

Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.

N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.

Voici la recette dans les grandes lignes:

  • La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
  • Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
  • On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
  • S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
  • Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.

Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.

Mais alors, a-t-on encore besoin de la démo ?

La substantifique moelle de la revue de sprint

La revue de sprint, ce n’est pas seulement la démo. C’est aussi :

  • Exposer la vélocité de l’équipe [Aubry12], p. 125
  • Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
  • Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.

Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?

En fait, oui !

Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.

Une question de boucle de feedback

En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.

Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.

Alors, la démo, c’est mal ?

La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :

  • De montrer l’avancement du produit à un public large.
  • De collecter du feedback global sur l’itération et l’état du produit.
  • De mettre les pièces du puzzle ensemble

Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !

Références

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

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

En finir avec le Scrum Master ?

Le quatrième volet de notre série va nous conduire du côté du Scrum Master. Dans l’épisode précédent (l’été dernier, donc) nous avons remis en cause le Product Owner, il semble justice d’en faire de même avec le Scrum Master, n’est-ce pas ?

Avant d’aller plus loin, rappelons l’avertissement désormais habituel : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

Scrum Master, ta mission si tu l’acceptes …

Mission impossible

Comme nous l’avons fait avec le Product Owner, il est bon de camper le paysage en synthétisant les missions du S.M. ; Nous avons de la chance, le terrain est mieux balisé aujourd’hui.

Le Scrum Master est souvent décrit comme le “chien de berger”, qui doit :

  • Veiller au bon suivi des cérémonies Scrum et âtre un agent du changement(1) (3)
  • Encourager l’équipe, l’aider à progresser et devenir autonome (1) , un rôle qui se prolonge envers les autres parties prenantes du projet (2)
  • Eliminer les obstacles (4)

Je note aussi que les écrits initiaux de Scrum donne un trait nettement plus fort au Scrum Master, le décrivant notamment comme un rôle de management, que ne le font les textes plus récents où il est plutôt décrit comme un facilitateur et un “servant leader”.

Pourquoi en faut-il un ?

image

Scrum édicte en règle la présence du Scrum Master : l’équipe doit pouvoir se concentrer à 100% sur le projet sans perdre de temps sur des considérations annexes, car le SM y veille. A la base, cette présence du Scrum Master repose donc sur  deux postulats:

  • L’équipe n’a pas la maturité pour prendre en charge sa discipline agile sans qu’un garant soit là pour y veiller.
  • L’environnement nécessite que quelqu’un joue le rôle de pare-feu, car les parties prenantes en contact avec celle-ci créent trop de perturbations.

Maintenant, imaginons un environnement favorable (donc ne nécessitant pas de “firewalling”) et une maturité affirmée de l’équipe, que reste-t-il de cette nécessité ?

C’est probablement le point qui a motivé la question posée en ce sens cet été sur Quora.

La question sur Quora

Is it possible to run Scrum without Scrum Master ?  

Les réponses que j’appelerais “bibliques” sont quand même majoritaires. Toutefois je constate qu’elles reposent sur deux fondements :

  • Le fait que les conditions d’un projets entrainent nécessairement la présence des deux postulats que j’ai cité plus haut.
  • Une croyance forte dans le bienfait de la présence des rôles.

Une autre partie des réponses affirme que cela est possible, généralement sur la base du niveau de maturité de l’équipe. Ma réponse préférée est celle de Xu Yi : “when you need to ask the question, no, you can’t. when you don’t need to ask the question, yes, you can.”.

Retour à la case départ : il est nécessaire du fait du manque de maturité de l’équipe et pour protéger des perturbations. Non seulement la réponse n’est pas satisfaisante, mais il y a plus : le SM peut s’avérer dommageable à l’équipe !

Protection ou isolation ?

Dans un excellent post qui a d’ailleurs devancé ma chronique, Tobias Meyer parle d’éliminer le Scrum Master ! Il avance plusieurs arguments à cela :

  • Le rôle tel qu’il est décrit ne peut être décemment endossé par quelqu’un se dénommant “master”.
  • L’idée même qu’une personne dédiée à être guide de l’équipe, à résoudre les problème pour elle est un non-sens, lorsque l’on considère le niveau de qualification des membres de cette équipe.
  • “protéger” l’équipe va à l’encontre de l’idée de responsabiliser celle-ci.
Bad Scrum Master

Ce troisième point plus particulièrement m’interpèle : l’un des principes de base de Scrum est de permettre à l’équipe de se concentrer à 100% sur son travail. Les rôles de PO et de SM sont là pour aider à atteindre cet objectif. Mais “protéger” peut rapidement devenir “isoler”. Le Scrum Master devient ainsi l’interlocuteur privilégié et parfois unique avec l’équipe. Certains développeurs y trouvent leur compte, qui préfèrent dialoguer avec leur machine qu’avec des utilisateurs. Au-delà de cette formulation ironique, n’oublions pas que nous avons tous tendance à nous replier sur notre zone de confort : programmer c’est être en terrain connu, donc dans la zone de confort, parler avec l’utilisateur à propos de son métier, c’est être dans l’inconnu, hors de la zone de confort.

Les valeurs agiles nous parlent de communication. L’équipe doit aller hors de sa zone de confort, elle doit aller au front pour comprendre et s’approprier la matière sur laquelle elle travaille. Scrum ne dit pas le contraire, mais la notion de “rôle” et de “protection” est tellement facilement assimilable au chef de projet à l’ancienne …

Une question de maturité d’équipe

Livrons-nous à un petit “remember the futur”. Tous les membres de l’équipe ont un niveau de maturité élevé en agilité, l’organisation a bien compris la nécessité de n’être pas intrusive. A quoi ressemble le fonctionnement de cette équipe ?

  • Le product owner vient aux stand-up. Il sait qui travaille sur quelle store. Il échange directement avec le développeur ou même le plus souvent, il lui envoie l’utilisateur le plus directement concerné.
  • Les améliorations du processus viennent de n’importe quel membre de l’équipe. Chacun évoque son idée au moment opportun (durant l’itération) et on n’attends pas l’itération suivante pour la mettre en oeuvre.
  • L’organisation n’interfère pas avec l’équille pour des questions politiques. Elle sait que la manière la plus productive d’obtenir un résultat est de laisser les personnes faire leur travail. Le comité de direction donne cependant du feedback lors des démos afin de réorienter le projet si nécessaire.

Dit comme ça, ça fait un peu bizounours. En fait, ça l’est bien un peu, hélas ! Nous n’avons pas terminé notre exercice, toutefois. Voyons comment on pourrait arriver ici en venant d’une situation standard.

Des rôles qui peuvent se répartir

Un coach m’a un jour affirmé qu’il voyait l’inutilité de sa présence comme l’accomplissement réussi de sa mission. C’est fort bien dit et aussi très juste.

La hiérarchie interfère avec l’équipe ? Certes, on peut faire rempart. Mais n’est-ce pas mieux de travailler avec la hiérarchie pour trouver un mode de fonctionnement équilibré et non intrusif ? Si le management intervient, c’est souvent qu’il a des craintes ou des insatisfactions.

Le mode de fonctionnement de l’équipe peut être amélioré, la productivité augmentée ? Oui bien sûr on peut montrer du doigt les voies d’amélioration … mais n’est-ce pas plus efficace d’enseigner à l’équipe à voir son propre gâchis, comme on dit en Lean ? Si un homme a faim, apprends lui à pêcher plutôt que de lui donner un poisson…

D’ailleurs, l’équipe étant auto-organisée, ne peut-elle dédier une personne sur chacun de ces fronts ? Pourquoi nécessairement tout ramener à une seule personne ? Que se passe-t-il quand elle n’est pas là ? Il est temps d’évoquer la sociocratie.

L’approche sociocratique

N’étant pas spécialiste du sujet, je ne vais pas m’y étendre. Ce mode de gouvernance est régit par 4 principes (5) :

  • Prise de décision par consentement: Les actions sont entérinées à moins d’objections.
  • Le cercle : c’est une entité autonome dans son travail et les décisions qui régissent son exécution.
  • Le double lien : en plus du lien hiérarchique traditionnel, chaque cercle choisit son représentant au niveau supérieur. Il participera aux décisions par consentement de ce niveau.
  • L’élection sans candidat: personne ne se porte volontaire pour un poste, les électeurs proposent des candidats qui sont libres d’accepter ou non le résultat du scrutin.

Pour une équipe ayant acquis une certaine maturité et une certaine conscience agile, l’évolution vers ce type de gouvernance semble une suite logique. Elle permet aussi au final de faire tourner le rôle de Scrum Master ou même s’y mettre fin.

Effets collatéraux

J’ai évoqué la “non nécessité du Scrum Master”. Mais allons plus loin : sa présence peut elle être nuisible, même si ce dernier est bien intentionné ?

Hélas la réponse est : oui ! Et sa présence paut avoir des effets de bord néfastes, jugez-en !

Effet colatéral

Enfin non, ce n’est quand même pas à ce point. Dans une équipe auto-organisée, l’agilité doit être l’affaire de tous. C’est déjà un peu antinomique de décider qu’une personne donnée sera porteuse de cette mission ! Passons.

Mais que peut-il se passer si une personne est en charge de la mise en oeuvre de Scrum ?

  • D’abord, les autres membres de l’équipe ne s’en préoccupent plus, jugeant que c’est l’affaire de “l’autre”.
  • Puis on arrive dans une situation de passivité où les choses ne se passent que si le SM s’en charge. Par exemple : avez-vous vu des équipes qui ne font pas le daily meeting un jour, car le Scrum Master est absent ? Oui, ça arrive !

Bien sûr, ce n’est pas toujours comme ça. Heureusement. Mais ça peut aussi être pire, si le Scrum Master n’est pas bien disposé.

Le chef de projet est de retour

Au secours ! Car oui, si Scrum décrit explicitement le rôle du SM comme n’étant pas un rôle de management, il n’est pas trop difficile de s’assoir dessus, surtout si tout le monde est bien disposé en ce sens. Retour au bon vieux commande-controle !

Chaplin, le dictateur

Alors quelle est la recette du désastre ? Elle n’est pas compliquée.

Prenez une bonne vieille équipe fonctionnant à l’ancienne. Ca ronronne bien. Les membres de l’équipe sont tranquillement en mode “ouvrier spécialisé”. Le chef de projet stresse un peu plus car tout repose sur ses épaules. Il distribue les tâches, car au moins c’est un mode de fonctionnement qu’il comprend.

Prenez une équipe managériale que l’on a fait mijoter dans un saladier-séminaire d’agilité. On l’a saupoudré d’épices exotiques lui faisant miroiter monts et merveilles : ils pourront changer d’avis tous les jours, la productivité sera multipliée par 100000 (je dois oublier un ou deux zéros), les utilisateurs auront des trucs mieux que ce qu’ils espèrent grâce à l’usage avisé de le télépathie. Les trucs standard, quoi.

Extrayez de l’équipe le chef de projet et faites-le revenir dans une poelle-formation Scrum Master. Les autres membres de l’équipes restent à la boite à bosser, car faut quand même pas exagérer.

Mixez l’ensemble, servez et voyez ce qui se passe.

Les membres de l’équipe ne comprennent pas trop ce qu’on attends d’eux et sont un poil déstabilisés (on vient de leur dire qu’ils sont enfin libre, mais bon ça reste un peu abstrait). Par défaut on va attendre les ordres, là on ne risque pas grand chose. Le chef de projet enthousiaste attends le démarrage de l’auto-responsabilité, l’allumette à la main. Pas grand chose n’arrive. Histoire d’amorcer la pompe, le chef de projet va distribuer les tâches (ou les user stories, ou ce que vous voulez) aux développeurs. Retour à la case départ. Enfin pas tout à fait, on a changé le vocabulaire.

Et si on ne trouve pas, on ne va pas ?

Le tableau que je dresse parait noir. Hélas il arrive. Et généralement on essaie alors de se voiler la face en se disant que non ce n’est pas comme avant. Pas tout à fait.

Mais que fait-on si on n’a pas de Scrum Master sous la main ? Ou que personne ne souhaites l’être.

  • On prends une victime au hasard ?
  • On roule sans ?

Clairement, sélectionner une victime n’est jamais la bonne approche. Surtout dans un rôle où la confiance est primordiale. Si l’équipe n’est pas non plus aguerrie à la pratique de l’agilité en générale ou de Scrum en particulier, il est aussi illusoire de penser que les choses se mettront en place tout seul. Il est préférable alors d’aller chercher un Scrum Master expérimenté en prestation. Mais oui.

Encore faut-il que ce Scrum Master ait bien compris son rôle et guide l’équipe dans le bon sens afin de ne pas faire tourner Scrum à la grosse farce !

Bon, alors le Scrum Master, c’est mal ?

“Scrum Masters, soyez les coaches de vos équipes agiles”. J’évite généralement dans cette colonne de faire la promotion de qui que ce soit. Mais ce slogan nous est asséné par Véronique Messager depuis maintenant un certain nombre d’années (6). Et elle a raison, c’est bien de cela dont on doit parler. Scrum n’évoque pas la chose, mais la véritable voie du Scrum Master est celle du coaching : être celui qui rends possible non pas Scrum, mais que l’équipe s’approprie Scrum !

Bref, le Scrum Master doit être un catalyseur, et pas le gars sur lequel on se décharge de l’agilité. Et dans ce cadre, son apport peut s’avérer décisif !

Références

(1) Scrum 2nd edition ;  Claude Aubry ; Dunod 2011 ; p. 44

(2) Scrum field guide : Mitch Lacey ; Addison Wesley 2012 ; p. 104

(3) Agile Software Development with Scrum ; Ken Schwaber & Mike Beedle ; Prentice Hall 2002 ; p. 31

(4) Essential Scrum ; Kenneth S. Rubin ; Addison Wesley 2012 ; p. 185

(5) Sociocratie : http://fr.wikipedia.org/wiki/Sociocratie ;

(6) Coacher une équipe agile ; Véroniue Messager ; Eyrolles 2012