L’agilité dans une organisation traditionnelle – rétrospective et perspectives

Ce billet fait suite à « L’agilité dans une organisation traditionnelle – un sprint de transition » Son objectif est de proposer un premier bilan du sprint de transition dont la préparation avait été décrite. Je vous propose également une restitution de la rétrospective faite par l’équipe sur les 6 derniers mois, avec pour principal objectif de préparer la suite.

Ayant pris du retard dans ma série de billets, il faut savoir qu’à l’heure où je rédige ce billet :

  • l’application est en production
  • la suite des développements est en cours et une mise en production est espérée pour fin septembre
  • l’équipe en est dans son second sprint (sprints de 2 semaines)

Je ne me ferais pas l’écho des interrogations levées à la fin du précédent billet, cela fera l’objet d’un billet à venir se focalisant sur l’analyse des deux premiers sprints.

Retour sur le sprint de transition

Le sprint de transition n’était pas borné dans le temps : sa fin était implicitement définie par le démarrage officiel des nouveaux développements.

Pendant ce sprint, l’équipe a également été sollicitée :

  • pour corriger les dernières anomalies identifiées en recette
  • pour préparer la mise en production
  • pour de premières présentations de spécifications fonctionnelles (générales et détaillées)

Il était clair que tous les items techniques identifiés ne pourraient être traité. En fait l’équipe n’a même pas pu traiter la moitié des items qui avaient été estimés (ceux qui avaient recueilli le plus de suffrages), soit 41 points sur le total de 118 points du périmètre priorisé.

Pour autant, l’équipe n’a pas chômé et a nettement avancé dans la lutte contre la dette technique, mais aussi dans les pratiques de test.

Outre les tâches incontournables concernant la préparation de la production, on notera par exemple les réalisations suivantes :

  • Améliorer la couverture de code en renforçant les tests unitaires : objectif atteint avec une augmentation de plus de 40 tests et 6% de la couverture sur le module core (nous partions d’environ 60%).
  • Renforcer les tests Selenium : tâche qui s’est avérée très coûteuse pour un résultat assez décevant et une maintenance périlleuse en prévision. L’objectif initial (nombre de scénarios) n’a pas été atteint, mais l’équipe a accumulé de l’expérience sur les bonnes pratiques dans le contexte applicatif qui est le sien.
  • Initier les tests Wicket : la bonne surprise avec des objectifs initiaux atteints et un début d’engouement de l’équipe pour les tests unitaires côté IHM. A l’issue du sprint, la couverture du module web avoisinait les 6% et les bonnes pratiques étaient documentées.
  • Mettre en place des versions locales de WDSLs pour une utilisation en développement : objectif atteint avec désormais un build local (génération des clients via plugin Maven) s’appuyant sur des versions locales de WSDLs, évitant d’être bloqué (freeze Eclipse du fait de l’intégration Maven) en cas d’indisponibilité, tout en ayant un build sur les Urls cibles au niveau du serveur d’intégration continue (permettant de détecter de potentielles erreurs en cas de désynchronisation des WSDLs).
  • Mettre en place des mocks pour les WebServices utilisés : objectif également atteint, celui de ne pas être bloqué lors de développements par une indisponibilité durable et de pouvoir démarrer l’application avec des mocks. Une variable d’environnement, un alias pour les beans Spring reprenant la valeur pointée correspondant à l’implémentation à utiliser, un peu de configuration Maven et Jetty et il nous est désormais très facile de basculer entre les deux modes.

D’autres éléments à relever :

  • Le Scrum quotidien a perduré, et à heure fixe (9h45).
  • L’équipe s’est approprié le nouvel espace Wiki et a largement documenté les éléments les plus pertinents et critiques.(environnements, éléments techniques, base de connaissance sur les pratiques de tests et outils mis en place). Elle est d’ailleurs très loin devant les autres équipes dans son adoption et usage du Wiki.
  • L’ajout de critères d’atteinte des objectifs d’une tâche au dos des post-its est une vraie révolution dans le rapport de l’équipe avec les tâches : chacun est attentif aux critères et s’assure qu’ils sont biens remplis avant de passer la tâche à « Fait », des discussions s’engagent même en cas de besoin sur l’interprétation des objectifs. Un très bon pas vers l’idée de définition de « Fait ».
  • Pendant 2 à 3 semaines, l’équipe avait un (tout au plus deux) objectif(s) précis : réduire la dette technique (notamment via le renforcement des tests) et préparer la mise en production. Cela s’est révélé très important en ce qui concerne la motivation de l’équipe, bien plus manifeste que sur de longues périodes lorsqu’elle avançait au radar.
  • Sans aller jusqu’au binômage, le niveau d’interactions de l’équipe a augmenté : sollicitations pour avis externe, pour relecture de documentation, feedback sur des améliorations pouvant être apportées. Tout le monde est concerné par l’ensemble des tâches présentes dans le backlog de sprint.

