Comment gérer des notions différentes de la valeur  ?  Comment gérer la valeur acquise dans un projet agile ?

Quelle définition peut-on donner au mot 'valeur' ?  Dans un projet agile aussi, on peut définir valeur comme l'équivalent du budget que l'on veut dépenser dans un projet. 

La valeur acquise - selon la méthode issue du PMI/DoD/DoE etc. - correspond à la valeur physique (elle doit être vérifiée par des inspections et par des tests) multipliée par le budget global, typiquement du projet ou d'un lot de tâches. 

Comme le budget global couvre tous les lots de tâches qui sont nécessaires pour atteindre l'ensemble des objectifs définis dans la Work breakdown Structure (Structure de Découpage de Projet), ni plus, ni moins, la qualité et la valeur dans un tel projet sont les équivalents à faire le juste nécessaire défini dans le budget.

Alors, dans les méthodes Agiles? Il y aura souvent des délais et des budgets fixes, et un périmètre variable, mais qui vise des priorités.  Toutefois, ce périmètre variable pourrait être pondéré en pourcentage du budget global du projet, et surtout si on sait bien classer les besoins par priorité.

Ensuite quant à la définition des mots "business value", il y avait toujours une distinction entre le prix payé par un client acheteur, les coûts payés par le fournisseur et la valeur ressentie par un client utilisateur, voyons les avantages moins les inconvénients destinés à l'ensemble des parties prenantes.

Donc, tout dépend de ce que l'on met dans les définitions des mots 'valeur' et 'qualité', etc.  Si la qualité se permet d'aller au-delà des attentes (esprit de service; exemple une belle sourire ne coûte rien à priori, mais pourrait bien aider à fidéliser un client) elle est différente d'une qualité qui ne devrait pas aller au-delà de la satisfaction des attentes (esprit de production; car la variabilité statistique coûte chère).

N'empêche que l'on peut gérer les deux définitions par rapport à un budget (prix) dans un projet agile tout comme dans un projet classique.

Des questions que l'on pose souvent:  

Comment contractualiser un projet agile ? Comment faire un prix forfaitaire pour un projet agile?

Voici 10 approches contractuelles ou de partenariat 'protocolaire' adaptées à des projets agiles:

1) Contrat type (rédigé par un expert juridique) avec connaissances des méthodes agiles (découvrir plus à http://www.metanaction.com/cms/node/158)

2) Établir un budget global; ensuite accorder un prix fixe pour chaque itération et contrôler les dépenses réelles et la vélocité réelle afin d'anticiper des dépassements. Le client aura des livrables utilisables et peut s'arrêter à la fin de chaque itération.

3) Faire les premières itérations en T&M (régie) et les autres - une fois que les besoins sont mieux clarifiés - en prix forfaitaires.

4) S'entendre sur un prix 'probable' avec une rémunération incitative (des économies sont réparties en fonction d'un pourcentage accordé et des dépassements sont rémunérés à prix réduit).

5) Rémunération dégressive si retard sur les besoins prioritaires (sur les 33 à 66% de besoins 'impératifs').

6) Paiement en fonction de la productivité en "points de fonctions", définition accordée par les partenaires.

7) Contrat cadre 'roulant' (renouvelable par 'itération', par 'version' et/ou par 'projet').

8) Définition d’une référence / baseline basée sur des "Business Goals" définis dans une optique de la prise en compte de leur évolution dans l'avancement du projet.

9) Participation aux résultats et esprit de confiance (les interlocuteurs se connaissent).

10) "Timebox" et "Cashbox" définis (conception à coûts et à délais objectifs) à base d'une co-conception et d'une 'priorisation' du périmètre / scope, comme par exemple dans le domaine de la fabrication automobile.

