Sélectionner une page

Dans cette série d’articles, je vais essayer de vous faire vivre la vie d’un coach agile dans des situations de transformation d’organisation. Les cas sont simplifiés pour des raisons d’écriture et de compréhension. Les discussions sont résumées. Dans les situations réelles des cas présentés, les attitudes, les pensés ou croyances sont parfois relativement subtiles. Comme on dit le diable se cache dans les détails. Mais je ne souhaite pas aborder ses subtilités dans ces cas d’étude.

Chaque cas d’étude sera constitué d’une description de la situation provenant d’une observation faite sur le terrain, d’une analyse de la situation, et pour finir une liste d’actions à mener par le coach. Des mots barbares sont forcément glissés dans les différents cas. Pour vous aider à mieux les comprendre, je mets à disposition des ressources vous permettant de mieux comprendre ces mots dans la section « Pour Aller plus loin ».

Cas d’étude

Le cas d’aujourd’hui porte sur une problématique de découpage d’une fonctionnalité. L’équipe est une équipe Scrum avec un Product Owner, un Scrum Master et plusieurs membres d’équipe ayant toutes les compétences nécessaires à la réalisation d’une application de gestion.

Observations

Lors du Sprint Planning voici l’échange qu’il y a eu :

PO : Il est temps pour nous d’attaquer le système d’inscription à une formation. Il y a deux Items dans le product backlog qui s’y rapportent. L’estimation que vous avez réalisée ne montre qu’ils ne peuvent pas être réalisés en totalité dans ce Sprint. Comment pourrions nous faire ?

Un membre de l’équipe : C’est vrai qu’il y a beaucoup de cas ! D’un autre côté, nous avons vu que si nous faisons la base d’un coup, cela nous ferait gagner du temps de développement mais nous ne ferions que cela dans le prochain Sprint.
Un membre de l’équipe : Nous pouvons montrer le schéma de base de données et en utilisant notre éditeur nous effectuons quelques requêtes d’enregistrement et de lecture.

PO : C’est démontrable, mais cela n’apportera pas de valeur à nos utilisateurs, d’autres propositions ?

Un autre membre de l’équipe : Nous pourrions juste réaliser le cas nominal pour les utilisateurs connus du système. Les cas tordus, les cas des utilisateurs anonymes et le cas des clients premium pourront être traités dans un prochain Sprint ?

PO : Non, cela n’aurait pas de valeur pour nos différents utilisateurs. La proposition n’est pas viable. Il faut absolument tous ces cas sinon cela n’a pas de sens au niveau métier.

Encore un autre membre de l’équipe : Écoutez-moi, j’ai la solution ! Nous pouvons les réaliser toutes les deux dans le sprint en réduisant le temps consacré aux tests unitaires et en simplifiant l’intégration de composant dans le système en dupliquant tel composant et apportant les modifications spécifiques.

PO : Parfait, allons-y ! Tout le monde est d’accord ?

Exercice
Avant de lire la suite de l’article je vous propose de répondre aux questions suivantes :
* Qu’observer vous ?
* Que pensent les membres de l’équipe et le PO ?
* Quelles sont les habitudes de l’équipe ?
* Quel pourrait être le résultat du Sprint ?

Analyse

Le résultat du sprint planning est la mise en réalisation de 2 items trop gros. Il y a alors un risque d’échec de l’équipe sur ce Sprint. Si l’équipe échoue sur ce sprint, elle va limiter sa capacité d’adaptation et retarder la livraison de valeur en ayant créé un effet tunnel non désiré. Par conséquent, les clients et utilisateurs seront moins satisfaits et leurs précieux retours seront, eux aussi, retardés dans le temps. L’équipe se fait alors berner par ses habitudes ! La time box du Sprint vient changer la donne.

La granularité de travail était au bon niveau avant la mise en place de Scrum. Mais l’équipe n’a pas identifié que ce niveau n’est plus adapté. Cela passe en dessous de son radar à problème. Comment cela est-il possible ? Regardons ensemble les comportements qui amènent à ce résultat. Les habitudes et comportements sont issus souvent de croyances. Il se transforme, parfois, en dogme.

Croyances de l’équipe de développement

Première croyance : si nous ne faisons pas en même temps telle action et tel autre, alors au final cela va prendre plus de temps.
Si mon objectif est d’optimiser mes temps de développement alors je peux suivre aveuglément cette habitude. Malheureusement, mon objectif est tout autre, je souhaite livrer au plus tôt et obtenir un retour sur ce que j’ai fait par les utilisateurs et clients. En suivant cette habitude, j’allonge ma boucle de feedback sur le produit.
Souvent en réponse à cela le développeur indique qu’il lui faut seulement 5,10,15… 60 min en plus pour le faire alors que s’il le fait en 2 fois cela va lui prendre au moins 2 fois plus de temps.
Ce qui est vrai pour la partie développement ! Qu’en est-il de la mise au point du logiciel, des tests, de la création de jeux de données spécifique, de la documentation utilisateur et de toutes les tâches annexes qui seront associés a ces fonctionnalités implémenter en moins de 10 minutes ? Et si la fonctionnalité en plus n’était pas si utile que cela (voire inutile), est-ce que vous la réaliseriez ?

Deuxième croyance : Le découpage en composant ou en couche est une habitude prise toujours dans l’objectif d’optimiser le temps de développement. Chaque personne devient spécialiste d’un composant ou d’une zone de l’application. Je ne développe pas ici. Je traiterai le sujet dans un autre cas d’étude sur les silos.

