La découverte de l’agilité avec Scrum

Dans les années 2010 l’agilité se démocratisait, et tout le monde en avait a minima entendu parler. C’est en 2012 au sein du pôle Web de La Mutuelle Générale que j’ai pratiqué l’approche pour la première fois.

Nous avions reçu la commande de refondre l’espace adhérent. L’existant n’était qu’un simple portail qui permettait de consulter les relevés santé. Le projet était ambitieux étant donné que nous devions créer tout un domaine applicatif. Il n’était pas question de mettre en place juste un portail mais également toute une couche de services. Ceci dans le but de proposer un ensemble de services à nos adhérents (terme utilisé dans la Mutualité pour désigner un client).

C’était un challenge pour nous car avant cela nous faisions uniquement de simples formulaires web avec base de données pour aider le métier dans son quotidien. Notamment la saisie des temps, des cures thermales, la gestion des prospects. Raison pour laquelle nous avons donc décidé d’être accompagnés par un cabinet de consulting, qui a par ailleurs proposé l’utilisation de Scrum comme méthodologie.

Les rituels agiles

La gestion itérative (sprints) est la notion la plus en décalage avec le cycle en V. Fini la pression de devoir tout définir en amont. Etant donné que l’agilité prône un logiciel rapidement utilisable, on ne se focalise que sur un périmètre très restreint. Ce qui par conséquent allège grandement la conception puisque les interactions techniques sont faibles.

La conception initiale était très importante à mes yeux. Pour qu’un projet ne rencontre pas de difficultés lors de son implémentation, il fallait que tout ait été éclairci en amont. Dans la démarche agile au contraire on ne se préoccupe que d’un périmètre restreint. Ce qui impliquait plus tard de devoir revoir l’architecture. C’est pourquoi cela m’a dérouté dans un premier temps.

L’autre rituel phare dans la méthodogie scrum, le daily a également retenu mon attention. Il parait intrusif au premier abord puisqu’on décrit l’avancement au jour le jour. Pourtant si on le voit sous un autre angle il est très utile pour la vision de chacun. D’une part pour les développeurs en cas de difficulté ou incompréhension du besoin. D’autre part pour les autres parties prenantes dans le suivi de la progression.

J’ai beaucoup apprécié les sprint review. Tout particulièrement les démos des développements réalisés durant le sprint écoulé. Avec le recul, je trouve la démarche beaucoup plus efficace que des pourcentages d’avancement qui ne représentent en rien la valeur produite.

Nous n’avons en revanche pas troqué la documentation classique pour des Users Stories. De ce fait nous avions des extraits des spécifications fonctionnelles dans nos user stories.

L’utilisation isolée de l’agilité

Après cette expérience nous avons commencé à travailler en utilisant les méthodes agiles au sein du pôle Web. Cela restait principalement cantonné aux projets WEB uniquement car nous étions les seuls à la pratiquer.
Parfois au cours des projets impliquant diverses équipes nous arrivions à réaliser les développements de manière itérative. Nous menions les projets en waterfall et de ce fait, le cadrage ainsi que les tests métier se déroulaient de manière classique.

SCRUM BOARD

Le premier élément du passage à l’agilité dans une équipe est la mise en place du tableau en papier collé au mur (le fameux scrum board) dans lequel nous avions l’ensemble des tâches collées sous forme de post-it.

Il n’a d’ailleurs cessé d’évoluer. Nous modifions régulièrement les états (todo, in progress, done…) ainsi que le groupement par projet ou priorité. Il est rare de trouver la bonne formule du premier coup. C’est d’ailleurs ce qui est intéressant dans l’approche, chaque équipe adapte le scrum board à son besoin.

Ainsi à nos débuts nous avions adopté des lignes verticales pour les états (à faire, spécifications, développement, tests, fait). Et des lignes horizontales par projet. Plus tard nous avions ajouté une ligne d’urgence (comme une sorte de bande d’arrêt d’urgence d’autoroute) et un « bac rouge » pour les incidents.

Des scrum board trop complexes (> 7 statuts) et avec des lignes saturées (tâches bloquées à l’étape « à tester » ou « à livrer » par exemple) sont généralement la preuve d’un problème d’organisation.

DAILY