Depuis quelques années un sujet revient souvent dans le management de projets; c'est celui du 'Business Case' bien sûr. Pourquoi ? Parce qu'il me semble que si la plupart des projets ont toujours visés des résultats définis en coûts, en délais et en heures, mais la justification de l'intérêt du projet restait hors champs; même si c'est souvent (ou devra l'être) la partie qui prend le plus de temps et qui consomme le plus d'investissements en ressources.

Il n'est pas évident à bâtir, pourtant, ce 'business case'. Trop fréquemment, il contient des facteurs clés de performances faciles à mesurer, mais non des indicateurs clés de réussite, très importants mais parfois difficiles dans la définition, au moins initialement...

Une bonne séance de travail en équipe sera très propice pour la définition d'un bon 'business case' ('cas d'affaire ou cas métier, selon si vous êtes Québécois ou Français.)

Dans les méthodes émergentes 'agiles', nous avons le 'le planning poker', et dans le management de projet 'traditionnel' nous retrouvons la définition d'une structure de découpage de projet, avec un travail en équipe sur l'affectation des lots réalistes en effort et en temps.

Dans des approches structurées comme PRINCE2 et des démarches agiles comme AgilePM on travaille le 'business case' et on l'utilise comme référentiel 'contractuel' pendant toute la vie du projet. Il existe des exemples: disponible ici aux Pays de Galles et ici à Boston.

Toutefois, l'équivalent d'une session de travail en équipe pour la définir ... reste à définir. Nous avons tous intérêt à créer une approche pour les 'business cases', comme celles qui existe ici pour des 'business models'.

Les pièges cognitifs sont des sortes de trempes à l’œil de la pensée. Venez les découvrir sur le lien suivant: Cognitive biases a visual study guide ou bien aux "biais cognitifs" à wikipedia". 

Ils vont devenir très importants dans la vie décisionnelle de l'entreprise. Ils le sont déjà !

Nous avons des réflexes de la pensée, comme des intuitions, qui nous permettent d'agir rapidement et souvent efficacement, sauf qu'il y a peut-être quelque-chose d'important que nous n'avons pas remarqué...

Ou bien, nous réfléchissons longuement jusqu'à la paralysie de l'analyse, alors qu'on aura mieux fait de mettre quelques idées à l'expérimentation. Et parfois, lorsqu'on fait de l'expérimentation ou aura mieux fait de nous servir de notre intuition ! Savoir où on doit se situer dans la pensée s'appelle la "métacognition". 

AgilePM est une démarche de « management de projets agiles créée afin d’offrir aux chefs de projet une approche rodée, évolutive, et adaptée à l’échelle de l’entreprise ».  SAFe (Scaled Agile Framework) est présentée comme une « base de connaissances interactive pour la mise en œuvre des pratiques agiles à l’échelle de l'entreprise ».  Quelle est la distinction la plus importante entre ces deux approches ?

Pour moi, la prochaine question essentielle pour les démarches  agiles, de tout genre, consiste à impliquer la direction pour des projets de grande importance stratégique, à savoir les projets qui auront un impact significatif sur l'avenir de l'organisation. D'après mon expérience, les décisions stratégiques dans des projets agiles sont prises chaque jour sur les sujets concernant les technologies et les clients, alors que, malheureusement, les cadres supérieurs se tiennent en dehors du processus.

Ainsi, les équipes sont "au pouvoir",  en principe (car souvent sans pouvoir budgétaire), mais cela ne signifie pas que « la hiérarchie » doit être absente.  À mon avis, dans un projet hautement stratégique, les directeurs doivent se rendre disponibles lorsque la situation l'exige, et même en pleine «timebox » (en principe,  un« sprint » ne permet pas cela).

La philosophie de SAFe exprimée dans les «41 choses que vous devez savoir» évoque l’idée « d’une stratégie centralisée» avec «une exécution locale.  Mais, comment alors la direction peut-elle participer à «l'exécution locale » ?  Réfléchissez comment une personne telle que Jobs, Gates, Dyson, Bezos ou Chanel participerait à des projets stratégiques.  Donnez de l'espace à l’équipe, mais mettez-vous à leur disposition le cas échéant, leur donnez du courage et encouragez les membres de l'équipe en cas de besoin. (Ne pas les étouffez, mais leur donnez de l'oxygène.)

