On parle toujours de Scrum dans les méthodes agiles, mais il existe de nombreux autres frameworks !
Celui que j’ai récemment pratiqué est “Shape Up !”. Il s’agit d’une méthode utilisée dans l’entreprise BaseCamp qui s’appuie sur son logiciel éponyme “BaseCamp”. Si vous souhaitez lire leur bible, ça se trouve ici.
Les piliers de “Shape Up !”
“Shape Up !” se base sur quelques hypothèses qui guident l’ensemble de la méthode :
- Des durées d’itération allongées à 6 semaines. Les méthodes agiles sont souvent appliquées avec des durées d’itérations de 2 semaines, mais il est rare qu’on arrive à réaliser une fonctionnalité de bout en bout dans ce laps de temps (conception, design, implémentation, test).
- La définition de notre appétit pour chaque fonctionnalité. Même en allongeant la durée des itérations, on n’a jamais le temps d’implémenter la feature parfaite. Il faut donc prendre le problème à l’envers, et définir notre “appétit” pour chaque fonctionnalité, c’est à dire le temps que l’on souhaite investir dessus. On adapte ensuite le périmètre à implémenter en fonction du temps alloué.
- L’assignation d’un projet complet aux développeurs. Nous sommes habitués à avoir un backlog constitué d’innombrables petites tâches. Maintenir ce backlog est extrêmement coûteux et pénible, et on pourrait même parler de masochisme lorsqu’il s’agit de fouiller dans votre historique JIRA… Par ailleurs, en assignant chaque petite tâche d’un même projet à différents développeurs, aucun d’eux ne se sent réellement responsable de la qualité globale du projet. Il faut donc autant que possible assigner un projet complet à un seul développeur pour augmenter son sentiment de responsabilité.
- La dette technique n’est jamais priorisée suffisamment régulièrement, et elle s’accumule inéluctablement : une période de cooldown de 2 semaines est définie à chaque itération pour permettre aux développeurs de la traiter le plus régulièrement possible
“Shape Up !” définit aussi 4 grandes étapes qui cadreront la conception, depuis la phase d’idéation jusqu’à la mise en production :
- shaping : définition des grandes lignes, de la faisabilité technique, et de notre “appétit” pour plusieurs projets à implémenter.
- betting : choix parmi tous les projets complètement “shapés” de ceux à implémenter dans la prochaine itération.
- building : l’implémentation des projets sélectionnés pendant le betting
- cooldown : la phase de relâchement où le développeur peut travailler sur “ce qu’il veut” en lien avec l’entreprise.
Suite aux différents éléments ci-dessus, nous arrivons à une durée complète d’itération de 8 semaines :
- 6 semaines qui contiennent les étapes de shaping pour le Produit, et de building pour les developpeurs
- 2 semaines qui contiennent le betting pour le Produit, et le cooldown pour les développeurs.
A noter que l’on retrouve la dualité qui peut exister dans le métier de Product Manager avec d’une part l’étape de discovery (étude et définition du besoin client, puis priorisation), et d’autre part l’étape de delivery (implémentation de la solution).
Mais pour mieux comprendre les différences avec Scrum, détaillons un peu plus chaque étape.
L’étape de Shaping, ou façonnage
“Shaper” une feature, c’est en faire une esquisse, une ébauche : ce n’est pas aussi précis qu’un design fait par un designer, mais ce n’est pas que du texte non plus (qui est souvent incomplet et fastidieux à lire).
Le principal intérêt du croquis est qu’il permet d’un coup d’oeil de comprendre l’idée globale de la fonctionnalité, tout en laissant de la place pour la créativité du designer. On ne se perd pas dans des détails de wording ou dans des choix esthétique. Pour autant, cela donne quand même suffisamment d’informations aux développeurs pour qu’ils imaginent leur architecture logiciel.
Pour avoir un projet complètement “shapé”, il doit avoir suivi les 4 étapes suivantes :
- Définition des limites et de l’appétit : on définit les limites du problème suite à l’analyse du besoin, puis on définit notre “appétit” pour à cette fonctionnalité. Plus la fonctionnalité est importante pour le business, plus notre appétit sera grand, et plus nous y investirons du temps (cette durée peut même aller jusqu’à couvrir le cycle entier, soit 6 semaines)
- Description schématique des éléments : réalisation d’un croquis répondant au problème tout en restant dans les limites définies précédemment
- Evaluation des risques : on regarde un peu plus en profondeur notre solution pour détecter tous les risques (cas aux limites, etc…).
- Ecriture du pitch : on regroupe tous les éléments ci-dessus dans un pitch (spécification + schéma) qui permettra de le prioriser et de l’implémenter.
L’étape de Betting, ou pari
L’étape de betting consiste à prioriser parmi les projets complètement “shapés” ceux à inclure dans la prochaine itération. Il est de la responsabilité de l’équipe produit de présenter des projets complets et à jour. Une fois les projets sélectionnés, tous ceux rejetés sont censés être supprimés, notamment pour ne pas alimenter ce fameux backlog avec des projets obsolètes. A noter que “Shape Up !” donne des méthodes pour sélectionner les pitchs du prochain cycle, mais je ne les détaillerai pas dans cet article.
L’étape de Building, ou construction
Maintenant que nos pitchs ont été sélectionnés, il s’agit de les implémenter. Ici, à la grande différence de Scrum, chaque projet a une équipe qui lui est assignée. Cette équipe doit être avoir toutes les compétences pour mener ce projet à son terme, et elle ne contient souvent qu’un seul acteur par domaine (par exemple 1 développeur frontend, 1 développeur backend, 1 designer). Il est de la responsabilité de cette équipe de mener à bien ce projet. Cela comprend la finalisation du design, les choix d’architecture logiciel, l’implémentation, les tests fonctionnels et automatisés, etc… L’intérêt d’assigner un projet complet à des personnes, c’est qu’elles sont davantage responsabilisées et impliquées dans le produit (les développeurs ne sont pas là uniquement pour dépiler des tickets). Par ailleurs, ils ont davantage de libertés, que ce soit concernant :
- les choix d’implémentation (le lead dev n’est là que comme coach, et non comme prescripteur de solution technique),
- le design (le développeur prend part aux choix de design, et peut indiquer quelles solutions sont plus ou moins couteuses à implémenter, etc…)
- ou l’organisation interne (liste de tâches, réunions périodiques, etc…).
Pour ceux que cela intéresse, “Shape Up !” détaille aussi une méthode de mesure d’avancement de projet, ainsi que des idées pour lever les dernières interrogations qui peuvent exister au sein d’un projet.
L’étape de Cooldown, ou relâchement
L’itération est terminée, les projets ont été mis en production, il est temps maintenant de reprendre un peu son souffle. Pendant ces 2 semaines de cooldown, chacun fait ce qu’il “veut” : refactoring, bug fixing, optimisation, investigation d’une nouvelle librairie, mise en place d’un nouvel outil… C’est un temps libre qui permet au développeur de se perfectionner et d’améliorer son code de manière générale. En définissant ce cooldown périodiquement, la codebase est régulièrement révisée : on améliore la qualité globale du code, et on augmente la vélocité de l’équipe sur le long terme (implémenter une nouvelle fonctionnalité est beaucoup plus simple et rapide lorsque la base de code est bien entretenue).
Le cooldown se rapproche du concept de 20% Project qui avait été instauré chez Google. Cela consistait à laisser 1 journée par semaine aux développeurs pour qu’ils travaillent sur n’importe quel projet qui les motivait (de là est né quelques grands succès comme par exemple la messagerie Gmail).
Et la QA dans tout ça ?
L’équipe en charge d’un projet est responsable de la qualité de ce qu’elle livre, elle doit donc être capable d’évoluer sans QA. D’ailleurs, BaseCamp a longtemps vécu sans QA en interne ! La QA peut donc servir de coach de bonnes pratiques, ou pendant la phase de shaping pour détecter les limites, mais toute la phase de tests est censée être réalisée par l’équipe en charge du projet.
Quant à la gestion des bugs, elle est complètement décentralisée (chaque développeur gère son propre historique de bugs), mais surtout, elle se rapproche de la théorie du zero bug : si je rencontre un bug, je dois me demander s’il est critique. Si c’est le cas, il doit être corrigé immédiatement, sinon, je peux l’oublier. En effet, la probabilité qu’il soit priorisé dans une prochaine itération est extrêmement faible. Pour vous en convaincre, regardez la durée de vie moyenne de vos tickets de bugs : soit ils sont fixés immédiatement ou dans les 2 semaines suivant leur découverte, soit ils sont vieux de plusieurs mois voire années.
Mon retour sur ce process
Disons le tout de suite, j’apprécie énormément travailler avec la méthode “Shape Up !” : elle est beaucoup plus épurée que Scrum et laisse plus de place à l’autonomie. Pour autant, elle est très complexe à bien appliquer. Voici quelques écueils que j’ai rencontré.
Shaping : un numéro d’équilibriste
Respecter les différentes étapes de la phase de shaping n’est pas aussi simple qu’il n’y parait (on saute directement à la solution avant d’avoir défini un appétit par exemple). Mais le plus complexe dans cette étape reste de savoir quand s’arrêter dans la conception d’une solution. Il est très facile de vouloir aller trop dans le détail, et on perd alors tout l’intérêt de cette fameuse esquisse. Mais à l’inverse, il ne faut pas rester trop schématique, au risque de ne pas détecter certains cas aux limites. On peut alors se retrouver avec des problèmes beaucoup trop complexes et non détectés pendant le shaping.
La QA reste une étape nécessaire
Sur le papier, rendre les équipes autonomes et se passer de QA est séduisant, mais il faut bien reconnaitre que la pratique est plus complexe. L’activité de test demande une rigueur que tout le monde n’a pas. De plus, avoir un oeil extérieur sur un projet apporte beaucoup à la qualité d’une fonctionnalité (d’un point de vue expérience utilisateur ou encore pour certains cas aux limites). En conséquence, nous n’avons pas réussi aujourd’hui avec mon équipe à nous passer de cette étape de QA.
Convient à des entreprises plutôt stables
Des itérations de 2 mois, c’est long, en particulier pour les personnes qui ne sont pas dans l’équipe technique. Cela peut donner une impression que le produit n’évolue pas. De plus, cette durée n’offre pas beaucoup de flexibilité s’il faut changer de priorité rapidement, ce qui peut arriver si l’entreprise est encore jeune et cherche encore son positionnement.
Optimisation temporelle
Nous aimons beaucoup optimiser nos process pour ne pas gâcher la moindre minute, et c’est particulièrement vrai en France. On retrouve ce concept d’optimisation avec les estimations faites pour chaque tâche en poker planning par exemple. “Shape Up !” prend complètement le contre-pied de cette logique, et tous les concepts de vélocité et d’estimation volent en éclats. Cela peut déstabiliser de nombreuses personnes, et en particulier certains managers.
Par ailleurs, on ne parallélise plus du tout certaines activités en faisant par exemple les tâches BackEnd en avance par rapport au FrontEnd. Pareil, cela peut donner l’impression de ne pas utiliser nos compétences au maximum. Mais de mon expérience, cette optimisation est souvent contrebalancée par des nouveaux besoins de dernière minute, ou des problèmes de communication entre frontend et backend.
Et le positif ?
Il y a plein de positif dans “Shape Up !” : ne plus gérer un backlog infini et obsolète, travailler sur des projets de bout en bout, avoir un temps dédié à l’exploration… Cette méthode nous force à nous poser davantage de questions sur ce qui est réellement important pour l’utilisateur puisque nous travaillons dans un temps fixé à l’avance. Basecamp explique d’ailleurs “Cutting scope isn’t lowering quality” : implémenter moins de fonctionnalités sur un projet ne signifie pas diminuer sa qualité, bien au contraire puisque cela nous oblige à faire des choix qu’il faut savoir justifier.
Je ne peux que vous conseiller de tester cette méthode pour vous l’approprier. Et si vous l’avez déjà expérimentée, n’hésitez pas à me faire votre retour d’expérience en commentaire !
Ce qu’il faut retenir
- Durée des itérations plus longue (6 semaines + 2 semaines)
- 4 étapes pour la conception
- shaping : “appétit” pour un problème et schématisation de sa solution
- betting : priorisation des différents projets “shapés”
- building : implémentation des projets via des équipes dédiées
- cooldown : amélioration globale du projet, à la discrétion des développeurs