L’agilité dans une organisation traditionnelle – un sprint de transition

Le contexte

  • Une organisation interne sur un modèle MOA/MOE avec une MOA détachée de la DSI depuis peu
  • Des équipes de réalisation d’un bon niveau technique, composées d’internes et de prestataires. L’équipe type : un chef de projet et des développeurs
  • Une infrastructure technique encourageante (projets structurés, intégration continue)
  • Un projet démarré il y a 6 mois avec la volonté initiale du middle management de faire les choses bien et de se réconcilier avec des applications existantes qui coûtent cher à maintenir
  • Une mise en production prévisionnelle pour mi mars qui aura finalement lieu ces prochains jours

Lorsque le projet a démarré, il y avait cette volonté unanime dans l’équipe de réalisation (composée de 5 personnes dont certaines formées / sensibilisées à Scrum) de mettre en oeuvre un ensemble de pratiques agiles. Les objectifs ? Améliorer la communication, l’autonomie de l’équipe, favoriser les prises d’initiatives, combattre l’effet tunnel, entre autres.

Bien entendu, à la vue du contexte, le lecteur avisé devinera que cette initiative est locale et non globale, qu’il n’y a aucune adhésion de la part du top management dans les démarches agiles, et que le périmètre ne s’étend pas aux interlocuteurs MOA.

Résumé des 6 derniers mois

Vous vous doutez bien de la difficulté d’introduire des pratiques agiles à un niveau local dans un tel contexte. Après une première tentative lors de la mise en place du projet à partir des informations contenues dans le draft des spécifications fonctionnelles du premier lot, l’équipe accuse le coup. Manque de repères, des tâches techniques estimées tant bien que mal, des spécifications fonctionnelles qui n’en finissent pas de bouger et de décaler le véritable démarrage des développements, obligeant l’équipe à s’impliquer dans la relecture proactive des spécifications.

Le management veut des dates, l’équipe finit par constituer son carnet de produit (product backlog) à partir des spécifications et en estimant les histoires (user stories) … en jours. Le Scrum quotidien (Daily Scrum) tourne vite au reporting des activités au chef de projet (Scrum Master volontaire et désigné) ainsi qu’à des séances collectives de conception / résolution de problèmes peu productives : l’équipe subit et personnellement j’ai l’impression de perdre mon temps lors du daily De plus, l’équipe, avec son Scrum board, ses post-its et ses rituels, devient vite l’attraction de l’Open Space : moqueries maladroites et décrédibilisation pas évidentes à accepter pour une équipe qui se veut volontaire et sérieuse.

Enfin, la complexité des histoires rend le premier sprint fonctionnel très peu productif et l’équipe, après avoir fait le constat de l’impossibilité de constituer des sprints de durée fixe (pas de priorisation, livraisons en recette par lots), amène l’équipe à mettre en suspens le Scrum quotidien tout en maintenant l’utilisation d’un Scrum Board (à faire / en cours / fait) avec désormais un découpage des histoires en tâches.

Quelques semaines plus tard, au cours d’une rétrospective improvisée, l’équipe dresse un bilan dont un des constats est la faible circulation de l’information (imputée à l’abandon du Scrum quotidien). L’équipe décide donc de remettre au goût du jour le Scrum quotidien en prenant soin d’éviter les travers du passé. Les délais se faisant de plus en plus pressants, l’organisation évolue de façon à spécialiser les développeurs par domaines fonctionnels, situation délicate par rapport à l’appropriation collective du code. Les retours de la recette du premier lot sont extrêmement positifs : encourageant !

Quelques évolutions fonctionnelles plus tard, nous avons livré il y a plus de deux semaines l’application en recette, commençons à traiter les premiers retours et absorber les ajustements occasionnés par les incohérences détectées et problématiques d’intégration. C’est également officiel : l’équipe va enchaîner sur un nouveau périmètre dont la mise en production est fortement souhaitée pour septembre.

Que faire donc pendant cette période de creux ? Fort d’une formation récente de type Scrum Master, et compte-tenu de ma frustration à voir l’équipe s’investir dans la douleur (l’équipe est « sans cesse en train de sprinter ») sans obtenir de satisfaction, j’ai donc décidé la semaine dernière de porter mon énergie sur cette période transitoire afin de donner à l’équipe les moyens de se mettre dans de bonnes conditions pour la suite.

