De nos jours, rares sont les projets logiciels qui se pilotent via la bonne vieille méthode du cycle en V. Ce moyen de gérer un projet, parfaitement adapté dans le domaine du bâtiment et utilisé pendant des dizaines d'années dans le domaine de l'IT, faute de mieux, a désormais laissé la place à des modèles dits "agiles" promettant sur le papier de régler tous les maux et de parvenir à faire enfin mentir la statistique selon laquelle un projet IT n'a que 14 % de chances de réussir (source Standish Group, 2018).

3 mois, mais avec combien de mois de retard ?

Dans le domaine du développement logiciel, on peut jouer sur 4 curseurs au cours de la vie du projet :

• le coût

• les délais

• le périmètre fonctionnel

• la qualité

Les paramètres de coût et de qualité étant intrinsèquement liés : un projet de mauvaise qualité engendrera des bugs, une maintenance douloureuse, et ne délivrera pas l'intégralité de la valeur prévue initialement : tout ceci entraîne des coûts additionnels.

Dès lors qu'un projet commence à déraper, on peut donc influer sur un ou plusieurs de ces curseurs : On peut décider de délivrer un périmètre fonctionnel restreint, on peut retarder la date de livraison, diminuer la qualité (en retirant les tests par exemple) ou augmenter la main d'oeuvre dans la mesure du raisonnable. L'onboarding de nouveaux arrivants sur un projet prend du temps, et chaque équipe de développement a une taille critique qui, une fois atteinte fait que l'inertie engendrée ne fera que ralentir l'avancement du projet : ajouter des développeurs à un projet qui dérive ne permet pas à l'équipe d'améliorer sa capacité à délivrer.

Constats

Afin de gérer au mieux les aléas d'un projet et de redresser la barre au plus vite, on s'est alors penché sur les processus appliqués jusque là : en cycle en V, tout est figé avant même le démarrage d'un projet : on fixe les jalons et les fonctionnalités avant la signature du projet, et on ne remet plus rien en question. Une fois un contrat signé concernant le développement d'un logiciel, le client va donc attendre sagement et passivement la livraison de ce dernier : pour lui, son travail est fait il a clairement et précisément énoncé ses demandes, et à la date inscrite sur le contrat, il pourra jouir de son nouveau joujou couvrant parfaitement l'intégralité de ses besoins.

Evidemment, dans la réalité, une telle vision est irréaliste pour plusieurs raisons :

• Il est impossible d'anticiper tous les aléas qui surviendront lors de la vie d'un projet : maladie ou congé parental de membres de l'équipe, pandémie entraînant la mise en pause de l'économie (exemple issu de l'imagination débordante de l'auteur)

• Entre le moment où le projet démarre et sa livraison, il peut s'écouler plusieurs mois, voire plusieurs années selon l'envergure du projet : pendant ce laps de temps, le besoin du client peut évoluer, de nouveaux outils peuvent arriver etc...

A chacun son métier : concevoir un logiciel est une tâche complexe, et un client dont le domaine d'expertise n'est pas l'IT aura donc toutes les peines du monde à anticiper l'ensemble de ses besoins, dès le départ, son projet de logiciel a donc toutes les chances d'être grandement incomplet. Les équipes IT et le client doivent travailler de concert pour concilier besoins métier et contraintes techniques et légales.

L'entrée en jeu de l'agilité

Tout ceci est décrit dans le Manifeste Agile, paru dès le début du siècle. Celui-ci décrit 12 principes fondamentaux, parmi lesquels les plus importants sont :

• Piloter par la valeur ajoutée

• Délivrer fréquemment

• S'améliorer sans cesse

• Accepter les changements en cours de route