Nous verrons dans un billet ultérieur que ce sprint est le point de départ de la montée en puissance de l’équipe dans l’adoption et la diffusion des principes agiles. A cela s’ajoute également la rétrospective d’une bonne demi-journée que j’ai eu l’occasion d’animer et que je vais vous restituer.

Rétrospective des 6 derniers mois

Un programme assez dense :

  • Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer ;
  • Projection du projet sur les 12 principes du Manifeste Agile (niveau d’adoption) ;
  • Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel) ;
  • Déceptions / insatisfactions relevées par l’équipe ;
  • Définition du FAIT ;
  • Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir.

Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer

Pour démarrer la rétrospective, rien de tel que de parler des satisfactions. En voici quelques unes relevées par l’équipe :

  • Organisation agile de l’équipe de développement, ainsi que la communication qui l’accompagne ;
  • La transparence au sein de l’équipe de développement et à destination des autres membres du projet / service ;
  • Richesse du contexte technique ;
  • Mise en pratique / apprentissage de pratiques agiles ;
  • L’entraide dans l’équipe de développement ;
  • La qualité du code ainsi que les feedbacks reçus sur la qualité de l’application ;
  • Inspiration mutuelle sur le thème de l’agilité : il n’y a pas un unique chef d’orchestre, tout le monde contribue à l’adoption et adaptation des pratiques au contexte projet ;
  • Les engagements pris par l’équipe ont été tenus.

En matière de facteurs clé amenant à ces satisfactions, ont été mentionnés :

  • L’implication de l’équipe de développement ;
  • Les moyens mis en œuvre pour favoriser la circulation de l’information (Daily Scrum notamment) ;
  • Des développeurs interchangeables et non spécialisés ;
  • Les échanges et feedback (relecture de code, pédagogie) entre les membres de l’équipe de développement.

Enfin, d’après l’équipe, pour que ces satisfactions perdurent et s’améliorent, les points essentiels à garder dans le viseur sont :

  • Le Daily Scrum ;
  • Le courage : avoir du courage même pour les tâches rébarbatives ;
  • La documentation sur le Wiki et l’appropriation collective du code (cf. syndrome du bus et de la perte brutale d’un membre de l’équipe).

Projection du projet sur les 12 principes du Manifeste Agile (niveau d’adoption)

L’une des motivations de la rétrospective était d’examiner le niveau d’adoption des pratiques agiles à l’échelle du projet (à nuancer, compte-tenu de la configuration en MOA/MOE, par rapport à l’échelle de l’équipe). Se projeter sur les 12 principes du Manifeste Agile m’a donc paru un bon moyen.

Je vais me limiter à décrire l’analyse faite pour quelques uns (l’adoption étant évaluée sur une échelle allant de 0 – nulle – à 5 – totale) des principes agiles, même si chacune des 12 analyses est extrêmement précieuse et sert à guider l’équipe / le projet.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
  • Evaluation : 5/5
  • Analyse : L’équipe en est convaincue et l’applique au quotidien dans les interactions touchant au projet.

“Continuous attention to technical excellence and good design enhances agility.”
  • Evaluation : 4/5
  • Analyse : L’équipe le met en œuvre, dans la limite du temps qu’elle peut y consacrer (cf. sprint technique de transition), positionne les tests et le refactoring dans ses priorités techniques.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
  • Evaluation : 4/5
  • Analyse : Les membres de l’équipe sont motivés et ont le sentiment d’avoir la confiance de leur management (libertés et autonomie). Quelques progrès lui paraissent cependant possible concernant l’environnement, les moyens, et l’écoute.