Le daily accompagne naturellement le scrum board car l’un n’a pas de sens sans l’autre.
Premier obstacle, convaincre toute l’équipe que le daily n’est pas un lieu de flicage mais un point d’échange sur la progression et essentiellement pour lever les difficultés.

Ensuite le temps de parole, il faut rester concis pour tenir le quart d’heure afin d’éviter de monopoliser l’équipe trop longtemps chaque jour. Plus les participants sont nombreux et plus la tâches est évidemment ardue. La règle est de tenir 1min par participant au delà duquel il est sommé de prévoir un atelier dédié à la résolution du problème.

Notre secret était l’utilisation de la boite à meuh (ou un son équivalent) pour sonner la fin de la minute ce qui donnait de bons résultats !

RETROSPECTIVE ET REVIEW

Les reviews, ou démos, n’étaient que très rarement pratiquées par manque d’implication ou connaissance de la démarche par le reste des parties prenantes.

Les rétrospectives ont été rapidement adoptées car elles donnent à l’équipe un cadre dans la remontée de difficultés et la résolution de celles-ci, ainsi que les actions correctrices à mettre en place pour améliorer les process lors du prochain sprint. Cela n’existait pas dans la méthodologie appliquée jusque-là, même si la gestion par les risques pourrait s’en approcher. La différence notable vient de la recherche d’amélioration au lieu du suivi d’un plan. En effet, une fois le cadre posé (process, gouvernance), il n’est pas aisé de les modifier. Une des raisons qui justifie une des valeurs agile: « réactivité au changement plus que suivi d’un plan »!

Par expérience, j’ai remarqué que l’absence de review mettait en exergue un problème d’implication de l’équipe. Soit parce que l’équipe de développement ne souhaitait pas communiquer son avancement, soit parce que le product owner et les autres parties n’étaient pas impliqués dans la méthodologie agile.

L’agilité promue en entreprise

En 2016, le management a pris conscience de la valeur des nouvelles méthodes agiles. Il a donc fait le choix d’être accompagné pour mettre en place l’agilité au sein de l’entreprise.
C’est ainsi que des coachs agiles sont venus expliquer les méthodes agiles aux différentes équipes et les accompagner dans le démarrage des nouveaux projets. Ils ont également formé une petite équipe de futurs coachs internes qui prendraient leur relai un an plus tard.

Difficultés

Globalement l’IT a plutôt bien accepté les changements mais n’était pas prête pour autant à faire fi du passé. C’est surtout les équipes du back qui ont eu le plus de difficultés à s’adapter et pour plusieurs raisons.
Premièrement, l’équipe en charge du progiciel de gestion santé, active infinite, était au centre de plusieurs projets qui nécessitaient une vision long terme.
Elle était également fortement impactée par des évolutions réglementaires, ce qui nécessitait également une vision très rigoureuse des roadmaps.
Enfin, le refactoring des traitements batchs lourds n’est pas toujours compatible avec la logique agile.

Automatisation

Je ne pense pas que ce soit incompatible mais pour que les équipes travaillant sur des process lourds basculent sur l’agile il faut des prérequis.
Cela passe avant tout par l’automatisation. On ne peut tenir des sprints de faible durée si les déploiements se font manuellement. En effet, les délais de prise en compte de la demande et du traitement peuvent prendre 2 à 3 jours ouvrés ce qui n’est pas acceptable sur une itération de 2 semaines (10 jours ouvrés). A ceci vous ajoutez les tests et vous n’avez qu’une faible charge accordée aux développements…
Automatisation des environnements et des configurations également: lorsque plusieurs équipes travaillent sur le même environnement, il est difficile d’être efficace car on dépense des efforts à coordonner l’état des environnements.

Multiplication des meetings

Une des grandes problématiques que j’ai rencontrée au sein de La Mutuelle Générale et que je rencontre encore aujourd’hui, est celle de la multiplication des réunions. Avec l’arrivée de l’agilité, les meetings se sont soudainement démultipliés ! Réunions classiques de suivi de projet en plus des rituels agiles. C’est une situation absurde qui met le doigt sur le manque de maturité dans l’adoption de l’agilité.
Cela conduit l’entreprise vers un rythme à 2 vitesses. Les équipes IT impliquées dans les rituels agiles et les parties prenantes restant avec leurs comités classiques : project committee, steering committee…

