Et pourtant c’est l’été…

Nous entrons en zone estivale, parait-il !

L’heure pour moi de faire le point et de passer en régime d’été. Attention “régime d’été” ne signifie pas “silence radio” !

Pour ma part…

Pour ma part, ces derniers mois ont été un peu chargés. Entre autre parce que j’ai changé de boulot. Je n’aurait pu quitter le précédent comme un voleur, et le suivant commençait à me mobiliser avant même d’avoir définitivement posé mes valises. Je vais maintenant consacrer mon temps à l’accompagnement agile, avec des choses connues et maitrisées à mettre en oeuvre et aussi d’autres moins connues… Bref, de quoi être enthousiaste, mais c’est aussi moins de confort.

Ah oui, j’allais oublier : une formation coaching que je vais suivre avec Véronique Messager très bientôt.

J’ai quand même bien mérité un petit break, et je vais le prendre !

Et aussi un peu de préparation

Je serais à l’Agile Tour Bruxelles sur la fin d’année, peut-être aussi sur une ou deux autres conférences. Ce sera au moins une nouvelle session à caractère participatif à préparer. Donc l’été sera aussi studieux.

Du côté du Scrum User Group, le programme de l’an prochain n’est pas encore établi, il faut dire que le Scrum Gathering occupe une partie d’entre nous (mais pas moi). Mais en toute logique, nous devrions commencer à nous en occuper dès maintenant.

Sur le blog

Je suis fermement décidé à ne pas laisser une semaine sans post, congés ou pas. Les divers évènements vont se tarir après la semaine prochaine, donc il y aura encore quelques retours ici même dans la dizaine de jours qui vient, puis il faudra attendre Septembre. J’en profiterais pour rattraper certains retards de ce côté remontant à plusieurs mois !

Au minimum, je livrerais ici une note de lecture par semaine, peut-être plus. Mais elles auront un petit goût archéologique, car je vais remonter des choses un peu anciennes. On reprendra les choses plus type en Septembre. Ne débranchez pas, ça peut quand même vous intéresser et le passé éclaire parfois le présent.

Pour ce qui est des citations, je vais bien sûr continuer à les dispenser.

Toujours sur le blog: en finir avec…

Je vous avez asséné l’an dernier ma série de l’été: en finir avec… avec ses 3 premiers opus (ici le premier, le second et le troisième). J’avais d’ailleurs conclus cette série par un lightning talk donné à Nantes.

Je suis fermement décidé à la reprendre. je ne vais pas m’engager sur un nombre de posts, mais j’aimerais en faire 3 entre maintenant et mi-septembre. Chacun d’entre-eux représente pas mal de boulot, cela dit, et c’est l’été, je le rappelle …

A très bientôt, donc.

Publicités

En finir avec … (le lightning talk)

Voici le support de mon lightning talk “en finir avec …” tel que je l’ai présenté l’Agile Tour Nantes 2012. C’est une présentation courte, de moins de 15 minutes.

Teaser de la présentation

L’agilité est en pleine expansion. Nombreux sont les projets, nombreuses sont les sociétés qui l’adopte ! Nous devons nous féliciter de cet engouement, et pourtant …

Pourtant cette adoption croissante n’est qu’apparence dans certains cas. Dans plus en plus de cas, même. Si Scrum est aujourd’hui l’approche qui fédère le plus, les quelques idées centrales de la méthode sont de plus en plus souvent dévoyées. Il en va de même d’autres pratiques agiles.

Ah ! Vous faites du Scrum, je vois que vous avez un P.O. et un Scrum Master. Vous n’avez plus de cahier des charges mais des User Stories, donc tout va bien.

Cocher la liste des pratiques agiles en repeignant plus ou moins les vieilles pratiques ne convient pas, il faut en finir avec cela !

Dans cette courte session, je vous propose de faire la peau à 3 pratiques : la Roadmap, le Product Owner et les User Stories. Mais vais-je vraiment les assasiner ? Pour le savoir il vous faudra assister à ce lightning talk !

Quelques rappels sur “en finir avec”

Cette série comprend aujourd’hui une présentation générale du principe de cette série ainsi que 3 posts:
Elle compte désormais la présente présentation, et une partie de la présentation de Caroline Damour et Emilie Franchomme à laquelle j’ai participé (du moins pour “la dernière”).
Viendront cette présentation sous forme d’articles, d’autres posts (certains sont en préparation, soyez patients) et peut-être une saison 2 ?

En finir avec le Product Owner ?

Nous nous retrouvons de nouveau pour le troisième volet de mon feuilleton de l’été. Après le roadmap et le backlog, occupons-nous un peu du Product Owner. Si vous discernez ma logique, vous devriez pouvoir deviner quel sera l’épisode suivant …

Je rappelle de nouveau mon mot d’avertissement : 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 !

Product Owner qui es-tu ?

En passant en revue ce que dit la littérature, nous devons comprendre que le Product Owner est visionnaire, leader mais également berger de l’équipe (1) il est aussi responsable du ROI du projet (2). On lui attribue aussi la responsabilité du contenu du produit, donc les fonctionnalités subordonnées à la vision, de leur échelonnement dans le temps (qui conditionne le ROI) et des choix tactiques au jour le jour (3). Il est aussi le point de convergence aux autres acteurs de l’entreprise partie prenantes dans le projet (4)

Bref, le Product Owner doit plus ou moins ressembler à ça :

rodina

Product Owner, pourquoi es-tu là ?

Fondamentalement, Scrum a été pensé comme un processus de développement logiciel. Cela semble bien de prime abord : après tout, développer du logiciel, c’est notre boulot !

En pratique, Scrum a planté une clôture autour de l’équipe du développement (le “team”) et de son berger (le Scrum Master, on s’occupera de son cas dans un épisode ultérieur). La relation entre l’intérieur de la clôture et ce qu’il y a à l’extérieur est reporté  sur une personne unique qui s’occupera donc de tout le reste, à savoir ce qui n’est pas du développement.