“The best architectures, requirements, and designs emerge from self-organizing teams.”
  • Evaluation : 3/5
  • Analyse : Même si l’équipe n’a pas atteint une maturité d’auto organisation, elle a l’impression que son mode de fonctionnement contribue à l’émergence de solutions réfléchies. Difficilement applicable sur l’ensemble du périmètre (ex. relation SAP).

“Simplicity–the art of maximizing the amount of work not done–is essential.”
  • Evaluation : 3/5
  • Analyse : Tentatives de pratique de TDD. Volonté de faire simple. A l’opposé, beaucoup de temps passé sur les briques complexes d’interopérabilité (SAP / SOA Suite).

“Business people and developers must work together daily throughout the project.”
  • Evaluation : 2/5
  • Analyse : Si on considère que « Business people » = MOA, les échanges quotidiens se renforcent de plus en plus malgré la distance et la contrainte organisationnelle. Si on considère que « Business people » = Métier, pas la moindre interaction ni de retour sur l’application qui n’arrive jusqu’aux oreilles des développeurs.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
  • Evaluation : 2/5
  • Analyse : Le rythme des derniers mois était trop soutenu, avec des phases de pics par moment, pour que l’équipe puisse le maintenir. L’équipe pense que son investissement est bien plus important que celui des sponsors et utilisateurs.

Avec des évaluations allant de 2/5 à 5/5, l’adoption sur le projet a été estimé en moyenne à un peu plus que 3/5. Néanmoins, avec un peu de recul, on notera que l’évaluation est parfois confuse car l’équipe a du mal à rester dans un même référentiel (l’équipe de développement vs. l’ensemble des acteurs du projet).

Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel)

J’ai voulu faire faire à l’équipe un petit exercice pour la sensibiliser aux problématiques de productivité et notamment les méfaits de la réalisation par une personne de plusieurs tâches en parallèle.

Le principe du jeu est de demander aux participants d’écrire les suites 1..10, A..J et I..X sur une feuille de papier, chaque suite occupant une colonne :

  • scénario 1 : en construisant chaque suite en parallèle (on commence par une ligne 1 – A – I, suivie de 2 – B – II, etc.)
  • scénario 2 : en construisant chaque suite en série (première colonne avec les chiffres arabes, puis seconde colonne avec les lettres de l’alphabet, et enfin dernière colonne avec les chiffres romains)

Chronométrer le tout, observer et mesurer :

  • un ratio allant de 2 pour 1 à 3 pour 1 dans le temps nécessaire à l’exécution de l’exercice entre les deux scénarios (maximum de 115 secondes pour le 1er, minimum de 23 secondes pour le second) ;
  • des erreurs commises lors de l’exécution du premier scénario (« fini ! … ah non mince … ») ;
  • une concentration beaucoup plus grande nécessaire pour le premier scénario.

L’exercice a permis à l’équipe de prendre conscience de l’importance de se focaliser sur une seule tâche à la fois. La petite discussion qui a suivi l’exercice a également été l’occasion de reparler de la notion de perturbation (externe et interne) pour déboucher sur la mention du Pomodoro (même si l’équipe n’est pas forcement mature pour ce genre de pratique).

Un bon point pour l’avenir (imaginez si l’équipe, grâce à du bon sens, arrivait à multiplier sa productivité par 2 …).

Déceptions / Insatisfactions relevées par l’équipe

Passons aux mauvaises nouvelles. En effet, la situation est loin d’être idéale et la rétrospective est également l’occasion pour l’équipe d’exprimer ses déceptions et mécontentements.

Nous avons fait une première passe de déceptions / insatisfactions, chacun pouvant s’exprimer et les autres l’interroger pour bien comprendre le point soulevé. Nous en sommes arrivés à une liste de 15 items, ce qui fait bien évidemment beaucoup.

Nous sommes ensuite passé au vote : chaque membre disposait d’un jeu de cartes de planning poker et pouvait voter à face cachée (sans être influencé par les autres) de 0 (pas concerné) à 100 (extrêmement impactant). Ainsi, nous sommes arrivés à hiérarchiser les déceptions et avons pu nous concentrer sur les plus marquantes.