Finalement, un peu de bon sens permet de se rendre compte du bien fondé de ces principes. Mieux vaut livrer au client de façon régulière de manière à pouvoir tester directement les hypothèses de développement. Un MVP (Minimum Viable Product) fonctionnel est bien plus facile à juger qu'un document de spécifications de 150 pages, d'autant plus lorsqu'on n'est pas expert dans l'IT, comme une majorité des clients de logiciels. Au lieu de s'enfermer dans un tunnel de développement sans fin (enfin, si, la fin est écrite à la page 7 du contrat d'édition du logiciel, évidemment !), au cours duquel tout peut arriver, il est bien plus sage d'impliquer le client dans le process de développement de son logiciel en lui faisant tester régulièrement, et en lui donnant la capacité d'en modifier le périmètre fonctionnel suite à ses essais.

Mais alors, pourquoi ça dérive encore ?

Fort de ces principes d'agilité, plusieurs méthodes de développement ont vu le jour : Extreme Programming, Kanban, et la plus répandue : Scrum, qui tire son nom et beaucoup de ses concepts de l'univers de l'ovalie (Scrum = Mêlée chez nos amis anglophones), Scrum décrit des pratiques de développement, des cérémonies régulières et des rôles au sein de l'équipe. Ainsi, on remplace le long tunnel de développement par des Sprints plus courts, de 2 à 3 semaines en général rythmés comme suit :

• Une réunion de kick-off du sprint, appelée le Sprint Planning au cours de laquelle la Scrum Team se réunit pour définir le contenu du sprint à venir

• Des meetings quotidiens (les Daily Meetings) au cours desquels chaque membre de l'équipe répond à 3 questions : Qu'ai-je fait hier ? Que vais-je faire aujourd'hui ? Ai-je rencontré des problèmes ?

• Une revue de Sprint, au cours de laquelle on réalise une démonstration du travail effectué au cours du sprint, auprès des stakeholders (ou sponsors : ceux qui attendent un gain via le produit)

• Une rétrospective, permettant de se remettre en question et d'analyser ce qui s'est bien passé lors du sprint, et ce qui mérite un changement

Ainsi, sur le papier du moins, on coche pas mal de cases du manifeste agile : on livre souvent, le client est au courant de l'avancée du projet et peut émettre des suggestions ou proposer des changements, on se challenge dans le but de s'améliorer.

Et pourtant, nombreux sont les projets pour lesquels Scrum est un remède pire que le mal. Plusieurs dérives classiques :

• Scrum n'impose pas le concept d'estimations : en théorie, on ne perd pas de temps à jouer les oracles et à deviner à priori le temps qui va être nécessaire pour réaliser une fonctionnalité.

  Et pourtant, dans bien des cas, le Sprint Planning se transforme en séance de chiffrage en séance, afin de faire rentrer au chausse-pied un certain nombre de Story Points (ou points de complexité) qu'une équipe serait théoriquement capable de délivrer au cours d'un sprint.

  En réalisant ces tâches, on perd du temps, et on crée une métrique peu utile au déroulé du projet, hormis pour le Chef de projet (qu'on appelle désormais Scrum Master, même si son rôle n'a pas bougé) qui doit remplir des fichiers Excel pour rendre des comptes à sa hiérarchie. L'effet est même pervers dans le sens où les calculs de vélocité d'une équipe (le nombre de Story Points qu'elle est capable de livrer en un Sprint) servent d'indicateur de performances des membres de l'équipe lors de leurs entretiens d'évaluation et peuvent créer des comportements indésirables où les développeurs les plus chevronnés vont se cantonner à des petites tâches, pour lesquelles le risque de déraper est faible afin d'être sûr de tenir leurs engagements alors qu'ils seraient plus utiles sur des tâches complexes, au vu de leur expérience.

• A combien tu estimes cette fonctionnalité ?

• Euh, 42 ça rentre dans l'échelle de Fibonacci ?

• La disparition du jalon final défini dans le contrat se transforme en réalité en création d'une multitude de petits jalons : à chaque sprint, on doit absolument avoir terminé le contenu du sprint, ce qui crée une pression supplémentaire toutes les deux semaines et ne permet jamais à l'équipe de relâcher la pression, quand sur une durée plus longue, les phases où on avance vite, et les phases où on bute sur plus de problèmes s'équilibrent sur la durée. En Scrum, un sprint qui se passe mal va générer une pression forte pour délivrer quand même les engagements, mais un sprint qui se passe comme prévu va inciter les équipes à délivrer plus de points pour avoir des indicateurs de performance vert clignotant ! Ainsi, l'équipe ne peut jamais souffler et finit par s'épuiser à la tâche, menant à de la démotivation, des démissions ou des burn-out.

• La pression du client pour embarquer des fonctionnalités pas encore "sèches" car importantes, qui vont générer des incompréhensions au moment du développement, ou des situations où les US (User Stories) sont embarquées, mais bloquées à cause de l'absence de pré-requis. On définit en général une DoR, ou Definition of Ready, c'est-à-dire un ensemble de données nécessaires pour que l'équipe de développement puisse entamer sereinement une fonctionnalité : par exemple, des maquettes graphiques, des jeux de données, la fourniture de clés d'API ou des livraisons de SDK à intégrer, des spécifications fonctionnelles claires etc... Si cette DoR n'est pas atteinte, on ne doit pas engager les développements.

Agilité = Post-It, c'est bien connu, il suffit d'un carré de papier auto-collant avec 3 mots écrits dessus pour entamer le développement d'une fonctionnalité !

• Les rétrospectives, dont le noble but est de permettre une remise en question permanente, sont souvent victimes de deux anti-patterns classiques : la présence du top-management empêche les prises de parole libérées, et font qu'en général, personne n'ose parler, et rien de concret ne ressort de cette cérémonie. Seconde dérive possible : lorsque l'équipe se complait dans le statu-quo : si personne n'est prêt à effectuer de réels changements, alors on décide souvent de micro-changements insignifiants, qui n'ont aucun impact sur l'organisation du projet, et on peut ainsi rester à se plaindre (on est Français après tout !), le tout sans jamais faire évoluer quoi que ce soit

Un modèle aussi performant, si on le scalait ?

Scrum, XP, Kanban et leurs équivalents sont des méthodes qui s'appliquent sur des équipes d'une taille relativement limitée : au delà d'une dizaine de personnes, les daily-meeting sont trop longs, les rétrospectives n'aboutissent à rien, et le Scrum Master est surchargé : Scrum recommande de 6 à 9 personnes maximum.

Plusieurs initiatives ont vu le jour, comme Scrum of Scrums, ou la plus répandue : SAFe (Scaled Agile Framework).

L'idée de SAFe est de proposer une méthode dite "agile coordonnée" afin d'étendre le fonctionnement Agile au sein d'une organisation entière. Un formalisme est donc défini, avec un découpage en trains, qui représentent de univers fonctionnels, et des sous-équipes : les Feature-Teams ou Feature-Aligned Teams selon la version du Framework, chacune en charge d'une partie fonctionnelle du projet, ou bien en Component Team ou Complicated Subsystem Team pour les équipes en charge de projets transverses.

Chaque train dispose également de son équipe de System Architects, garants de la qualité technique des livrables, ainsi que d'un RTE, Release Train Engineer, sorte de Scrum Master transverse à l'ensemble des équipes du train, dont le rôle est d'être un facilitateur, d'aider à la synchronisation entre les équipes et de régler les conflits.

SAFe découpe une année calendaire en 4 Program Increments (PI), d'une durée de 3 mois, qui sont eux-mêmes découpés en 6 itérations : les 5 premières fonctionnent comme des sprints classiques, organisés en Scrum, Kanban, XP ou autre selon la préférence de l'équipe, et la dernière itération, nommée Innovation & Planning comprend la cérémonie du PI-Planning, 2 à 3 jours pendant lesquels on prévoit l'incrément à venir, et le reste est consacré à une phase de "respiration", pendant laquelle les équipes travaillent sur des sujets qui n'ont pas forcément de valeur business immédiate : veille technique, réflexions sur l'organisation, mitigation de dette technique...

Ce PI Planning s'organise en plusieurs phases :

• Une réunion d'introduction : la plénière, pendant laquelle les stakeholders présentent la vision globale du train et redescendent de l'info auprès de toutes les équipes sur les différents KPI, les actions moyen/long terme à venir etc...

• Les Team Breakouts : réunions lors desquelles toutes les équipes se rencontrent pour partager les besoins qu'ils auront lors du PI à venir afin de traiter les features de leurs backlogs : par exemple, une feature front peut nécessiter un développement côté back avant de pouvoir être entamée : ceci crée donc une dépendance qui doit être prise en compte lors de la planification de toutes les tâches.

• Le partage des risques auprès des stakeholders. Cette réunion permet aux équipes terrain de remonter de l'info auprès du management qui peut alors prendre les actions nécessaires pour limiter ces risques : main d'oeuvre supplémentaire, décalage planning, re-priorisation etc...

• La revue du plan "Draft" : il s'agit d'un premier partage du plan des 3 mois à venir, en tenant compte des différentes dépendances identifiées lors des Team Breakouts. En cas de conflit entre deux équipes, les stakeholders peuvent alors trancher en fonction de la business-value associée à chaque sujet. On utilise l'outil WSJF (Weighted Shortest Job First) : une moyenne pondérée de business-value par rapport à l'investissement nécessaire qui permet de faire remonter des sujets "quick-win", rapides à mettre en place, qui pourraient être écrasés face à des sujets à plus grosse business-value, mais qui nécessitent un investissement plus important.

• La définition des objectifs : les différentes équipes présentent leurs objectifs pour l'incrément à venir, en accord avec les stakeholders : ces objectifs sont pris par l'équipe et permettent de responsabiliser l'équipe qui est alors maître de son engagement de delivery.

• Une rétrospective globale au train, avec en actions conrètes la création de groupes de travail pour améliorer les process identifiés comme perfectibles, dans un esprit d'amélioration continue.

• Le partage du plan définitif, souvent très proche du plan "draft", et un vote de confiance par les équipes. Si ce vote de confiance est trop faible (car trop de risques non traités, trop de dépendances non maitrisées, des objectifs trop ambitieux...), alors le framework SAFe prévoit que l'ensemble du PI Planning est à recommencer.

  

Un sublime exemple de Program Board, avec des dépendances bien identifiées. Porte également le nom de plat de spaghetti !

En sortie de ce PI Planning, toutes les équipes repartent alors avec un plan défini pour les 5 sprints à venir, des dates de livraison théoriques pour les différentes dépendances, et surtout une vision claire et consolidée de l'ensemble des sujets du train : chacun sait pourquoi il travaille, et dans quel but il construit son produit.

SAFe est un framework plutôt bien pensé, et en constante évolution : on dénombre 6 versions majeures depuis sa création en 2011, cependant, comme sur les méthodologies de travail agiles évoquées précédemment, les dérives sont nombreuses, parmi lesquelles :

• Penser qu'il s'agit d'un framework à la carte :

  Implémenter le framework en ne prenant que ce qui nous arrange : la phase de respiration ne délivre pas de valeur business ? Retirons la et transformons l'itération d'Innovation & Planning en une itération classique !

  Le RTE ne produit pas de valeur business immédiate ? On peut donc s'en passer !

• La cérémonie du PI Planning doit être le moyen de synchroniser toutes les équipes du train. Sa préparation en amont et lors de l'événement doit être sans faille : les sujets doivent être cadrés et priorisés en amont, les dépendances identifiées pour que l'exercice soit efficace : sans cela, le plan décidé lors du PI Planning est alors impossible à tenir, et l'exercice est vu comme une perte de temps.

• Ne pas suivre les équipes au jour le jour, et attendre le PI Planning tous les 3 mois pour recueillir des feedbacks terrain : les stakeholders et le management doivent receuillir régulièrement du feedback terrain, et participer activement aux décisions.

Evidemment, toutes ces dérives contribuent à créer un climat de méfiance entre les différentes équipes : la collaboration est mise à mal, et au lieu de travailler ensemble pour délivrer des objectifs communs, chaque équipe utilise les dépendances avec les autres équipes pour justifier un delivery faible.

Donc on abandonne tout et on revient 20 ans en arrière ?

Scrum et l’agilité en général ne sont pas à jeter pour autant. Le parti-pris initial est toujours d'actualité, cependant, il ne faut pas oublier un point crucial : toutes les équipes sont différentes, et il n'existe pas de recette magique universelle !

Scrum n'a pas été créé comme étant une méthode immuable, et chaque équipe doit se l'approprier pour la faire évoluer à sa manière. Le concept d'Agile doit lui-même être appliqué à la création des process de gestion d'un projet et pas seulement au développement du logiciel : on doit sans-cesse revoir nos process, les challenger, les améliorer, et ne jamais se satisfaire d'une situation imparfaite. On ne peut appliquer une méthode de travail agile comme on appliquerait une recette de cuisine : on doit itérer et l'adapter à notre équipe pour en tirer le meilleur, ne garder que ce qui fonctionne et changer tout ce qui peut donner lieu à une amélioration, cependant, une chose est sûre, un projet qui dérape régulièrement et dans lequel les rétrospectives ne remontent aucun axe de changement est un projet voué à l'échec.

L'agile nécessite également une implication forte du management (directeurs de production, commerciaux etc...), et du client qui doivent tous être convaincus du bien-fondé d'un modèle itératif. Passer en agile implique de se passer du filet de sécurité (bien qu'illusoire) qu'est le contrat dans lequel tout est défini à l'avance, et toute dérive donnera lieu à des pénalités financières : s’agiliser implique de mettre l’intérêt du produit avant la négociation contractuelle. Une équipe sceptique sur les bienfaits de l'agilité saura facilement mettre en place des anti-patterns afin de saboter la méthode, et de pouvoir dire "Je vous l'avais bien dit que ça ne marcherait pas !".

Les égos et les reflexes de l'ancien monde sont également dangereux : on ne passe pas de chef de projet (qui est un métier à part entière) à Scrum Master en un claquement de doigts. Scrum Master est un rôle, pas un métier : un développeur peut endosser ce rôle, et il n'y a pas de notion hiérarchique entre le Scrum Master et le reste de la Scrum Team. Imposer un chef de projet comme Scrum Master sans le former au préalable et lui demander de changer sa façon de travailler est donc un excellent moyen de faire échouer un projet !

Attention à bien déceler les signes, à l'instar des code-smells dans du code applicatif : il n'existe pas de SonarQube pour le fonctionnement d'une équipe de développement, chaque membre doit être vigilant à tout instant et ne doit jamais hésiter à remonter tout dysfonctionnement !

Finalement, le plus important est de comprendre que l'agilité dans le développement logiciel est finalement plus une question de bon sens, et de capitalisation de bonnes pratiques collectées au cours de nombreux projets qu'une marche à suivre immuable. Dès lors, lorsqu'un problème surgit, il est promordial de continuer à faire preuve de bon sens et de pragmatisme, en se rappelant les principes du manifeste Agile :

• Des Hommes qui travaillent de concert sont plus importants que des process et outils

• Une collaboration active avec le client

• L'adaptation au changement