Cet article fait partie d’une série intitulée « Il était une fois un projet IT en Kanban », débutée en 2013 et décrivant les différentes étapes de l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basée sur la mise en place d’un système kanban.

Les épisodes précédents :

• Il était une fois un projet IT en Kanban (Episode 1) : Du Story Mapping au Kanban) ;
• Il était une fois un projet IT en Kanban (Episode 2 – Part I) : Indicateurs Graphiques ;
• Il était une fois un projet IT en Kanban (Episode 2 – Part II) : Mesurer la performance du système avec les KPI ;
• Il était une fois un projet IT en Kanban (Episode 3) : Tenez vos promesses avec la prédictibilité;
• Il était une fois un projet IT en Kanban (Episode 4) : Améliorer la qualité de vos Stories ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie I) : Gérer les obstacles – La fiche Kaizen ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie II) : Gérer les obstacles – Le Kata ;
• Il était une fois un projet IT en Kanban (Episode 5 – Partie III) : Gérer les obstacles – Le A3 Problem Solving.

Ce sixième épisode est l’occasion de mettre en avant un sujet récurrent, sur les projets agile que j’accompagne habituellement : comment peut-on gérer les adhérences (nommées également contributions) avec des équipes externes, agile ou non.

Qu’est-ce qu’une adhérence externe ou contribution ?

Un adhérence externe représente le développement d’une activité (story) fonctionnelle ou technique, nécessaire au bon fonctionnement d’un produit et dont la réalisation est effectuée par une autre équipe que celle intervenant sur le projet.

Nombre de projets/équipes agiles sont confrontés à cette problématique d’être en attente de livraison d’un ou plusieurs composants, par une autre entité, sans avoir la moindre visibilité sur leur date de livraison et leur avancement.

Comment avons-nous géré les contributions sur notre projet ?

Etant donné (État des lieux et analyse)…

Dans le cas de notre projet, l’adhérence identifiée portait sur la partie édition de contrats, dont le développement était géré par une entité externe, que nous nommerons dans la suite Équipe Alpha. La méthode de gestion de projet mise en œuvre par cette entité est le cycle en V, avec des développements en offshore.

L’équipe kanban était, quant à elle, composée d’un Product Owner, d’un Proxy Product Owner (là, je sens que ça va troller), d’une personne en charge de la rédaction et du passage des cas de test et d’une équipe de développement de 4 personnes.

Cette contribution a été identifiée, dès le lancement de la démarche kanban, comme un obstacle ou tout du moins un risque sur la capacité de l’équipe projet à tenir son engagement de livraison à la date prévue. Ce sujet a donc été traité, via une fiche kaizen et un kata, pour aboutir à un A3 décrivant les actions à mettre en œuvre (voir les articles de l’épisode 5 pour plus de détails sur la gestion des obstacles).

La première étape a été de prendre contact avec l’équipe Alpha, afin de lui présenter la démarche kanban, mise en œuvre sur le projet, la roadmap et les objectifs de l’équipe projet. Cela a également été l’occasion de revoir le mode de fonctionnement de l’équipe Alpha :

1. Une demande de développement est réalisée via la rédaction d’une expression de besoin détaillée ;
2. Un devis est réalisé, ainsi qu’une proposition de planning de livraison ;
3. Les développements sont réalisés par une équipe offshore ;
4. La livraison est effectuée à la fin de la phase de codage et de tests unitaire, pour les tests d’intégration.

Nous avons ensuite étudié la possibilité, pour l’équipe Alpha, de se réorganiser en mode agile. Au vu des délais courts du projet et de la relation contractuelle avec l’équipe de développement offshore, cette solution n’a pas été retenue.

Lorsque (Actions mises en oeuvre) …

Etape 1 – De l’expression de besoin aux cartes kanban

La première action mise en œuvre, a été d’identifier un « Agent de liaison » (faut vraiment que j’arrête de regarder NCIS) entre l’équipe kanban et l’équipe Alpha, ayant en charge la rédaction de l’expression de besoin et la relation entre les deux équipes. Une autre activité essentielle, que cet « Agent de liaison » a eue, a été de découper l’expression de besoin, sous forme de fonctionnalité, de type story.