Face à ce constat, j’y vois plusieurs problématiques.
D’une part, les réunions « doublons » grèvent la productivité.
Ensuite la tenue de réunions type « suivi planning et budgets » démontre un manque d’implication et collaboration de l’ensemble des participants.
Enfin l’incohérence du top management dans le choix de l’agilité tout en conservant un pilotage par les délais et budget fixes.

On allait donc à l’encontre de 2 valeurs fondamentales: « Individus et échanges plus que processus et outils » et « Collaboration du client plus que négociation du contrat »

Documentation

La documentation est un sujet délicat dans la mise en place de l’agilité. On pense souvent à tort qu’il n’y a pas de documentation dans les méthodes agiles. Cela vient d’une mauvaise interprétation d’une des 4 valeurs du manifeste agile : « Des logiciels opérationnels plus qu’une documentation exhaustive ».

Les termes « plus que » ne sont pas équivalents à « non » ou « pas du tout »! La documentation doit simplement être réduite au strict nécessaire. Cette logique « de frugalité » (principe KISS) se retrouve dans d’autres aspects de l’agilité et va dans le sens de l’optimisation. Il faut évidemment documenter mais éviter une documentation lourde qui au final ne sera ni lue, ni maintenue. Quoi de pire qu’une documentation lourde et obsolète…

De plus les User Stories font office de documentation, on retrouve ainsi notre chère documentation. D’ailleurs, la User Story est au centre de la méthodologie Scrum et sans elle il n’y aurait pas de backlog ni de fonctionnalités à implémenter. Preuve qu’il y aura dans tout projet une documentation de ce qui a été réalisé.

En revanche on peut lui adresser 3 reproches.
Le premier étant de se retrouver avec documentation désordonnée car dispersée au travers des différentes users stories.
Le second touche la qualité. A cela je m’inscrits en faux, car la rédaction des users stories répond à des critères quantifiables : Definition of Ready (Dor) et Definition of Done (DoD) qui assurent leur qualité.
Le dernier concernant la documentation d’architecture ou conception globale. Les users stories se focalisant sur chaque fonctionnalité indépendamment les unes des autres sans cohérence globale.
C’est une limite de la méthodologie Scrum car elle ne couvre pas toutes les étapes du projet, en particulier cette phase d’initialisation ou cadrage.

Chiffrage

Enfin un dernier point concernant l’application de l’agilité en entreprise et pas des moindres : le chiffrage. Ce point rejoint d’une certaine manière le maintien des points de suivi classique.

En agilité on ne chiffre pas en jours/homme. On ne peut que constater le budget dépensé et il est difficile / impossible de se projeter. D’ailleurs la vélocité des équipes évolue durant la vie du projet. On ne peut donc pas convertir un effort en jours/homme.

On ne chiffre donc pas en temps mais en complexité (tâche simple, moyenne ou grande). D’ailleurs, fait amusant, auparavant afin d’estimer une tâche en jours/homme on définissait d’abord la taille de la tâche pour ensuite lui appliquer un abaque. En agilité on se simplifie la vie en définissant simplement la taille de chaque tâche.

La différence étant qu’au lieu de traiter en 2 semaines, 10j/h de tâches par développeur, on détermine la capacité globale de l’équipe à traiter un nombre de tâches. Ainsi chaque équipe aura sa propre capacité moyenne. Capacité moyenne car une équipe est composée de développeurs de différentes séniorité, qui ne traiterons donc pas leurs tâches au même rythme !

Ne pas avoir un suivi en j/h va à l’encontre du suivi de la roadmap/budget au niveau du management. D’où les difficultés à travailler en agile dans une entreprise qui ne l’est pas dans son ensemble. Rappelons au passage que Scrum n’est pas adapté à l’échelle d’une large organisation. Il faudra se tourner vers des frameworks d’agilité à l’échelle pour coordonner l’ensemble des équipes en mode agile.

Gestion de la maintenance (run) avec un backlog

Avant mon arrivée au poste de responsable des applications web, mes prédécesseurs géraient les incidents et les demandes d’évolutions au cas par cas. C’était fastidieux car il fallait tenir un suivi de chaque évolution. De plus les demandeurs avaient l’impression que leurs sujets n’avançaient pas ou étaient mal priorisées.