Pour chacun des 8 items ayant retenu le plus de vote, l’équipe a réfléchi aux axes et sources d’amélioration. En voici quelques uns.

Jusqu’à peu, le Daily Scrum n’était pas à heure fixe
  • Impact : 353/500
  • Axe d’amélioration : Daily Scrum à 9h45 jusqu’à fin juillet, puis rechercher un consensus sur l’horaire satisfaisant toute l’équipe.

Le workflow JIRA empêche l’équipe de s’auto-organiser et le chef de projet devient un point de contention
  • Impact : 333/500
  • Axe d’amélioration : Sans révolutionner le workflow, permettre aux développeurs de s’attribuer un ticket serait une amélioration notable pour l’équipe.

Scrum Master n’est pas un véritable rôle dans l’équipe. Soit il est combiné au rôle de chef de projet, soit il est absent à défaut de libérer du temps pour un développeur
  • Impact : 320/500
  • Axe d’amélioration : L’équipe souhaiterait prendre le temps de réfléchir aux objectifs du Scrum Master sur Aecetia, et de définir son rôle de manière explicite. L’équipe souhaiterait que chacun puisse endosser le rôle de Scrum Master le temps d’un sprint.

L’équipe a le sentiment de ne pas être prise au sérieux
  • Impact : 300/500
  • Axe d’amélioration : A l’image des présentations DBA faite dans le pôle, saisir l’opportunité de faire des présentations courtes sur Scrum et le vécu / l’expérience de l’équipe. Exposer les règles du Daily Scrum et convier les gens en tant que spectateurs.

Nous verrons en conclusion la suite donnée à cette réflexion sur les insatisfactions.

Définition du FAIT

Ayant noté des divergences (post-it déplacé alors que le code n’est pas commité) et difficultés (navigateur cible Internet Explorer, la majorité de l’équipe étant rompue à l’utilisation de Firefox) sur la vision du FAIT, j’avais également mis comme objectif une première définition écrite du FAIT.

Arrivant en fin de journée, le premier jet ne m’a pas paru satisfaisant (la fatigue aidant) et nous avons repris la réflexion plus tard, ce qui nous a amené à la liste suivante :

  • Code commité sur toutes les branches concernées ;
  • Existence de test(s) unitaire(s) passant ;
  • Si l’IHM est concernée, présence de test(s) Wicket ;
  • Avoir testé la fonctionnalité dans son ensemble sur un cas le plus proche de la réalité possible ;
  • Avoir réfléchi à la pertinence d’enrichir la documentation ;
  • Testé avec IE7.

D’autres éléments ont été évoqué, mais n’ont pas obtenu l’unanimité (raison entre parenthèses) :

  • Fonctionnalité potentiellement livrable (définition floue)
  • Déploiement avec JBoss (perte de temps)
  • Testé avec JBoss (perte de temps)

Voilà l’équipe armée avec SA définition de FAIT (portant sur les User Stories), prête à l’appliquer sur les prochains sprints.

Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir

Dernière réflexion menée par l’équipe en marge de la rétrospective, l’identification d’initiatives que l’équipe peut/doit porter.

En résumé, 3 thèmes ont été abordés :

  • Les tests d’IHM ;
  • La méthodologie et gestion de projet ;
  • Le Scrum Master.

A l’image de la priorisation du backlog technique, chaque membre de l’équipe avait 12 points de valeur à attribuer sur le backlog de 12 tâches identifiées, ce qui a permis de dégager les priorités, à savoir dans l’ordre :

  • Définir clairement la responsabilité des tests Wicket vs. tests Selenium ;
  • Faire un suivi des estimés et tracer le burndown de sprint ;
  • Impliquer toute l’équipe et non le seul Scrum Master ;
  • Estimer les User Stories / Fonctionnalités en points ;
  • Faire une démo en fin de chaque sprint (nice to have : en présence d’utilisateurs) ;
  • Faire une rétrospective tous les 2 sprints ;
  • L’équipe doit réfléchir continuellement aux rôles qu’elle souhaite que le Scrum Master ait, et les expliciter à l’image de la définition du « FAIT » ;
  • Permettre à chacun d’endosser le rôle de Scrum Master à tour de rôle. Sprints de 2 semaines, 2 sprints successifs par Scrum Master ;
  • Découper les User Stories / Fonctionnalités en tâches estimées en heures. Ne pas accepter de tâches de plus de 8h.

