Agile Project Management—Driving Value or Where’s the Beef?

http://www.projecttimes.com/robert-galen/agile-project-managementdriving-value-or-wheres-the-beef.html par Robert ‘Bob’ Galen

Il y a des années il y avait une merveilleuse publicité dont je me rappelle où une matrone nommée Clara Peller jugeait des hamburgers par la quantité de bœuf qu’elle y trouvait. Souvent elle était déçue dans sa recherche et, de frustration, criait « Où est le steak ? ». Wendy’s était la chaîne de restauration qui a inventé cette idée publicitaire et à ce jour la phrase est devenue une accroche pour délivrer de la valeur et répondre aux attentes des clients.

Je pense que Clara était sur quelque chose de vraiment important. Dans mon expérience, les business loupent souvent le « steak » quand ils essayent de délivrer de la valeur à leurs clients particulièrement dans le domaine du logiciel. Je ne sais pas exactement pourquoi. Parfois je pense que les développeurs sont trop distants de leurs clients. Ils peuvent rarement les toucher ou les observer. Ou comprendre leurs vrais défis. Donc ils font des suppositions quand on en vient à la priorisation des besoins puis jettent le logiciel « par-dessus le mur » pour un retour d’information.

Assez souvent ils sont sous pression pour livrer un maelström de fonctionnalités. Même si quasiment personne ne sait ce que sont les besoins clients, donc ils fournissent des solutions en ratissant large espérant atteindre les besoins. En croisant les doigts. Même si cela peut connaître certaines réussites, on aboutit aussi à la livraison de fonctionnalités de faible valeur qui diluent la concentration de l’équipe et augmentent les coûts de développement.

Ne serait-ce pas merveilleux si nous pouvions nous concentrer entièrement sur le « Steak » dans le développement d’application ? Dépenser la majorité de notre énergie, en nous concentrant sur la livraison de solutions à forte valeur et répondant aux plus forts besoins de nos clients. Éliminer le désordre de la déception et de l’ambiguïté et travailler simplement sur qui compte le plus ?

Même si cela ressemble à un conte de fées, les méthodes agiles aspirent justement à atteindre ce but. Mais il n’est pas facile de l’atteindre et le Chef de projet Agile efficace joue un rôle merveilleux dans cette quête. Dans ce billet, je veux partager quelques idées sur la façon de concentrer l’équipe sur la livraison de vraie valeur.

Un « backlog » priorisé !

Un des premiers mécanismes qui pilotent la valeur est le « Backlog de Produit » – la liste priorisée des besoins qui pilote ce que les équipes agiles vont construire. Chaque équipe devrait être focalisée comme un laser sur la priorisation de leur « backlog » de 1 à N. Il ne peut pas y avoir trois ou quatre fonctionnalités de priorité 1, seulement une; puis une seule deuxième, une seule troisième, et cetera.

Croyez-moi, vos clients et parties prenantes voudront jouer indéfiniment avec les priorités. J’ai vu des cas où ils avaient fait des regroupements dans un tableur qui donnaient la priorité de chaque fonctionnalité, puis des sous-fonctionnalités de chacune d’entre elles également priorisées. Ils insisteront pour dire qu’ils ne peuvent pas décomposer davantage la valeur quand ils essaieront d’augmenter la priorité. Cette approche (1.a, 1.b..1.z) leur permet d’échapper à la vraie priorisation et à la sélection. Elle indique aussi leur incapacité innée à faire des choix difficiles quant à ce qui est réellement le plus important. Ne les laissez pas le faire!

Un backlog de produit efficace est toujours dans un ordre linéaire et priorisé. L’équipe délivrera toujours les fonctionnalités de priorité les plus hautes en premier. Ils travailleront d’abord sur celles-ci, les finiront en premier, et s’assureront que le client est bien engagé.

Et, puisque le client est l’arbitre final des priorités, il ne devrait pas vraiment se plaindre de cette approche. Il est vrai qu’historiquement nous leur avons permis de nous donner de longues listes de fonctionnalités sans faire cette distinction et ils sont devenus un peu paresseux.

Quand encouragée à prioriser, je n’ai jamais vu de partie prenante qui en soit incapable.

Valeur Pilotée par le client

La priorisation peut aussi être pilotée par la valeur perçue, le changement, qui devrait être conduit. Une technique utilisée par beaucoup d’équipes agiles est la notion de Poker de valeur. C’est une variation de la populaire technique de Poker de Planification (Planning Poker) qui est utilisée pour l’évaluation de la taille d’une « User Story ». Mais au lieu de déterminer la taille des « User Stories » en points d’histoire, nous utilisons des Points de Valeur comme déterminant.

Dans ce cas vous utilisez un jeu de cartes étiquetées de 1-10, un étant la valeur la plus basse et dix la plus haute. Pour chaque « User Story » ou thème d’histoires vous demandez à un groupe mixte de clients et de parties prenantes ‘de voter’ sur la valeur de l’Histoire. Vous prenez une approche tournante et discutez ‘le pourquoi’ derrière la valeur la plus haute et la valeur la plus basse et vous laissez les membres de l’équipe exprimer leurs avis sur la nuance de valeur.

Une fois que la discussion est finie, vous faîtes un second vote et rediscutez jusqu’à ce que vous rétrécissiez la fourchette de valeurs autant que possible. Parfois vous atteignez un accord sur une valeur de l’ensemble de l’équipe. Parfois vous obtenez simplement une fourchette.