J’ai alors décidé de gérer toutes les demandes et incidents mineurs avec la méthodologie Scrum. Premier avantage, la gestion du backlog. Celle-ci a supplanté la tenue d’un fichier excel qui n’était utilisée que par l’IT. De plus les outils associés (trello, azure devops, jira…) ont permis de collaborer beaucoup plus aisément avec le métier. Plus besoin de passer par des emails, les demandeurs saisissaient leurs besoins directement sous forme d’US.

Deuxième point, la visibilité de la progression. Les intéressés pouvaient visualiser l’état de chaque demande dans les outils de collaboration. Plus besoin d’échange par email inutile.

Enfin dernier point les cycles itératifs courts. Le métier a rapidement compris le fonctionnement des cycles itératifs et comprenait qu’un cycle entamé devait se terminer avant la prise en compte des nouvelles demandes. Les cycles étant courts, l’attente était acceptable. De plus cela permettait à tous les demandeurs de s’y retrouver et éviter qu’on oublie les demandes peu prioritaires.

Défis de l’agile avec équipes externes

L’agilité par nature prône le rapprochement. Dans l’idéal, les équipes réalisent leurs daily meetings de visu et de vive voix. Les scrum boards sont scotchés à un mur et visibles en permanence par l’équipe.

Première difficulté: tenir ces différents rituels à distance. Il y a quelques années, on utilisait encore peu la visio et on échangeait de fait uniquement par téléphone/mail. Avec les nouveaux outils de communication et la suppression de la téléphonie classique fixe, le problème disparait.

Autre point, les objectifs contraires des équipes internes et externes. Avec des contrats rigides gérés par des indicateurs stricts (nombre de tickets traités par mois etc), une TMA se retrouve rapidement à gérer du « chiffre ». Elle va essayer de maximiser les indicateurs au détriment de la valeur du produit.

C’est d’ailleurs la raison pour laquelle le manifeste agile insiste bien sur la valeur fondamentale : la collaboration avec les clients plutôt qu’à la négociation contractuelle ;

Afin d’éviter ces effets on a eu recours aux contrats agiles, on se focalise sur une mise à disposition de moyens avec plus de souplesse sur l’engagement de résultats.

Mais ils ont leurs limites et ne sont pas une solution miracle pour gagner en qualité. Pour obtenir de la réactivité en cas d’incident ou la résorption de dette technique, il faut investir, sans quoi on devra toujours prioriser ou trouver des contournements.

Conclusion

Les méthodes agiles sont désormais la norme, et leur efficacité est avérée et reconnue quasiment de tous.
Désormais, les nouvelles recrues n’ont connu que l’agilité et elles collent avec leur mentalité. Il est utile à mon sens de connaitre les méthodes classiques car elles ont des avantages. Et sont dans certains cas plus adaptés qu’une méthode agile.

Mes expériences m’ont permis de voir les difficultés rencontrées et comment la méthodologie Scrum a apporté des solutions. Ce ne sont que des pratiques pragmatiques mais qui sont standardisées et connues de tous. Faire un daily, gérer les demandes dans un backlog, les prioriser ne sont pas une révolution.

Le grand bouleversement provient de la mise à jour perpétuelle du produit. On ne construit pas une application comme une maison qui devra tenir toute une vie. En informatique la logique veut qu’on avance étape par étape en explorant et se focalisant sur les fonctionnalités les plus demandées et apportant plus de valeur aux utilisateurs et aux clients.

L’agilité promeut également le rapprochement et l’implication de tous, internes comme externes. Les faits ont prouvé que toutes les méthodes ou démarches ne peuvent à elles seules créer la qualité. C’est la qualité des individus et leur collaboration qui amène la qualité. La rigidité des anciens process bride les actions tactiques qui solutionnent les difficultés. Il est impossible qu’un process soit parfait et prenne en compte toutes les possibilités. C’est en cela que les valeurs agile font écho à notre environnement actuel et ont fait leurs preuves:

• Individus et leurs interactions plutôt que processus et aux outils ;
• Logiciel fonctionnel plutôt qu’une documentation exhaustive ;
• Collaboration avec les clients plutôt que négociation contractuelle ;
• Adaptation au changement plutôt que l’exécution d’un plan.

Article précédent

Article suivant