Une première définition du rôle du Scrum Master

L’une des décisions à effet quasi immédiat, pour laquelle l’équipe s’est réunie peu après la rétrospective, a été la définition du rôle du Scrum Master.

Cette définition avait plusieurs objectifs :

  • adapter le rôle à l’organisation et aux conditions dans lesquelles évolue l’équipe ;
  • permettre à chaque Scrum Master potentiel d’avoir un référentiel suffisant pour mener à bien sa mission sans nécessiter d’avoir reçu une formation ;
  • diffuser la vision de l’équipe au delà de l’équipe ;
  • pouvoir rétroagir et affiner les composantes du rôle au fil des sprints.

La vision générale de l’équipe est que le Scrum Master (malgré certaines formulation pouvant laisser penser cela) n’est pas un substitut de chef de projet, n’a pas d’autorité sur l’équipe, mais plutôt doit aider l’équipe à s’améliorer.

Différents thèmes ont été formalisés :

  • Au service de l’équipe : moyens, protection, amène l’équipe à s’interroger sur la répartition de la charge ;
  • Respect des pratiques agiles : garant ultime du Daily Scrum, s’assure de l’appropriation de la définition du « FAIT », organise les démos de fin de sprint et s’assure que l’équipe les prépare ;
  • La gestion du Product / Sprint Backlog : proxy Product Owner ou coaching de ce dernier, backlog priorisé, mesure la vélocité et les indicateurs, facilite les séances de planification ;
  • Amélioration continue et ambiance : préparation et facilitation des rétrospectives, célébrations, suivi des garants/porteurs d’améliorations/initiatives.

Bilan et actions entreprises

Les retours sur la rétrospective ont été plutôt positifs, permettant à l’équipe de s’exprimer et d’oser communiquer sur ce qui va mais aussi ce qui ne va pas, de s’engager dans la voie de l’amélioration continue en rendant sa réflexion visible de tous. L’équipe a désormais une identité. Le fait d’avoir une vision commune permet à chacun d’en parler, de s’impliquer, par ce qu’il sait (et c’est indéniable : cela rassure les plus discrets / prudents) qu’il a le soutien de l’ensemble de l’équipe.

Faire une rétrospective est une chose, rendre visible le résultat et les enseignements en est une autre. Pour ce faire, j’ai sacrifié un peu de temps dans la rédaction d’un compte-rendu (qui m’aura mine de rien été très utile dans la rédaction de ce billet) déposé dans le wiki et dont les principaux éléments ont été restitués par l’équipe sur son scrum board pour les communiquer à toute personne curieuse :

  • définition de « FAIT » ;
  • insatisfactions, pistes d’amélioration, avec une colonne « Garant(s) » permettant à quelqu’un de se désigner pour veiller à ce que les choses évoluent dans la bonne direction ;
  • liste des initiatives envisagées, avec une colonne « Garant(s) » permettant à quelqu’un de se désigner comme pilote de l’initiative ;
  • définition du rôle de Scrum Master ;
  • niveau d’adoption des principes agiles ;
  • etc.

Si la colonne « Garant(s) » tarde un peu à se remplir (essentiellement remplie avec le garant « Scrum Master » en cohérence avec la définition du rôle de ce dernier) cela ne veut pas pour autant dire que les actions sont oubliées : la grande visibilité garantit que cela ne tombera pas dans l’oubli et même sans garant les choses peuvent évoluer grâce à l’action collective et la vision partagée par l’équipe.

Cette communication a eu pour effet ces dernières semaines de susciter la curiosité de personnes concernées ou non par le projet sur lequel travaille l’équipe (autres équipes de développement, architectes, responsable technique, chargé d’étude, direction, etc.) que les gens passent et marquent un léger temps d’arrêt ou qu’ils lisent et engagent la conversation avec l’équipe.

Le virus est libéré et se propage naturellement par la méthode douce (devrait-je plutôt parler d’inception en référence au film qui tient l’affiche en ce moment ?). Affaire à suivre.

Laisser un commentaire

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