Scrum décrit le rôle d'un «Product Owner» et SAFe esquisse les grandes lignes du rôle de «Product Manager ».  Toutefois, ces rôles sont souvent délégués à un niveau plus bas que la prise de décision stratégique.  Compte tenu de l'importance des décisions qui seront prises au cours du cycle de vie souvent mouvementé d'un projet agile, la gouvernance d'un projet «stratégique» devrait être située au niveau du conseil d’entreprise.  Combien de «chefs de produit» siègent au conseil d'administration?

J’ose identifier dans AgilePM / DSDM de l’APMG des ingrédients pour une présence renforcée de la direction : au sein du « rôle de visionnaire » et les conseils pour l'utilisation d’un « business case », et dans le détail des « Stage Gates » de Robert Cooper (des « portes avec des dents ») la participation des équipes dans les jalons, et dans des oeuvres de conception et de développement de produits,  tels que dans approche d'ingénierie stratégique d’Ulrich et Eppinger via le «livre de contrat», et «design thinking» en général, et dans le BABOK de l'IIBA.  Je ne le vois pas explicitement dans Lean pour la production, mais en Lean Start-Up d'Eric Ries, via les «pivots» et les «indicateurs réalisables».  On le voit aussi dans la gestion des parties prenantes dans le PMBOK v5 de PMI et dans la structure de rapports d'exception de PRINCE2 de l'APMG, et dans le rôle de «Sponsor» agissant en tant que «Champion Exécutif», présent dans toutes les approches susmentionnées.

Pour moi AgilePM est une façon d'envelopper toutes ces choses ensemble et d'impliquer la direction dans la prise de décisions cruciales au sein de projets agiles d'importance stratégique élevée.   

Si vous regardez l’étude annuelle « Agile Trends & Benchmark Report », produite par SwissQ, une société de conseil spécialisée dans les technologies de l'information et des pratiques de tests, et (page 4) vous trouverez une courbe de maturité qui montre que Scrum s’approche d’une phase de  post-maturité et DSDM se trouve dans la phase d'introduction du cycle de vie.

L'enquête révèle (page 5) que: "54% de tous les projets agiles échouent en raison de difficultés à concilier la philosophie d'entreprise avec des valeurs agiles»,  «les projets Scrum demeurent des îlots qui sont largement auto-organisés» et que «17,9% de praticiens des méthodes agiles utilisent ‘definition of ready’,  alors que 62,1% utilisent ‘definition of done’».

Certes, 42,2% des statistiques sont inventées bien sûr ;-)  Néanmoins, pour moi, la signification est dans les rôles.  Des consultants en pratiques de tests recommandent un «testeur intégré», une notion qui est ancrée au sein de DSDM. Scrum insiste à plusieurs reprises sur l'indépendance de l'équipe de toute intrusion de la direction et le rôle du ‘Product Owner’ consiste à «servir le client». (Eh oui: il est important de savoir ce que les mots «servir» et «client» devrait signifier à chaque fois ;-)

SAFe décrit le rôle de ‘Product Manager’ d'une manière qui évoque une gestion hiérarchique.  Le chef de produit "communique la vision" à l'équipe et "maintient la feuille de route du produit." http://www.scaledagileframework.com/product-management/ En substance ce rôle est «typiquement un membre actif de l'équipe de gestion de portefeuille de projets, où on participe à la prise de décisions sur les principaux vecteurs économiques pour les versions futures".

Avec DSDM, le visionnaire d'affaires « définit la vision de l'entreprise », favorise l’interprétation de cette vision en actions, surveille l’avancement réalisé en conformité avec la vision de l'entreprise, communique et favorise la vision à toutes les parties intéressées, etc   Ceci est potentiellement un rôle beaucoup plus proactif et élevé.

A mon sens, ce sont des points clés: Un projet «stratégique» peut «faire pivoter» la vision de l'entreprise. Un projet stratégique agile peut contraindre à engendrer des réorientations fréquentes de la vision au cours du projet.  Une clarification de cette vision implique un dialogue interactif, un degré de confiance et de respect mutuel entre l'équipe de développement (la technologie) et l'entreprise (le marché).  La phrase « définit la vision de l'entreprise» doit admettre la participation et encourager l'appropriation par les partenaires. Tous les partenaires de cette élaboration et de mise en forme de la vision de l'entreprise doivent apprendre à comprendre le vocabulaire, non seulement de la technologie (agile ou autre), mais aussi de l'entreprise.

Les histoires sont une façon agréable d'illustrer des questions de management. L'histoire de la construction des cathédrales en est une. On y retrouve un chevalier, un tailleur de pierre, un maçon, et un bâtisseur de cathédrales. 

Je pense que beaucoup d’équipes Scrum sont un peu comme les maçons: apeurés à l'idée d'être refoulés dans le rôle de tailleur de pierre, ou convertis en pierre par un regard de sponsor, de chef de projet, ou de visionnaire de projet, alors que nous voudrions les inviter à devenir des bâtisseurs de cathédrales.

Une équipe Scrum pourrait dire: «Dites-nous ce que vous voulez, partagez vos priorités et nous le construirons pour vous ; simplement ne nous dérangez pas."  Ce n’est pas beaucoup demander, et il est regrettable que les attentes vis à vis du management soient actuellement si basses. 

Nous pourrions proposer beaucoup plus. «Voilà pourquoi nous avons besoin de ces résultats pour lesquels nous sommes responsables; si vous pouvez nous aider à préciser les priorités, vous déciderez comment le travail devra être fait."  Si l'équipe Scrum démontre un intérêt  pour les résultats et les priorités (impératives, souhaitables et facultatives) qui sont atteignables grâce à leurs efforts, alors c'est leur droit de décider comment ils veulent faire leur « mêlée. »

Les histoires de management peuvent être fascinantes.  A l’époque de la construction des grandes cathédrales et d'autres gros œuvres, les chefs de chantiers qualifiés étaient très recherchés: maîtres maçons, architectes, menuisiers (maître d'œuvres) et la maîtrise d’ouvrage - tout comme pour la construction de navires. Plus tard les membres de l'équipe sont devenus des «compagnons» dans le mouvement de « compagnonnage».

Dans la terminologie de «Lean Start-Up», un «pivot» est une adaptation délibérée aux hypothèses de base sur un nouveau produit, système, service ou processus. Pour la mise en œuvre de la notion de pivots, une entreprise cherche des retours d’expériences avec des clients et des utilisateurs existants ou potentiels, tôt et souvent, et utilise les évaluations afin de changer d’orientation, soit légèrement ou radicalement.

Le pivot permet à une entreprise, star-up ou entreprise déjà établie, d'essayer des hypothèses, à faire des investissements à coûts minimaux pour un maximum d'informations. Par exemple, les clients veulent-ils regarder le produit sur le web et acheter dans le magasin, ou regarder le produit dans la boutique et acheter sur le web?  Ces hypothèses et ce qui les touche sont assez importants.  Dans quelle mesure les personnes sont-elles à la recherche d'un produit, sur l'étagère 'prêt à utiliser', d'un service, des conseils, du soutien, de la formation... ?

Qui sait? Il ne peut être qu’un petit détail ou une façon de faire qui pourrait avoir un impact significatif sur le comportement des clients.  Ou bien il pourrait être quelque chose de plus radical, qui vous permettrait de faire une percée dans la technologie, du marketing et de modifier le modèle économique tout entier.  Par exemple, que voudraient faire les utilisateurs par téléphone, avec une tablette, un PC ou dans le ‘cloud’ ?  Le point clé des «pivots» est qu’il s’agit de l’expérimentation par l’essai et par l’erreur, mais ils apportent aussi la réussite et l’apprentissage grâce à des révisions.

Voici quelques explications et des exemples de différents types de pivots, inspiré par le livre Eric Ries "Le Lean Start-Up" et aussi par Osterwalder et Prigneur dans leur "Business Model Generation" toile.

(Il faut comprendre que le mot ‘lean’ ne signifie pas mourir de faim, maigre ou affamé. Cela signifie « fit for purpose », (apte et en forme physique), éviter l’inutile en faveur d’un travail utile, et travailler sur ce que les clients sont prêts à vous payer pour faire, soit plus tôt ou plus tard, plutôt que de faire choses inutiles juste pour avoir l'air occupé. Si nous étions tous ‘lean’ à la maison, par exemple, nous aurions plus de temps pour faire les choses que nous aimons vraiment faire.)