Product Owner, es-tu Superman ?

A ce stade, vous pouvez déjà répondre à cette question en comparant votre PO à sa représentation picturale ci-dessous.

superman-standing

Pourquoi Superman ? Cessons d’occulter ce qui se passe derrière la barrière et tentons de dresser une liste de ce que le périmètre produit va représenter si l’on englobe non plus seulement le développement mais tout ce que va prendre en compte cette activité produit. Ma liste va être bien naïve, n’étant hélas pas un spécialiste de la question, disons que c’est juste pour amorcer la réflexion.

  • Connaissance métier sur le périmètre couvert par le produit.
  • Compréhension de la segmentation du marché selon différentes dimensions : maturité, domaine d’activité, profils d’utilisateurs.
  • Stratégie de vente, de pénétration et de fidélisation, pour le volet commercial.
  • Appréhension des différents facteurs de risques : volatilité et compréhension du marché, positionnement de la concurrence, incertitudes sur les facteurs internes et externes influençant le déroulement du marché.
  • Connaissance des opportunités d’alliance, pour renforcer une position sur un marché (coalition), soit pour développer une “verticale”. Les options dégagées peuvent redessiner le contour fonctionnel du produit et/ou influer sur la priorité des différentes fonctionnalités.
  • Maîtrise du modèle de cash-flow afin d’optimiser les revenus générés par le produit et/ou permettre la récurrence de ces revenus.

Vous pouvez ajouter vos propres points à cette liste déjà longue, mais on constate déjà que cela fait beaucoup. La plupart des entreprises l’ont d’ailleurs acté : elles placent derrière le PO non pas une mais plusieurs personnes pour couvrir ces différentes facettes. Mais du point de vue de l’équipe située dans l’enclos, on ne veut pas trop le savoir : on ne veut voir qu’une seule tête.

A défaut d’être un Superman, le PO sera donc un “hub”. Cette capacité à être un “hub” vient-elle naturellement avec la capacité visionnaire dont nous avons parlé plus haut ? Vous devinerez certainement ma région d’origine à ma réponse : peut-être bien que oui, peut-être bien que non …

Un des éléments que j’apprécie particulièrement dans les approches agiles, c’est l’effacement les responsabilités au sein de l’équipe. L’équipe est responsable de délivrer le produit. Cela requiert différentes compétences qui sont assurées par la complémentarité des membres de l’équipe, mais sans qu’il soit nécessaire de dresser des rôles. Plus simplement dit: c’est travailler en bonne intelligence. Curieusement, ce que l’on accepte et que l’on acte côté du côté de l’équipe de développement ne s’étend pas côté produit…

NOUS versus VOUS

Arrivé à ce point, j’en reviens à l’aspect que j’ai évoqué plus haut : il y a ce qui est dans l’équipe de développement et ce qui est en dehors. Et ce qui est en dehors se résume au Product Owner. Mais outre le fait d’occulté la complexité et les ramifications de ce rôle, l’autre effet collatéral malheureux est que si le Product Owner fait partie de Scrum, il ne fait pas partie de l’équipe !