Préparation d’un sprint transitoire à connotation technique

L’équipe a tout au long du projet fait des efforts sur le thème des tests, mais elle a conscience que la couverture est plus que moyenne. L’équipe est également en souffrance dans certaines tâches qui lui coûtent beaucoup (trop) de temps.

Construction d’un backlog

Objectif : identifier les tâches, actions, que l’équipe juge pertinente de faire durant les prochains jours en prévision du démarrage des développements sur le nouveau périmètre

J’ai réuni l’équipe, expliqué l’objectif, puis l’équipe s’est mise à discuter et à décrire de manière concise des items touchant à des sujets comme :

  • le partage d’informations critiques sur le Wiki
  • la documentation technique
  • les préparatifs pour la mise en production
  • la maintenance et l’enrichissement des tests
  • la réorganisation de code existant
  • la recherche ou construction d’outils améliorant la productivité de l’équipe
  • etc.

Durée : 1h30′

Résultat : 36 items sous la forme de post-its

Rendez-vous fût pris avec l’équipe pour le lendemain 10h et une journée supposée riche en contenu.

Objectif : classer les items identifiés la veille en en estimant la valeur ajoutée relative

Je distribue à chaque membre de l’équipe une feuille reprenant les 36 items (que j’ai pris soin de numéroter) et leur permettant de prendre des notes pour préparer l’identification de la valeur ajoutée relative de chacun d’entre eux.

1ère étape : Présentation des 36 items pour que l’équipe se les approprie

J’ai proposé à l’équipe que chacun présente à tour de rôle un item, l’illustre, ou à défaut pose des questions à l’équipe pour préciser sa compréhension.

Durée : 20′

Résultat : Une bonne vision du backlog et une amorce de réflexion individuelle sur l’apport de chaque item

2ème étape : définition des valeurs ajoutées relatives

J’ai distribué à chaque participant 30 pastilles de couleur à coller au dos des post-its en fonction des valeurs ajoutées estimées. Chacun emploie la méthode qui lui convient, pioche dans les post-its et leur attribue des points de valeur.

Court débriefing et confrontation de points de vue en attendant un membre pris par d’autres priorités, lequel finira pas apporter sa pierre à l’édifice en attribuant lui aussi ses 30 points (sans être influencé par la vision des post-its).

Nous écartons pour la suite les 15 post-its ayant le moins de valeur ajoutée.

Durée : 30′ en groupe + 20′ avec le retardataire

Résultat : Un backlog ordonné par valeur ajoutée

Estimation des items constituant le backlog

Objectif : Définir les attentes et critères d’acceptation pour chaque item constituant le backlog

Toujours au dos des post-its, l’équipe décrit pour chaque item ce qui est attendu pour considérer que la réalisation de ce dernier est terminée. Un mélange d’échange de visions et de prémices de conception : le tout s’avérera très utile pour la suite.

Durée : 90′ pour 21 items

Résultat : un référentiel commun à l’équipe permettant de mieux cadrer les estimations de complexité

Objectif : Estimer la complexité de chaque item

Un classique avec le Planning Poker. J’impose néanmoins au préalable à l’équipe de se mettre d’accord sur l’une ou l’autre tâche qui lui paraît élémentaire et sur laquelle un consensus d’estimation peut être trouvé. Je lui impose également une estimation en points de complexité et non en jours. L’équipe trouve son étalon et lui attribue la complexité de 1. Les estimations démarrent et se passent relativement bien. Grâce aux critères d’acceptation définis auparavant, l’équipe converge beaucoup plus facilement (parfois dès le premier vote) tout en focalisant la négociation sur la complexité et non le périmètre.

Durée : 90′ pour 21 items

Résultat : Un backlog à la fois estimé en priorités et en complexité

Consolidation et remplissage du Scrum Board

Après un repos bien mérité, j’attaque la matinée suivante par le calcul du ROI (la valeur ajoutée relative ramenée à la complexité) de chaque item et le report sur la face avant de chaque post-it du triplet (valeur ; complexité ; ROI).