Vous pourriez même compartimenter les valeurs selon les différentes perspectives de l’équipe. Par exemple, les personnes de la qualité et des tests estiment une histoire particulière à cinq, tandis que la valeur des gens du métier cela la valorise à trois et les développeurs ou les gens de la technologie à un. Toutes leurs estimations fournissent des données importantes sur combien vous estimez transversalement la fonctionnalité.

Cette logique pourrait aussi être appliquée à de multiples parties prenantes. Par exemple, les parties prenantes Nord-Américaines pourraient estimer une fonctionnalité à six, tandis que les parties prenantes EMEA la jugent seulement à trois. Dans tous ces cas, discuter de la VALEUR comme d’un attribut distinct aide l’équipe dans la priorisation et dans la décision de combien de finition il faut apporter aux fonctionnalités individuelles.

Une Variation

Une variation vraiment efficace sur la technique de Poker de Valeur est de donner à chaque votant ou contributeur associé un montant de financement à dépenser pour leur vote. Alors, non seulement ils votent sur une valeur, mais ils doivent aussi investir une partie d’un montant fixe de dollars sur la fonctionnalité.

Très souvent de l’argent de Monopoly ou un équivalent amusant sont utilisés à cette fin. Disons que chacun possède 5,000 $ à dépenser sur leurs fonctionnalités pendant le Poker de priorisation. Dans un cas spécifique, une partie prenante vote neuf sur une caractéristique.

Pour souligner l’importance, ils déposent 1,500 $ sur la caractéristique soit environ 30% de leurs fonds disponibles. En fait, ils dépensent leurs fonds sur un total de seulement sept fonctionnalités. Pendant qu’ils continuent à prioriser les fonctionnalités ultérieures, ils ont clairement communiqué leurs avis sur la valeur. En fait, cette caractéristique à 1,500 $ finit en première priorité avec une valeur totale de 12,000 $ à travers l’équipe de vote entière soit 25% des fonds disponibles.

Aussi, voici une question intéressante. Si vous implémentez cette approche, que transmet Priorité n°1 par rapport à Priorité n°1 ET 25% de la valeur ? Selon moi, il y a une grande différence. Cette fonctionnalité représente une part beaucoup plus significative de la valeur et exige un soin particulier dans l’exécution. J’espère que vous voyez la différence.

Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF)

Souvent dans les équipes agiles, des « User Stories » singulières n’ont pas la masse ou l’impact suffisant pour être estimées efficacement par le client. Plus tôt, j’ai parlé en termes de thème d’histoires. C’est une façon commune de grouper ensemble des histoires qui ont une valeur et de la signification en tant que groupe. Non seulement cela aide dans le développement des jeux de fonctionnalités significatives, mais si vous priorisez au niveau des thèmes, cela simplifie votre priorisation. Cela a aussi plus de signification du point de vue des clients.

Une variation sur ce thème est la Fonctionnalité Minimale Commercialisable (Minimal Marketable Feature : MMF). Ce concept est originaire de Kanban et de LEAN. Essentiellement, c’est comme un thème, mais il apporte les notions de faisabilité, possibilité de commercialisation et l’utilisation d’ensemble client.

Très souvent un MMF est plus grand qu’un thème. Cela pourrait être équivalent à une épopée d’histoires d’utilisateur et exiger que plusieurs sprints soient achevés. Cependant, une fois réalisé, l’équipe délivrera d’habitude physiquement le MMF au client, par exemple, le faisant passer dans l’environnement de production.

Suivi de Valeur

Un des merveilleux ajouts à votre ensemble d’outils de Chef de projet Agile est de brûler complètement la valeur d’histoires, de thèmes, ou MMFs. Vous voudrez installer le graphique de « Burndown Chart » dans un emplacement bien visible qui mette en évidence la valeur livrée par l’équipe. Comme avec tout graphiques « Burndown » vous voudrez garder les yeux de chacun sur le progrès et interagir avec l’équipe sur le progrès et le flux.

Vous voudrez calculer la valeur totale pour une version ou un projet. Alors configurez votre « Burndown » sur une base itération-par-itération.

Si vous obtenez un comportement agile sain dans votre équipe, vous verrez que la valeur est livrée d’une façon chargée sur l’amont. Vous devriez aussi voir les fonctionnalités de forte valeur livrées très tôt. En fait, je m’attends habituellement à ce que des équipes factorisent la valeur dans la qualité globale et dans les stratégies de test.

Savoir conclure

Les chefs de projet Agiles ne se soucient pas juste d’exécuter par cœur de tâches ou des « user stories ». Non! Au lieu de cela ils concentrent leurs équipes sur une vue nuancée et à multiples facettes et vers une exécution orientée client et pilotée par la valeur.

Non seulement espèrent-ils en premier délivrer de la valeur, mais ils espèrent aussi qu’en ce faisant, le client peut atteindre un niveau « assez bon » avec les incréments de produit livrés de façon incrémentale et permettre ainsi à l’équipe d’arrêter le projet plus tôt que prévu.

S’arrêter après la livraison des fonctionnalités et de la fonction qui leur importe vraiment le plus. En quelque sorte atteindre leur valeur et se déplacer ensuite vers le projet suivant de valeur la plus haute. C’est cette sorte de recherche de valeur qui peut vraiment faire qu’une équipe agile se détache de ses homologues traditionnelles et se déplace tellement plus rapidement.