Avez-vous déjà entendu le P.O. déclarer lors d’une démo : “vous avez fait du bon boulot” ? Beaucoup d’entre-vous répondrons oui, et penserons qu’ils ne voient pas le problème. Et il n’y a pas de problème apparent, l(intention est clairement bonne. Mais pourquoi diable ce PO ne se sentait pas partie prenante de cet effort ? Pourquoi n’a-t-il pas déclaré “nous avons fait du bon boulot” ou plus modestement “nous avons fait du boulot dont nous pouvons être fiers” ?

La réponse est qu’hélas Scrum ne nous aide pas ici. Si l’intention des créateurs de Scrum était et est toujours d’englober PO et équipe dans une même dynamique, cette séparation permet de retomber très facilement dans une logique de répartition des tâches, plutôt qu’une logique d’endossement d’un leadership. D’ailleurs à ma connaissance, rien dans Scrum ne dit que le PO et seul le PO doive maintenir le backlog. Rien ne dit non plus que l’équipe ne doive pas se sentir impliqué dans la qualité de celui-ci. Et je pourrais continuer longtemps. Pourtant il m’apparait qu’il est facile d’avoir cette lecture, et que de nombreuses équipes qui viennent d’anciens processus et font partie de “l’early majority” de la courbe de Moore pour l’adoption de Scrum penchent en ce sens. Je ne suis pas non plus certain que les consultants qui épaulent ces équipes les aident toujours dans la bonne direction …

J’en appelle maintenant à Gilles Mantel qui nous a bien dynamisé avec sa “Scrum Master Academy”: il est peut-être temps de s’attaquer aussi à une “Product Owner Academy” ! L’un des articles pourrait être “Product Owner, ta place est au milieu de l’équipe”.

Du Product Owner à la MOA

J’ai récemment lu un billet d’Audrey Pedro à propos du rôle de “Product Owner Proxy” qui faisait écho au billet de Claude Aubry sur le même thème allant dans l’autre sens. Qui a raison, que penser ?

Je trouve intéressant cette émergence du concept de “Product Owner Proxy”. Non que je lui donne raison, et je penche là dans le sens de Claude, mais parce que je pense qu’il est la réponse à la légèreté avec laquelle Scrum appréhende ce rôle qui est, je le répète ici un peu différemment : tout ce qui n’est pas lié au développement va dans l’escarcelle du PO. C’est à la fois trop pour un seul homme (ou une seule femme) et une incitation à retomber dans de vieux réflexes contre lesquels la communauté agile s’est battu pendant des années: le partitionnement en rôles.

Le Product Owner Proxy est ni plus ni moins que la résurgence du concept de MOA : un intermédiaire, avec des compétences n’existant pas dans l’équipe de développement, mais qui n’est pas le “sachant” métier et doit se retourner vers ce référent métier (le vrai PO) pour avoir des réponses ! Nous avons là une belle équation perdant-perdant:

  • L’équipe n’a plus accès au référent métier capable non seulement de lui transmettre ses besoins, mais une appréhension de son métier qui passe par des remarques, des discussions informelles et toutes sortes d’éléments intangibles qui ne sont perceptibles que par le contact direct
  • L’équipe perd la responsabilité de la compréhension du fonctionnel car c’est le P.O. proxy qui fait cela. Elle se replie sur le développement et fait … ce qu’on lui dit de faire. Vous pouvez coller le vocable que vous voulez, mais j’estime qu’ici on n’est déjà plus dans un projet agile, car l’état d’esprit n’y est plus.
  • Si par hasard l’équipe vient à dialoguer directement, c’est cette fois le P.O. proxy qui voit échapper une partie de la compréhension du besoin … et risque de se retrouver sur le bord de la route.
  • Il faut bien sûr pour compléter cette évocation parler du Product Owner qui perd le contact quotidien avec l’équipe, voir avec la réalité du développement et va établir une relation “moi / vous” avec l’équipe, comme je l’ai évoqué plus haut.
maitrise-ouvrage

Après avoir donné raison à Claude, donnons aussi raison à Audrey ! Audrey définit avec justesse les missions qu’elle remplit. Cela signifie qu’il y a du boulot à faire, aucun doute. Et s’il y a du travail à faire pour épauler la vision du P.O., il doit être fait. Mais pas en créant un nouveau rôle accentuant une vision du développement en silo qui n’a rien à faire dans une approche agile, mais en intégrant cette personne à l’équipe de développement !

Une seule équipe

Là où j’entends parler de rôle, je voudrais parler de compétences ! Plutôt que de raisonner sur la base d’attribution de tâches liées aux rôles, acceptons l’idée que nous avons besoin d’un ensemble de compétences (développement, test, architecture, ergonomie, mais aussi compréhension du besoin, marketing, etc…) pour couvrir tout ce qu’il y a à réaliser. Cela nous amène vers plusieurs conséquences, que je vais illustrer en faisant d’Audrey ma “persona” (bien que je ne la connaisse pas) :

  • Audrey n’a plus une étiquette particulière. Elle est intégrée à l’équipe. Elle n’est plus nécessairement la seule à accomplir les tâches qu’elle a décrite, bien que ses connaissances lui confèrent un leadership sur ces parties. Mais c’est un leadership lié aux compétences, non au fait qu’elle soit dépositaire d’un rôle.
  • Intégrée à l’équipe, elle embrasse non plus l’étroite mission du P.O. proxy, mais l’objectif de l’équipe: délivrer un produit. Elle est prête à intervenir plus largement, sur des aspects qu’elle connait moins et où elle n’aura pas le leadership: ergonomie, tests fonctionnels, etc… L’acquisition de ces nouvelles compétences lui ouvrira de nouvelles perspectives vers le futur, mais surtout elle va se montrer plus polyvalente sur le projet actuel.
  • J’ai parlé de l’objectif de l’équipe : délivrer un produit. Et j’ai certainement tord. Nous venons de redessiner le contour d’une équipe plus large incluant le P.O. proxy, mais aussi le P.O. ! L’objectif de l’équipe n’est plus alors de livrer un produit mais de rendre un service. Le succès du projet n’est plus la livraison du produit mais l’accomplissement de l’objectif business initial du projet. La construction du produit y est incluse. L’équipe élargie fait bloc derrière cet objectif business et cesse de limiter son horizon à la construction du produit.

Dans son billet, Audrey parle d’assurer la sérénité de l’équipe. Si l’on parle d’éviter les perturbations qui gênent l’avancement du projet, alors je suis d’accord. Mais si l’on parle d’isoler l’équipe des réflexions et questionnements fonctionnels, je ne le suis pas. Le rôle d’une équipe agile est d’être au front, au contact avec les problématiques métier. C’est vrai que c’est moins confortable que de travailler sur l’intégration de la librairie machin-bidule. Mais c’est de ce contact qui naissent la richesse et les solutions innovantes.

Justement, en parlant d’innovation.

Lean Startup

Le courant du Lean Startup illustre parfaitement ce mode de pensée: le processus est complètement orienté, non plus même sur la valeur délivrée au client, mais vers sa compréhension et l’apprentissage de l’impact de ce que nous faisons sur celui-ci. De facto, l’équipe englobe la totalité des personnes qui vont assurer cette mission. L’un des points du livre qui m’a interpellé à postériori, c’est qu’à aucun moment Eric Ries n’évoque la notion de “rôle”. Vous n’en trouverez même pas l’entrée dans l’index de fin.

Quelle solution ?

Dans mon esprit, Scrum a définit le Product Owner comme le dépositaire de la direction à emprunter. Peut-être l’appellation “propriétaire” induit-elle un biais malheureux : elle incite les autres acteurs du projet à abdiquer une participation active à la compréhension et à la définition du besoin.

Personnellement, je n’ai jamais vu de projet sur lequel il n’y avait pas un initiateur, une personne “portant” l’idée. Parfois cette personne disparait derrière la lourdeur des structures ou la “culture du comité”. Mais c’est cette personne qui est pour moi le P.O. Elle n’a pas toujours les qualités de superman évoquées plus haut mais cela ne devrait pas être prépondérant, par exemple en suivant les lignes directrices esquissées plus haut:

  • Il n’y a qu’une équipe et elle englobe tout le monde y compris le Product Owner.
  • La réussite de l’objectif business (et non uniquement la construction du produit) est l’affaire de tous. Tout le monde doit se sentir concerné et tout le monde peut contribuer.
  • Jetez aux orties les abaques d’affectation de types de tâches en fonction des rôles.

Et vous, quelle est votre vision du Product Owner ?

Références

(1) Agile Product Management with Scrum ; Roman Pichler ; Addison Wesley 2010 ; p. 4

(2) Agile Project Management with Scrum ; Ken Schwaber ; Microsoft Press 2004 ; p. 20

(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 30

(4) The Scrum Field Guide ; Mitch Lacey ; Addison Wesley 2012 ; p. 72

En finir avec le backlog ?

Second volet de mon feuilleton “en finir avec…”. Ma victime du jour est le backlog.

Je rapelle mon mot d’avertissement : 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 !

De la roadmap au backlog

Lors du premier opus, nous avons vu les conséquences d’une roadmap gérée en tant que portefeuille de projet: plan, stock, frein au changement, etc… Mais ce qui est vrai à grande échelle peut-il l’être à une échelle moindre ? Car le backlog ressemble au portefeuille de projet à plus petite échelle.

Nous considérons naturellement la backlog, brique fondamentale de Scrum, comme un outil agile indispensable. Qui penserait à le remettre en cause ?

Pourtant, dévié de sa bonne utilisation il peut avoir des conséquences néfastes.

Pourtant il peut servir à déguiser les anciennes pratiques.

Pourtant les conséquences évoquées ci-dessus ne sont pas seulement des travers d’usages, elles prennent naissance dans la nature intrinsèque du backlog. C’est un peu abstrait pour l’instant. On va illustrer tout ça.

Je veux un backlog complet

Tout d’abord, c’est quoi un backlog ?

“The backlog represent everything that anyone interested in the product or process has thought is needed or would be a good idea in the product” (1)

En clair toutes les idées qui pourraient s’avérer bonnes sont aptes à y figurer. Cela soulève plusieurs points :

  1. Est-ce que seuls les éléments qui vont être effectivement réalisés doivent figurer dans le backlog ?
  2. Le backlog doit-il comprendre initialialement tout ce qui sera réalisé ?
  3. A-t-on le droit de changer le backlog, et surtout d’y ajouter des choses passée la “phase initiale” ? Vous aurez noté les guillemets.

Ce sont de fausses questions car Scrum y répond. Pourtant j’y reviens car c’est déjà une source de travers.

Le backlog contient des éléments qui vont être effectivement réalisés

Scrum répond “non” à cette question. Il s’agit juste d’une liste de fonctionalités candidates.

D’un autre côté, Scrum nous invite à lister ce que les différents acteurs ont en tête à un moment donné. A créer du stock, aurais-je envie de dire (vous voyez certainement où je veux en venir), mais je reviendrais plus tard sur ce point.

Là où le bât blesse, c’est que ce backlog en son état initial correspond à un périmètre produit. Et le client souhaite souvent avoir une estimation de ce périmètre. En soi, aucun mal à cela. Sauf que le périmètre se transforme souvent en engagement, surtout quand le client n’est pas réellement agile. A partir de ce point, je vous souhaite bonne chance dans le monde merveilleux du suivi budgétaire. Je ne prend même pas la peine d’évoquer l’antagonisme entre le mode “suivi budgétaire” et la gestion du changement …

Le backlog initial est complet

Là aussi Scrum répond clairement “non”.

Sauf que là aussi, si ce backlog sert d’estimation initiale du projet, il vaut mieux ne pas être trop à côté de la plaque. Certes on pourra toujours troquer une fonctionnalité contre une autre… Mais qu’en est-il si les premières étapes du projet mettent en lumière de nouvelles idées, des aspects du fonctionnel qui onté été occulté ? Ou simplement des oublis ? A l’extrême on devrait être en mesure de “pivoter” comme l’on dit en language Lean Startup et c’est un des aspects que l’approche agile en général et Scrum en particulier permettent.

Mais ce backlog que l’on construit à l’avance à souvent tendance à se transformer en carcan.

Notre client pas très agile va arguer “faites des ajustements, mais il faut avoir une idée claire de là où l’on va au départ”. Eh bien non, ce n’est pas obligé. C’est certainement un confort si l’on peut, mais Scrum nous donne la flexibilité qu’il faut le cas échéant. On a quand même donné le bâton pour nous faire batttre avec ce foutu backlog…

Le backlog ne peut pas être changé

Là aussi Scrum est clair : “oui on peut le changer”. C’est même l’essence du processus de tirer profit du feedback pour le faire évoluer !

Oui, mais …

On a constitué cette (longue) liste, un processus coûteux en temps et en énergie. Cela va nous freiner dans une certaine mesure pour opérer des changements qui seront eux-même coûteux dans leur introduction mais aussi dans la remise en cause des items existants !

Bien sûr ce frein sera encore plus important dans le cas d’un changement radical. Il pourra même se transformer en blocage : “remettre en cause ? Alors que l’on a là une liste de fonctionnalités bien établies ?”

Je veux un backlog détaillé

Le backlog “complet” ne suffit même pas toujours pour démarrer un projet, surtout si l’on souhaite utiliser ce backlog pour effectuer une estimation comme je l’ai indiqué plus haut. Il nous faut alors savoir ce qu’il y a derrière chaque item afin d’avoir une idée valable de la complexité de celle-ci ! Vous l’avez probablement remarqué : on a déjà quitté Scrum depuis un certain temps. Mais qu’importe, on parle de backlog ! Tout va bien !

Cette affaire de backlog détaillé m’inspire trois choses.

Détailler

Détailler ou au moins rentrer dans le coeur de chaque fonctionnalité c’est échafauder le système alors que l’on a rien commencé, que rien ne peut nous aider à soutenir notre reflexion ou etayer nos hypothèses. J’ai fait référence au “lean startup” plus haut. Eux nous suggèrent de ne pas oublier que justement ce que nous appelons “expression des besoins” sont en fait des hypothèses. Personnellement, cela me rapelle une citation du “Mythical Man-Month”, elle s’adresse au developpeur mais pourrait aussi concerner celui qui construit le backlog : “Le programmeur, comme le poète, manie des abstractions voisines de la pensée pure. Il construit des cathédrales dans les airs, à partir de l’air lui-même, par le pouvoir de son imagination” (2). Construire des cathédrales dans les airs avec de l’air, c’est pas facile…

Faire mûrir

Ma seconde réflexion va vers ce que l’on apelle parfois le “mûrissement du backlog”. Vous avez peut-être déjà entendu cette expression : “il faut que ça mûrisse” ? Voilà qui nous invite à une petite pause bucolique.

frui-murSmall

Il y a bien sûr un concept derrière ça : c’est que quand une idée est seulement une ébauche, le simple passage du temps va permettre de rafiner l’idée qui tombera alors toute seule tel un fruit mûr ! C’est pas beau ? J’ai bien entendu de gros doutes sur ce processus spontané. Mes seules certitudes à ce propos sont:

  • Si on ne fait rien, il ne se passe rien.
  • La seule conséquence inéluctable du passage du temps, c’est la génération d’un délais.

Il existe des techniques, actives celles-ci, pour développer des idées à l’état d’ébauches :

  • Le brainstorming
  • L’expérimentation, que ce soit sur la base d’un prototype ou non.

On retrouve ces techniques dans les processus de développement orientées vers l’innovations comme le Design Thinking. Mais pour ça, il faut lâcher le backlog 5 minutes …

Backlog a.k.a. “cahier des charges”

Finalement, ce backlog complet et détaillé portait autrefois un nom: le cahier des charges. Par un effet pervers, nous avons reconstitué ici sous une forme certes différente, ce que nous voulions abandonner dans les anciennes approches. Il ne reste plus qu’à en confier la confection à une MOA (auquel on aura donné un autre nom) et on aura fait le tour !

Bien sûr Scrum ne dit pas du tout d’en arriver là. Mais il est tellement facile de glisser progressivement pour en revenir à ce que l’on faisait avant. Tout en se donnant bonne conscience, souvent même de bonne foi, car on apelle cela “backlog”.

L’effet de bord de ce backlog “complet et détaillé” est le délai que cela nécessaire pour en arriver là.

Une phase d’analyse ?

Scrum a poussé le concept d’itération zéro, pour amorcer un projet. Mais pour débuter avec un backlog complet et détaillé, cela ne suffit pas. Aussi voit-on le product owner ou l’équipe PO commencer un travail qui n’est pas seulement exploratoire mais un travail de fond en avance de phase afin que l’équipe de développement puisse débuter son oeuvre avec une matière première solide.

C’est la négation même de l’approche agile dont le fondement est le cycle court et le feedback. C’est en fait la réincarnation de la phase d’analyse !

L’autre conséquence de cette phase d’analyse, outre le délai, est la création d’un stock. J’en ai parlé plus haut et j’ai l’air d’insister, mais en terme “lean”, le stock est assimilé à du gâchis: c’est du travail dont on ne sait s’il va être utilisé et demande une charge d’entretien : relecture, réévaluation régulerière, etc…

Old files

Ma liberté de penser !

Vous finissez un sprint et allez commencer le suivant. Il est temps de choisir les prochains items de backlog à développer.

Qu’est-ce qui importe vraiment ?

Sont-ce les prochains items de backlog selon la priorité qui leur a été attribuée ? Pas vraiment, ou du moins pas comme ça.

Ce qui importe vraiment c’est ce que nous avons appris à la lumière du sprint écoulé : approfondir des fonctionnalités sur lesquelles nous avons travaillé, se diriger vers une direction complètement différente et parfois oui, prendre des items du backlog tel que nous l’avions dressé.

Mais par rapport à ce focus sur le feedback et l’apprentissage le backlog agit régulièrement comme un frein ou plutôt comme un gros élastic que nous aurions dans le dos, qui nous ramène inoxorablement vers la voie que nous avions tracé au départ.

Qu’est-ce qui empêche d’utiliser le backlog pour prendre en compte l’apprentissage et le feedback ? Absolument rien. En fait, il est fait pour ça. Comment l’utilisons-nous dans les faits ? Je vous laisse le soin d’y répondre.

Dans un projet agile, ce qui s’interpose entre vous et le feedback est un problème. Ne laissez pas le backlog devenir un problème, ne le laissez pas entraver votre liberté de penser. Un backlog n’est pas un cahier des charges.

A quoi ça sert vraiment ?

J’ai l’air de dire jusqu’à présent que le backlog est l’oeuvre du malin. Donc est-ce utile ? Voilà un point sur lequel nous allons pouvoir répondre aisément.

S’assurer que l’on fait les choses les plus importantes

Imaginez que vous avez un backlog de 50 items alors que vous n’allez pouvoir en traiter que 3 dans la prochaine itération. A quoi servent donc les 47 autres ? Eh bien essentiellement à s’assurer que l’un des 3 items importants ne se trouve pas parmi ces 47 autres !

Donner de la perspective

Certes, quand on fait un projet hautement innovant, voir de la R&D, construire un backlog a peu ou pas de sens. On est d’ailleurs là en dehors de la zone de Scrum. Mais lorsque cela est possible, en fait assez souvent, avoir du contexte donc une idée de ce qui est considéré comme le périmètre du projet à un instant donné, aide à la réflexion et est plus stimulant pour l’équipe.

Quelle(s) alternative(s) ?

Elles sont essentiellement déterminées (ou limitées) par notre créativité. J’en propose 3. Et je vais tricher un peu.

Arrêtez ça

Ce n’est pas une alternative mais un conseil : ne faites pas le backlog “complet et détaillé”. C’est mal. Arrêtez de faire ça, simplement.

Pas de backlog

Si on n’a plus de backlog, on ne fit plus du Scrum, n’est-ce pas ? Mais certains projets à forte composante exploratoire ne se prêtent pas à cela. Nous sommes alors dans le cas où la backlog va générer plus d’entrave que d’aide. Il est peut-être temps de sortir de Scrum. D’autres approches agiles s’accomodent de l’absence de backlog :

  • Extreme Programming parle juste de User Stories (on s’occupera de leur cas dans un épisode futur) à traiter et ne fige même pas celles-ci pour l’itération en cours. Toutefois XP n’est pas hostile à la présence d’un stock de stories.
  • Kanban n’a pas de backlog, mais des files d’attente. Et celles-ci ont des capacité déterminées et limitées. On a bien du stock dans une certaine mesure, mais celui-ci est limité et contrôlé.
  • Lean Startup ne parle ni de backlog ni de stock de features. En fait, cette approche s’oppose intrinsèquement à ces notions car le focus est ici uniquement sur l’apprentissage scientifique qui est fondamentalement antagoniste avec la présence d’un “stock d’hypothèses”.

Le backlog à géométrie variable

C’est mon préféré. C’est aussi un compromis entre les avantages (donner de la perspective, identifier les fonctionnalités candidates) et les inconvénients (créer du stock, générer de la charge et du délais). Fort heureusement, c’est aussi ce qui est préconisé par de nombreux auteurs, dont Claude Aubry (3).

Dans cette approche on limite le découpage fin des stories et leur détail qu’aux fonctionnalités classées les plus prioritaires. Je ne vais pas entrer dans le détail ici, ce n’est pas le but de ce post. Vous en trouverez la description ailleurs.

Alors le backlog, c’est mal ?

J’utilise des backlogs et j’aime bien ça. Je serais donc bien en peine de dire que c’est mal.

Mais ce n’est pas non plus de la magie. Le backlog est un outil. Mais aussi bénéfique soit-il un outil porte en lui-même les germes de ses propres travers. Je me limiterais à deux conclusions:

  • Ne dénaturez pas le backlog et la façon dont il doit être utilisé.
  • Soyez conscients des inconvénients. Ils joueront contre vous si vous les ignorez.

Références

(1) Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice Hall 2002 ; p. 33

(2) The Mythical Man-Month anniversary eat, Frederik Brooks, Addison Wesley 1995

(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 67

En finir avec la roadmap !

Je vous l’avez promis il y a peu, voici le premier opus de mon feuilleton “en finir avec…”. Ma victime du jour est la roadmap.

Avant que vous commenciez cette lecture, un mot d’avertissement. 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 !

La roadmap qu’est-ce que c’est ?

Ce terme est utilisé en informatique de manière assez libérale. Il peut concerne aussi bien un projet, qu’un ensemble de projet, une stratégie business et beaucoup d’autres choses encore. Je vais m’intéresser ici à la roadmap d’une organisation de développement. Elle est souvent relative à un portefeuille de projets, comme on le verra.

Mais au fond, que va-t-on attendre d’une roadmap ? Ou du moins, qu’est-ce que moi, je vais en attendre ?

Principalement une certaine perspective d’avenir, capable de me montrer les orientations des mois à venir. Je suis réaliste, je sais bien que :

  • Plus on se projette dans le futur, plus le niveau d’incertitude est élevé. En un an, beaucoup de choses peuvent se passer en terme d’évolution du marché, d’opportunités business, etc… Je considère même que c’est un signe de bonne santé de l’entreprise, du moins tant que l’on ne confond pas évolution de la stratégie et atermoiement.
  • Qu’un changement majeur de stratégie (un “pivot” dans le langage Lean Startup) peut totalement remettre en cause cette perspective à un moment donné.
  • Qu’il n’est ni utile ni raisonnable de chercher à étoffer cette projection de détails que l’on n’a pas encore et qui seront peut-être obsolètes au moment où l’on traitera le sujet.

Bref, quand on va me parler de roadmap, je vais penser à quelque chose comme cela

pushpin on map

En clair : une direction, avec des jalons représentant des niveaux d’accomplissements, mais aussi des dates en dur représentant des contraintes opérationnelles : engagements divers contractualisés, salons, etc…

Le syndrome de la roadmap de projets

Dans les faits, nous allons plutôt devoir composer avec un plan établi sur la base d’une liste de projets priorisés et planifiés en fonction de notre capacité de travail afin d’optimiser celle-ci en l’utilisant au mieux.

Peut-être aurez-vous remarqué le début d’une pointe d’ironie ?

Peut-être aussi, si vous avez suivi des posts et présentations plus anciens que j’ai pu faire, vous dites-vous que j’ai défendu ce même concept de roadmap il n’y a pas si longtemps ? Je l’avoue dès maintenant : mes idées ont sinon changé, du moins pas mal évolué. J’assume.

Le problème avec cette occupation optimisée de la capacité de travail, c’est que la roadmap ressemble désormais à ça:

parking-Small

On peut faire pire. Il y a une variante de la roadmap de projets appelée “roadmap matricielle”. En  voici une vue d’artiste (vous remarquerez les “jolies couleurs”, partie intégrante du concept).

roadmap_matricielle

La roadmap matricielle présente une certaine élégance et peut donner l’apparence d’une maîtrise plus pointue du sujet. Après tout, il faut être plus intelligent pour appréhender les choses en deux dimensions qu’en une seule, non ? Cela bien établi, on se demande pourquoi personne n’a encore eu l’idée de réaliser des roadmaps tridimensionnelles ! La difficulté de rendre cela sous Powerpoint, j’imagine …

En réalité la roadmap matricielle amplifie les travers de la roadmap de projets :

  • Plus d’embouteillage : ce n’est plus une file de projets qui en en attente mais une série de files d’attentes ! L’image du péage de Saint Arnoult s’impose à moi !
  • Alignement des ressources avec le plan. Il est bien facile d’ajouter une ligne à une matrice. Mais qu’en est-il des équipes de développement ? La pratique montre qu’elles sont rarement dimensionnées en conséquence. Souvent cela se traduit par du temps partagé de développeurs (un désastre) ou des équipes de développement fractionnées pour atteindre des tailles d’une ou deux personnes pour certaines d’entre-elles…
  • Pas de focus stratégique. On attend d’un comité de direction qu’il donne justement une direction ! Que peut-il faire quand il est incapable de mener à bien sa mission première ? Il peut ne pas décider de direction stratégique et clamer que “toutes les directions sont prioritaires”. La roadmap matricielle traduit cela.

Qu’elle soit matricielle ou non, la roadmap a des conséquences dont nous allons nous rendre compte qu’elles sont des effets de bord de son existence même. Ce sont pour la plupart en fait des effets psychologiques.

Conséquences, conséquences

La persistance dans l’action

L’une des vertus de la roadmap est de montrer que derrière le projet en cours, il y a un ou plusieurs projets en attente. En principe c’est un bienfait, ce n’est même pas complètement négatif, même si je vais prétendre l’inverse dans deux secondes.

Mais concentrons-nous sur notre projet en cours.

Etant agile, vous savez que l’intérêt d’un projet ainsi réalisé réside dans le feedback, l’émergence de nouvelles idées porteuses de valeur ou l’abandon d’idées initiales qui finalement n’en ont pas. Dit autrement, on devrait arrêter un projet quand il n’y a plus de valeur business dans les fonctionnalités à venir, par contre on devrait le poursuivre si la valeur de ces fonctionnalités à venir le justifie. Il n’est d’ailleurs pas rare que les fonctionnalités différentiantes arrivent relativement tardivement car on doit au préalable assurer les fonctionnalités de base, comme le montre le modèle de Kano.

Modèle de Kano

Hélas la file d’attente crée une pression psychologique vers l’arrêt du projet, même si les fonctionnalités à venir sont intrinsèquement porteuses de valeur. Il faut certes juger de l’intérêt de poursuivre ou passer à autre chose, mais la roadmap tend à créer un biais dans la décision dans le sens de la tenue du plan.

La rigidification du changement

Une roadmap de projet, c’est un plan. Et créer un plan, ça prend du temps. Combien de temps (en délai) allez-vous prendre pour prioriser avec un comité de direction un portefeuille de 20 ou 30 projets ? Si votre réponse est “1 mois”, je pense que vous vous en tirez bien. Généralement, ce sera plutôt plus.

Maintenant, partons sur l’hypothèse de 2 équipes traitant des projets allant de 6 mois à 1 an, ce qui est compatible avec une roadmap d’une vingtaine de projets soit disons 3 ans de travail. Statistiquement, on va donc se retrouver avec un démarrage de projet tous les 3 à 6 mois. Quelle est la probabilité pour qu’un comité de direction réévalue cette roadmap à chaque début de projet (tous les 3 à 6 mois), avec un délai de réévaluation qui sera de 1 à 2 mois ? En théorie, c’est faisable, dans la pratique c’est au mieux improbable.

On se retrouve ainsi devant l’alternative suivante:

  • Pas de réévaluation du portefeuille et on suit le plan sans le remettre en cause, en tout cas pas à chaque début de projet.
  • Le bon sens prédomine, et lors du début du projet suivant, on démarre le projet qui parait être le plus important pour la société, qui n’est pas nécessairement celui prévu par la roadmap. Et la roadmap devient gentiment obsolète…

Incapacité à faire face à l’imprévu

L’un des autres effets pervers de la roadmap est l’effet d’encombrement qu’elle donne. En rendant visible (et priorisés) un grand nombre de projets, elle provoque une censure, voir une autocensure par rapport à de nouvelles opportunités business qui demandent un changement radical de direction. La présence même de la roadmap crée un frein psychologique à l’idée d’arrêter là un développement en cours ou de le réorienter.

Une variantes de ceci est la perte d’opportunités pour les équipes de réalisation elles-mêmes : crucifiées à leur roadmap, elles voient les projets d’actualité passer en d’autres mains car “ces pauvres gars sont bien trop occupés, il faut les soulager”. Là encore l’effet d’encombrement se substitue à l’importance business des projets qui émergent.

Quand c’est pas cher, c’est prioritaire

L’analyse et la priorisation d’un portefeuille de projets se font souvent sur la base d’indicateurs associés à ces projets : risque, importance business, coût, etc… En soi cela est une bonne chose même si calibrer l’importance relative de ces indicateurs est à la fois subjectif et délicat. Mais hélas ce processus nous expose lui-même à deux travers:

  • Perdre de vue l’axe stratégique que l’on s’est fixé.
  • Tomber dans le syndrome de la priorisation par le coût : “ce projet est tout petit, on doit pouvoir le caser avant ce gros”. Une fois tombé dans cette logique, le corollaire est une importance exagérée donnée à la quotation des projets (elle conditionne majoritairement les priorités), donc une logique de coûts préétablis sur les projets fonction des spécifications et par là même une sclérose anticipée du périmètre fonctionnel !

La roadmap de projets, c’est du stock

Quel est l’intérêt avéré d’analyser, évaluer et prioriser une vingtaine de projets lorsqu’au final c’est un et un seul projet qui démarrera au prochain démarrage de projet ?

En fait, il y a bien un intérêt : s’assurer que le bon projet à démarrer est bien celui que l’on a choisi et aucun des 19 autres ! Mais quel est l’intérêt de déterminer que les projets en position 4 et 5 sont correctement priorisés ? Ou même que celui mis en seconde position est le bon ? Le Lean nous apprend deux choses importantes:

  • Le stock, c’est du gâchis. Il doit être éliminé.
  • Les décisions doivent être différées jusqu’au “dernier moment responsable”. Ce dernier moment responsable, c’est celui où l’on va effectivement démarrer le projet.

Etablir, entretenir, réévaluer de longues listes de projet, c’est indubitablement du stock. Combien de projets de cette liste ne seront même jamais démarrés?

Et la roadmap agile ?

Depuis quelques années est apparu le concept de “roadmap agile”. La littérature sur le sujet n’est pas très abondante non plus, mais elle existe. Vous trouverez d’ailleurs une note de lecture sur un de ces ouvrages sur ce blog.

Quel est le but d’une roadmap agile ? Il reste de gérer et prioriser un portefeuille de projet, mais de manière plus efficace en ne remontant que les informations pertinentes à la priorisation. Donc, on décide plus efficacement sans s’engluer dans une masse d’information et un niveau de détails qui ne sont pas pertinents à ce niveau. On est aussi plus efficace à collecter et analyser l’information en amont. Bref, on se met en condition pour permettre le suivi et l’évolution itérative du portefeuille.

Mais cela reste quand même du stock !

Quelle alternative(s) ?

Analyser un gros portefeuille de projet est-il nécessaire ?

D’un point de vue des équipes de réalisation on a guerre besoin d’avoir une vingtaine de projets priorisés. On a même pas besoin d’avoir une visibilité sur ces vingt projets. On a juste besoin de connaitre le prochain projet. Avoir une idée des un ou deux suivants tels qu’on les imaginent aujourd’hui peut aider à donner de la perspective, pour autant que l’on accepte que la vérité d’aujourd’hui ne sera peut-être pas celle de demain…

D’un point de vue business, c’est un peu différent. Il faut identifier le (ou les quelques) bon(s) projet(s) à réaliser. Mais il n’est pas utile de recenser et surtout analyser tous les projets potentiels de l’entreprise ou du département pour cela. Si la stratégie est clairement identifiée, les quelques projets les plus importants remonteront naturellement. Et il y a de bonnes chances pour que ce soit les bons.

Le problème est la “stratégie clairement identifiée”. Ce n’est pas un boulot si facile que cela, mais c’est celui que l’on attend d’une direction.

Se livrer à une grande foire des projets, pardon à une roadmap des projets est aussi une façon d’abdiquer à l’établissement de cette stratégie.

Alors la roadmap, c’est mal ?

C’est le moment où je ne vais pas répondre à la question. C’est à vous d’y répondre.

La roadmap n’est pas intrinsèquement mauvaise, surtout si on essaie de la mener en agile. La vertu qu’elle doit porter est de donner de la perspective.

On peut aussi avoir une liste des “projets potentiels”, sorte d’aide-mémoire entretenu au fil du temps et de discussions informelles. Je le fais. Et cela m’aide lorsque le sujet et des sujets proches sont évoqués.

Mais les effets néfastes de la roadmap de projets existent et peuvent être plus importants que ses bienfaits. A vous de juger.

Personnellement je pense que la roadmap commence par une stratégie. Elle doit permettre de se focaliser sur un petit nombre de projets.

En finir avec …

Mare du dogmatisme ? Besoin de fraicheur ?

Cet été je vais me métamorphoser en grand sacrilège du Scrum ! Non que je ne crois plus en Scrum, mais plutôt que je voudrais m’insurger contre une utilisation un peu mécanique de la méthode qui va à l’encontre même de l’agilité

En finir avec les zombies !

Je vais intitulé ma série d’article “en finir avec …”. Pour l’instant je n’en ai écrit aucun, j’espère que j’arriverais à tenir ce que je dis. Je ne m’engage pas sur un nombre d’article, vous verrez bien ce qui arrivera, mais ça arrivera entre maintenant et la mi-spetembre, qu’on se le dise. Ca vous oblige aussi à rester à l’écoute, du moins ceux qui pensent que je peux les intéresser.

Mais pourquoi “en finir avec” ?

Par provocation, d’abord !

Ensuite pour stigmatiser que rien n’est coulé dans le béton. Les éléments constitutifs de Scrum ne sont ni une fin en soi ni une justification. Ce sont juste des moyens, un guide pour faire des projets agiles. Si je dois choisir, je préfère un projet agile sans Scrum, qu’un projet déguisé qui s’auto-proclame agile (mais qui ne l’est pas) sous couvert de backlog, product owner, stand-up, etc…

Pensez plutôt que d’appliquer !

Je constate, et hélas je ne suis pas le seul, une augmentation des projets Scrum Canada Dry. Peut-être est-ce le prix à payer pour cette extension rapide de Scrum que nous observons aujourd’hui ? Beaucoup d’organisation dépourvue d’ADN agile tentent l’agilité en mimant ses rituels. C’est le “cargo culte”.

Mon but est de réagir, de nous éloigner de l’aspect rituel afin de nous concentrer sur l’aspect fondamental et initial de l’agilité. Je ne le ferais pas en citant une nouvelle fois le manifeste agile, bien que j’avoue que ce soit un bon moyen mais en faisant oeuvre active de déconstruction !

Attention, ça commence bientôt …

Action !

Ce prologue va me forcer à entrer en action, car je n’ai encore rien rédigé. Voici donc l’agenda :

  • A partir de la semaine de cet été jusqu’à la mi Septembre, une série de posts sur ce thème ! Je ne sais pas encore combien, cela va dépendre de mon courage et de mon inspiration.
  • Une proposition de Lightning talk pour l’agile tour nantes ! Ca c’est pour très bientôt, mais les délibérations pour l’acceptation des sessions ne seront connues que le 17 Septembre. J’ai horreur du travail à la chaine, je ne soumet donc mon sujet qu’à un seul évènement, avec l’espoir qu’il sera retenu. Nous verrons bien.

A très bientôt !