Croyances du PO

Si nous n’avons pas tout, alors nous n’avons rien ou ne délivrerons peu ou pas de valeur.
Cette croyance est intéressante car la notion de MVP souvent véhiculée par les Agiliste vient la renforcé. Mais l’habitude derrière cette croyance est l’habitude de tout prévoir et d’imaginer la solution dans le moindre détail. Cela ne laisse aucune place à des solutions innovantes ! Celles-ci peuvent être découvertes lors de discussion entre les utilisateurs et l’équipe de développement.
Elle cache aussi souvent une autre croyance : Le PO doit définir dans le détail tous les Items comme s’il était un « Business Analyste » ou un concepteur fonctionnel. Je ne vais pas non plus rentrer dans les détails des effets de cette croyance. Je la traiterais dans un autre cas d’étude pourtant sur les rôles et responsabilités de chaque membre de l’équipe Scrum.

Comportement dangereux

La dernière proposition faite par un membre de l’équipe de développement est extrêmement dangereuse : proposer de faire dans les temps en sacrifiant la qualité !
Cela est aussi une habitude prise lors de la réalisation de projet contraint par le coût, les délais et le périmètre. La qualité vient en sacrifice pour garantir ce triangle infernal. Mais cela est une illusion car en sacrifiant la qualité, vous allez augmenter le nombre de défauts et donc : allonger les délais et augmenter les coûts. Si l’équipe continue à avoir ce comportement par rapport à la qualité, elle va diminuer sa capacité de livraison et d’adaptation. Au final, ce sont les utilisateurs et les clients qui en pâtiront.

Exercice
Avant de lire la suite de l’article je vous propose de répondre aux questions suivantes :
* Que proposez-vous à l’équipe ?
* Comment allez-vous vous y prendre ?

Actions de coaching

L’équipe Scrum a les ressources pour réussir, ses croyances la limitent dans sa capacité d’être agile. Nous savons qu’il n’est jamais bon d’indiquer verbalement que le coaché a une croyance. Notre objectif est de les assouplir, si nous n’avons pas le choix. Sinon nous allons faire découvrir les résultats de nouveaux comportements.
Dans un premier temps, nous allons faire vivre de nouvelles expériences dans un environnement sécurisé. Puis, dans un second temps, nous allons amener l’équipe à reproduire ce qu’elle a vécu dans son propre environnement. Nous allons nous appuyer aussi sur les comportements de l’équipe aidant. L’équipe Scrum communique et s’auto-organise pour trouver une solution à sa problématique.

L’une des propositions faites par les membres de l’équipe de développement allait dans le sens d’un découpage fonctionnel des items d’un niveau de granularité permettant une gestion de priorité plus aisée par le PO et un développement ou de petit succès en petit succès permettra à l’équipe de gagner en confiance.

Plusieurs opportunités peuvent se présenter à vous. Ici, je propose deux opportunités.
La première opportunité : Intervenir par le questionnement pendant le Sprint Planning. Dans ce cas de figure, j’ai posé mon cadre d’intervention au préalable et l’équipe est d’accord. En variante : intervention lors d’une action de « Refinement » de l’équipe ou lors de la rétrospective. La difficulté ici est le questionnement pour que l’équipe puisse prendre conscience de ces habitudes sans qu’elle se sente coupable afin qu’elle puisse modifier son comportement. Si elle m’interpelle sur les stratégies, je lui propose de regarder le diagramme : Story-Splitting-Flowchart-FR.pdf et nous entamons une discussion sur quelle stratégie à employer. Comme un enfant en train d’apprendre à faire du vélo, elle cherche son équilibre. Je l’invite à faire des essais sur le même item avec différentes stratégies et de regarder les résultats ainsi obtenus.

La deuxième opportunité : Mise en place d’un atelier de 2 à 3 heures.
Cet atelier se base sur l’atelier de Alistair Cockburn : « Elephan Carpaccio ». Le plus gros travail est d’amener l’équipe à se projeter sur ce qu’elle fait et ne fait pas lors du débriefing. Ainsi l’équipe entame une discussion sur le découpage, la granularité et les stratégies à utiliser qui sera bénéfique par la suite. Pour la stratégie, vous pouvez vous appuyer sur le diagramme : Story-Splitting-Flowchart-FR.pdf

Quelle que soit l’opportunité de coaching exploitée, ce qui est important pour moi est que l’équipe ouvre une discussion sur ce qu’elle fait et de l’impact de la granularité des items sur sa réussite. Au final, elle est la mieux placée pour savoir si c’est ou n’est pas la bonne granularité pour elle !

Pour aller plus loin…

Livres

Changer les systèmes de croyance avec la PNL (Anglais) Broché – 27 février 2006 – Robert Dilts
Le langage du changement. Éléments de communication thérapeutique (Anglais) Poche – 5 juin 2014 – Paul Watzlawick
Les accords toltèques au quotidien, c’est malin : En couple, avec vos enfants, au bureau… Libérez-vous de vos croyances limitantes ! – 17 novembre 2017 – Xavier Cornette de Saint Cyr

Ressource Web

http://www.scrumguides.org
https://agileforall.com/splitting-stories-in-french/
https://fuehrung-erfahren.de/en/2018/08/no-more-elephant-carpaccio/
https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
Un excellent guide de l’atelier Elephan Carpaccio : https://docs.google.com/document/u/1/d/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk/pub

Nicolas DELAHAYE