Ces stories ont ensuite été écrites sur des cartes kanban dédiées :

Etape 2 – Rendre visuel les adhérences

Après avoir identifié nos cartes kanban d’adhérence, nous avons créé un tableau de suivi de leur réalisation, à côté du Management visuel de l’équipe kanban.

À ce stade, nous pouvons suivre l’ensemble des sujets en adhérence avec notre projet. Néanmoins, comment connaitre les impacts de ces adhérences sur les users stories de l’équipe kanban ?

Etape 3 – Lier les adhérences aux user stories et aux MMF

Lors du découpage de l’expression de besoin, en carte kanban d’adhérence, l’équipe kanban a constaté que certaines user stories ne pourraient pas être totalement validées, sans la livraison par l’équipe Alpha d’une fonctionnalité. Le risque était donc de se retrouver avec des stories développées, mais non testables, ce qui aurait eu pour conséquence une perturbation du système kanban, la génération de goulet d’étranglement et une perte de la prédictibilité de notre système.
Pour éviter que ce risque ne se produise, nous avons mis en place le processus suivant :

• Ajout, dans le système kanban, d’une étape (buffer) d’attente des stories. Les stories restent en attente jusqu’à ce que l’équipe kanban ait une visibilité fiable sur la date de livraison d’une adhérence à laquelle elles sont liées. Dès que cette confirmation est donnée, la story peut être tirée dans la phase de développement et ensuite être testée avec son adhérence.
• Ajout d’un identifiant visuel unique (pictogramme) entre une adhérence et la ou les stories auxquelles elle est liée. Cela nous a permis, d’un simple coup d’œil, de visualiser les liens entre les stories et les adhérences et de mieux gérer la priorisation. Pour les adhérences n’étant liées à aucune story, mais uniquement à la MMF (Minimal Marketable Feature), aucun identifiant n’est affiché.

Etape 4 – L’équipe Alpha en Guest Star des Daily Meeting

L’ensemble du suivi de l’avancement a été effectué par notre « Agent de liaison », qui était en contact direct avec l’équipe Alpha. Mais cela n’a pas été suffisant pour garantir une efficience de notre processus et garantir une livraison des composants aux échéances prévues.

Nous avons donc, tout simplement, invité le responsable de l’équipe Alpha sur ce projet, à nos daily meeting (réunion d’équipe quotidienne). Cela a permis d’instaurer une communication de partenariat, une confiance mutuelle et de sensibiliser au quotidien notre partenaire sur nos attentes/priorités.

Alors (Résultat)…

Alors ? Eh bien, l’ensemble des fonctionnalités que nous attendions de l’équipe Alpha a été livré dans les délais prévus, avec un niveau de qualité très satisfaisant. Le plus a été que le processus mis en œuvre a également permis de faire disparaitre l’effet tunnel, avec une livraison des composants au fil de l’eau et une forte réactivité de l’équipe Alpha dans l’ajustement des priorités.

Un facteur, qui était à l’origine identifié comme un obstacle majeur du projet, a au contraire permis de rendre notre système kanban plus efficient et prédictible, sans oublier la tenue de ses promesses par l’équipe projet. Cela a également généré une meilleure communication entre des équipes distantes et appartenant à des organisations différentes.

L’aspect humain, l’implication et la motivation des équipes partenaires a également été un facteur déterminant dans la réussite de ce processus.

Take Away (Allez plus loin)

Bien entendu, ce processus est aussi applicable lorsque votre système kanban est en adhérence avec plusieurs équipes. Votre tableau de suivi peut alors être découpé en « ligne d’eau », dont chacune représentera une équipe contributrice. Cela nécessitera également la mise en œuvre d’une instance de coordination entre ces contributeurs et le système kanban.

Vous pouvez également lire l’excellent livre de Laurent Morisseau « Kanban pour l’IT », dont la quatrième partie aborde ce sujet de liens entre équipes projets, au travers d’un réseau de systèmes kanban (page 230).

 

Note de l’auteur : J’ai à l’origine créé cet article sur le blog Xebia ou vous pouvez le retrouver.