Je réordonne le tout dans un tableur pour classer les 21 items par ROI, puis nous reprenons l’ensemble dans le backlog du sprint (de durée indéterminée) de transition.

Peu de surprise quand à la présence d’items touchant à la mise en production. Voici quelques exemples de couples (résumé – ROI) :

  • Recherche d’une solution de visualisation d’un (ensemble) de DataSets DBUnit – 2 (4 / 2)
  • Préparation préproduction et production – 2 (10 / 5)
  • Décrire le processus de livraison – 1 (5 / 5)
  • Restructurer le code lié aux écrans de recherche / résultat et du mécanisme de recherche, et le documenter – 0.3 (6 / 20)
  • Ecran de consultation / recherche : évaluer les requêtes SQL jouées et en optimiser la quantité pour les scénarios de recherche – 0.6 (8 / 13)
  • Améliorer la couverture de code en renforçant les tests unitaires – 1.1 (9 / 8)
  • Initier les tests Wicket – 1.6 (8 / 5)
  • Renforcer les tests Selenium – 0.5 (7/13)
  • Mutualiser la règle de gestion pour la date XX – 6 (6 / 1)
  • Mettre en place des versions locales de WDSLs pour une utilisation en Développement – 2.5 (5 / 2)

Quelques ajustements pour le lancement du sprint :

  • Une tentative de Scrum quotidien à heure fixe (9h45, soit 15′ avant que certains ne soient potentiellement indisponibles pour cause de réunion)
  • L’ajout d’une colonne « JIRA » sur le Scrum Board pour accueillir les tickets, présentés à l’équipe et affectés (traités en priorité) au cours du Scrum quotidien. L’ajout de colonnes « Livré » et « Recetté » dédiées à cette catégorie d’items.

Quelques observations

21 items allant d’une complexité de 1 à 13, c’est amplement suffisant (peut-être trop sachant que réunions et corrections d’anomalies agrémentent notre quotidien) pour occuper l’équipe pendant les 2 à 3 semaines de transition.

Nous travaillons bien entendu sur 2 branches : l’une pour le produit destiné à partir en production, l’autre pour préparer l’avenir. Si les corrections d’anomalies sont reportées sur chaque branche, nous n’excluons pas de faire de même pour certaines tâches dont le risque de mettre en péril la mise en production est faible.

Nous nous surprenons à retourner les post-its pour nous assurer de bien garder en tête les objectifs de l’item traité ainsi que les conditions qui nous permettent de le passer dans la colonne « Fait ».

Nos deux pilotes côté MOA ne se sont jamais autant arrêtés devant le Scrum Board, la faute sans doute aux post-its de type JIRA et aux quelques items relatifs à des tâches fonctionnelles. L’un d’entre eux nous a même déplacé des post-its de « Livré » à « Recetté » et a participé à quelques Scrum quotidiens. Et jusque là, personne ne s’est plaint de l’abandon partiel de l’application JIRA (qui reste utilisée pour expliciter les tickets et décrire leur résolution, mais dont la contrainte du workflow imposant une affectation des tickets par le chef de projet a été contournée pour une meilleure implication de l’équipe et appropriation du processus).

Conclusion

Ce sprint un peu particulier s’avère riche en enseignements et semble avoir une portée bien plus importante que ce qu’on pouvait penser au départ en le qualifiant de sprint technique. L’équipe a bon espoir de s’en servir pour démarrer les prochains développements fonctionnels dans de bonnes conditions. Elle pourra également compter sur une rétrospective à venir portant sur les 6 derniers mois.

Il nous reste néanmoins quelques inconnues pour l’instant :

  • Allons nous réussir à tirer profit de ce sprint pour enchaîner avec des estimations en points de complexité et non en jours ?
  • Allons nous réussir à impliquer la MOA pour fonctionner sous forme de sprint avec une priorisation des histoires, même si « tout ce qui sera spécifié sera indispensable » pour la mise en production de septembre ?
  • Allons nous pouvoir agrémenter les prochains sprints de quelques items « techniques » extraits de notre backlog technique afin de combattre la dette technique ?

Une réflexion au sujet de « L’agilité dans une organisation traditionnelle – un sprint de transition »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *