Scrum propose une approche empirique de développement logiciel et invite à s’intéresser avant tout à la valeur livrée plutôt qu’à la quantité livrée. Malgré cela, nous constatons que, même après plusieurs années de pratique, peu d’équipes réussissent à réellement s’inscrire dans cette approche empirique. Elles restent bien ancrées dans une pensée linéaire qui guide leurs décisions et actions de façon souvent inconsciente, voire insidieuse. Cette pensée linéaire les amène entre autres à associer le succès à la livraison de la portée prévue, dans les temps impartis et pour le budget prévu.
Ainsi, trop peu d’équipes Scrum réussissent à avoir un dialogue ouvert, constructif et lucide sur les choix à faire et les actions à prendre pour optimiser la valeur produite et l’intégrité technique de la solution développée. C’est une polarité complexe et difficile à bien gérer.
Mais qu’en est-il du succès?
Le succès du produit et, par le fait même, le succès de l’équipe Scrum se mesurent en fonction de la valeur de ce même produit. Dans une équipe Scrum, le Product Owner est ultimement responsable du succès du produit.
Le Product Owner joue un rôle important notamment de porteur de la vision afin de guider l’équipe vers la livraison d’incréments qui permettent de matérialiser de la valeur de la façon la plus judicieuse. Autrement dit, le Product Owner guide et stimule l’équipe de développement afin que le travail accompli produise le plus grand rendement possible de l’investissement.
En parallèle – et c’est, selon nous, une perspective trop peu souvent comprise et présente –, le Product Owner garde un œil sur le potentiel d’innovation. C’est pourquoi il encourage l’équipe à réaliser le produit dans une perspective d’effort soutenable et une conscience de la qualité intrinsèque.
Pour nous, un Product Owner d’expérience contribue également, par sa présence et ses actions, à créer un environnement stimulant où règne le bien-être de chacun. De plus, grâce à lui, cet environnement est aussi source de créativité, d’innovation et de productivité.
Un instant! Il me semble que ce qui est important, c’est de livrer ce qui est prévu, non? Le Product Owner ne devrait-il pas avant tout s’intéresser à la vitesse de développement de son équipe?
C’est en effet la perspective usuelle sur la question… et c’est le signe que la pensée prédictive et linéaire est encore à l’œuvre. Elle nous amène à faire des prédictions de vitesse pour s’assurer qu’on va bien tout livrer ce qui est prévu, à la date prévue, sans dépasser le budget. Bref, les critères habituels de succès.
La perspective empirique qui sert de fondation à l’Agilité reconnaît le caractère complexe du développement logiciel et s’inscrit davantage dans une approche spéculative. D’ailleurs, Jim Highsmith nous suggère de ne pas planifier, mais plutôt de spéculer (voir son texte Don’t Plan, Speculate [en anglais]).
C’est bien gentil la perspective empirique ou spéculative, mais un bon gestionnaire doit savoir apporter des certitudes.
L’incertitude amène naturellement de l’inconfort, c’est un fait. Nous en profitons pour vous proposer la lecture du billet Un gestionnaire Agile à cœur ouvert.
Cependant, quantité livrée ne signifie pas nécessairement valeur créée. Ça ne signifie pas non plus valeur créée au moment opportun. Si vous souhaitez en lire davantage au sujet de la vélocité, nous vous invitons à lire les billets La vélocité, une mesure fausse! et La vélocité, une mesure utile! de notre collègue Tremeur.
Il est également important de prendre une perspective de qualité afin de préserver, à long terme, la capacité d’innover et de s’adapter rapidement. Une perspective de qualité ajoute aussi à la satisfaction, voire à la fierté, du travail accompli. Nous avons la conviction que cela peut contribuer à un bien-être durable pour l’ensemble de l’équipe.
Nous croyons aussi qu’un des freins à l’adoption d’une vision axée sur la valeur plus que sur la quantité livrée, que ce soit de la part de l’équipe de développement, du Product Owner ou du Scrum Master, se trouve dans les métaphores mêmes que les équipes Scrum utilisent pour représenter et gérer leurs produits et activités.
Quelles sont ces métaphores?
La métaphore usuelle, celle utilisée par de nombreuses équipes et sur laquelle sont bâtis la plupart des outils électroniques de gestion de produit Agile, s’articule autour du feuillet Post-it® et de la carte (index card).
La carte est vue comme une unité de travail, et ce, qu’elle représente une fonctionnalité désirée dans le produit ou une activité de développement décrite dans le carnet de sprint. Elle est plus rarement perçue comme un potentiel de valeur à explorer, à valider et à exploiter.
Quelle autre métaphore nous proposez-vous?
Devant les constatations, observations et sentiments mentionnés ci-dessus, avec d’autres collègues, nous nous sommes mis à la recherche d’une métaphore qui guiderait naturellement les équipes à intégrer la pensée empirique et spéculative. Une métaphore qui permettrait aussi de se défaire plus facilement des modèles mentaux bien ancrés et restrictifs.
Voyons l’équipe Scrum comme une entreprise de prospection pétrolière. Elle gère en parallèle plusieurs sites de forage pour lesquels elle a des espoirs différents en matière de résultats. Le fait d’exploiter plusieurs sites de forage lui permet d’éviter de se retrouver avec un seul site qui pourrait s’avérer sec. C’est une façon pour l’entreprise de contrôler son risque et d’optimiser ses résultats en investissant ses énergies et ressources de façon judicieuse. Elle reconnaît le caractère spéculatif et imprévisible de son activité.
L’application au quotidien, ça pourrait donner quoi?
Une fonctionnalité, c’est un peu comme un puits de pétrole. Elle a un potentiel de valeur sur le marché qui est spéculatif. Sa valeur réelle se mesure une fois le logiciel livré, autrement dit une fois le puits exploité et le pétrole vendu.
Lors de la planification de sprint, l’équipe Scrum définit une mission de forage – c.-à-d. l’objectif du sprint – qui prévoit l’exploitation de plusieurs puits – c.-à-d. les éléments de carnet de produit qui ont été sélectionnés.
Contrairement aux postulats de la pensée linéaire, il est possible que la mission soit un succès commercial sans pour autant que les puits prévus aient été exploités. Il est également possible que l’exploitation des puits prévus ne remporte pas le succès escompté. Autrement dit, le succès de la mission et l’atteinte des objectifs de forage initialement prévus ne vont pas forcément de pair.
Pendant le sprint, l’équipe de développement se réunit quotidiennement – lors de la mêlée quotidienne – pour faire le point sur son avancement relativement à sa mission et planifier les activités de forage de la journée qui commence. Pour cela, les membres de l’équipe se posent les questions suivantes :
- Quels ont été mes résultats de forage (accomplissements) et qu’ai-je découvert comme pétrole au cours de la journée précédente (valeur)?
- Quel est mon plan de forage pour la journée et en quoi ce plan contribue à la mission de forage (valeur)?
- Quels sont les obstacles que je rencontre dans mes activités qui mettent en danger la mission de forage?
L’équipe doit rester alerte et garder ouverte la possibilité de revoir son plan de forage, et ce, à tout moment durant le sprint si elle découvre de meilleures façons d’atteindre ses objectifs de mission.
Voici quelques questions que nous suggérons et qui sont à même de mener l’équipe à une redéfinition optimisée de son plan de forage :
- Où en sommes-nous dans l’atteinte des objectifs de la mission de forage?
- Que devons-nous faire pour maximiser les chances de succès de la mission de forage?
- Que manque-t-il pour que ce puits soit exploitable?
- Devons-nous arrêter de creuser ce puits, qu’il soit exploitable ou non?
La revue de sprint est l’occasion pour l’équipe Scrum de faire le bilan des puits creusés pendant le sprint et de la valeur qui est maintenant exploitable. Elle prend en compte tout changement dans le contexte d’affaires pour décider de la pertinence de poursuivre les activités de forage et d’éventuels objectifs des missions à venir.
Voici quelques questions que l’équipe Scrum se pose dans cette optique :
- Y a-t-il une opportunité d’exploitation à saisir dès maintenant?
- Qu’avons-nous appris de la nature des sols lors de ce sprint?
- Comment devons-nous adapter nos plans de forage à venir pour créer la plus grande valeur possible dans le futur?
- Quels sont les scénarios pour le futur que nous pensons probables? Peu probables? Très probables?
- Devrions-nous continuer à financer de nouveaux forages?
Cette approche spéculative contraste fortement avec l’approche linéaire plus naïve qui consiste à simplement comparer les puits creusés avec le plan initial, ce qui mène à peu d’apprentissage et d’adaptation.
Et maintenant?
Nous espérons avoir réussi à offrir une perspective qui invite à une réflexion et à un dialogue plus riche et inclusif (plus utile) que vous pouvez mettre de l’avant de façon concrète dans vos équipes.
Pour les Product Owners, nous espérons que ce billet vous incitera à adopter une perspective axée sur la valeur créée davantage que sur la quantité livrée. Pour les Scrum Masters, nous espérons vous avoir donné des outils pour créer des espaces de conversation au sujet de la valeur. Enfin, pour les membres des équipes de développement, nous espérons que vous adopterez une position constructive et contributrice dans les conversations avec votre Product Owner et que vous ne resterez pas dans une position de résignation ou d’opposition comme nous le constatons souvent.
Pas de commentaire