Le problème

Le premier août, j'ai quitté l'équipe avec laquelle je travaillais depuis plus de trois ans et je suis devenu le chef de produit d'une équipe voisine appelée Catalyst. Catalyst était une équipe très performante; il avait dix ingénieurs, dont huit étaient "Sr. Ingénieurs. Catalyst était une équipe de gros frappeurs.

Lors d'une rétrospective deux semaines et demie après mon arrivée, quelqu'un a soulevé la question de nos séances de planification . Ils ne fonctionnaient pas; toute l'équipe était d'accord. Les principales plaintes étaient :

• Nos séances de planification ont été très longues. Nous avons tous passé une heure dans un zoom téléphonique tous les lundis (techniquement, il s'agissait d'une alternance de sessions de « planification » et de « raffinement » dans le cadre d'un « sprint de 2 semaines »). Ils étaient longs, pas des plus engageants et sans doute productifs.
• La plupart de nos tickets n'avaient pas de contexte ; il n'était pas clair comment ils se connectaient à un objectif plus grand.
• Nous n'avions pas assez de temps pour cadrage/planification en petits groupes. Les gens avaient soif de tableaux blancs, de sessions de 3 à 5 personnes où nous pouvions vraiment décomposer les choses et concevoir/architecter des solutions.

Ce que nous avons essayé

Plus tard, nous nous sommes réunis tous les trois dans le comité de proposition et avons passé en revue les problèmes. Nous avons discuté du fardeau très réel de la fatigue liée à la planification et aux réunions qui peut s'installer chez un ingénieur et saper sa productivité pendant une journée entière (ou plus).

Conformément aux premiers principes Agile, nous avons essayé de prendre du recul et de nous demander pourquoi nous organisions des réunions de planification. Pourquoi faisions-nous des sprints de deux semaines ? Pourquoi avons-nous séparé la planification et le raffinement ? Quels problèmes étaient les plus importants pour nous à résoudre avec nos rituels de planification ? Le faisions-nous simplement parce que la plupart des autres équipes le font de cette façon ? Quelle était la chose la plus simple que nous puissions essayer pour résoudre nos problèmes et incarner nos valeurs ?

Nous avons écrit quelques déclarations que nous voulions être vraies à propos de notre nouveau système :

• Nous ne voulons pas être liés à deux semaines. Nous voulons un système qui s'agrandit et se rétrécit de semaine en semaine en fonction de la quantité de planification que l'équipe doit réellement faire cette semaine-là.
• Nous n'avons vu aucune distinction utile entre la planification et le raffinement.
• Nous voulions que les individus puissent s'inscrire ou non à la planification en fonction de leurs besoins personnels, de leurs intérêts ou de leurs contraintes de temps.
• Nous voulions réduire considérablement le temps que nous passions tous les 12 à passer un appel à regarder notre tableau Trello. Nous pensions que c'était épuisant pour l'équipe, et pas très productif. Il y avait trop de monde dans la salle pour faire la vraie planification pratique dont nous avions envie.
• Nous voulions optimiser les sessions de travail de 3 à 5 personnes où nous pouvions réellement définir les tests et les solutions et rédiger des tickets.

• Tous les lundis c'est pareil. Pas de différence entre les lundis de « planification » et les lundis de « raffinement ».
• A 10h30 tous les lundis, nous rejoignons tous la réunion de 30 minutes "Cérémonies d'ouverture".
• Nous avons quatre autres tranches horaires de 30 minutes programmées tous les lundis de la journée : Bloc A, Bloc B, Bloc C et Bloc D.
• Lors des cérémonies d'ouverture, le PM et le responsable de l'ingénierie présentent les dernières informations concernant le contexte plus large du produit et de la livraison. Toute personne dirigeant un test ou un produit donné donne une brève mise à jour. Quelqu'un donne une mise à jour de la santé technique.
• Le groupe décide ensuite de la meilleure façon d'utiliser les quatre blocs utilisables ce jour-là . Quels projets nécessitent du temps de planification ?
• Les groupes décident du moment des « cérémonies de clôture » ; soit pendant l'un des blocs utilisables, soit au stand-up mardi (si nous manquons de blocs). Tout le monde partage les mises à jour dans Slack et dans un document de planification commun.
• Les projets peuvent utiliser les blocs comme temps de planification en petit groupe. De petits groupes discutent des objectifs du projet, décomposent les tâches en sous-tâches et rédigent des tickets ensemble.
• Les cérémonies de clôture ne prennent que 10 à 15 minutes. Chaque petit groupe informe l'équipe de ce qu'il a fait.
• Lors des cérémonies de clôture, l'équipe passe en revue toutes les échéances à venir qui informeront la hiérarchisation billet par billet.
• Vers quoi travaillons-nous ? Nous passons en revue les tests, etc. vers lesquels nous travaillons

Ce que nous avons aimé dans cette idée

Il y avait certaines choses qui nous passionnaient particulièrement concernant cette nouvelle idée.

• Le processus était complètement élastique ; certaines semaines, lorsque nous avions beaucoup de travail de planification à faire, nous avions déjà 2,5 heures de temps de planification bloquées sur le calendrier. D'autres semaines, lorsque nous avions déjà beaucoup de choses à faire, nous pouvions avoir un enregistrement de 15 minutes lors des cérémonies d'ouverture, puis terminer. Les ingénieurs pourraient se mettre au travail.
• Nous avons considérablement réduit les grandes réunions et optimisé pour des sessions de travail de 3 à 5 personnes.
• Nous avons donné à notre futur le pouvoir de décider de ce qui devait être planifié. Un bloc de temps pourrait être utilisé pour l'idéation du ciel bleu, la portée d'un test ou parler de la dette technologique.

Catalyst a essayé la planification de style olympique pendant 3 semaines, puis a fait une autre rétro pour réfléchir à ce qui fonctionnait et ne fonctionnait pas. Voulions-nous conserver la planification olympique ?

Les retours ont été extrêmement positifs. Pour toutes les raisons que nous avions théorisées, l'équipe aimait beaucoup plus la planification de style olympique que ce que nous faisions auparavant.

Les plus gros problèmes que les gens rencontraient étaient :

1. Si une personne manquait une session de planification pour un produit qui l'intéressait, elle se sentait complètement perdue par la suite et ne savait pas comment se reconnecter. Nous avons réalisé que nous ne faisions pas vraiment de « cérémonies de clôture », et c'était vraiment difficile pour ingénieurs pour rattraper les séances de planification qu'ils ont manquées.
2. Si une personne était intéressée par tout ce que nous faisions, cela impliquait soit des choix difficiles, soit un très long lundi de réunions.
3. Si nous n'étions pas très précis pour organiser des réunions au bon moment et avec les bons liens d'appel, les gens auraient beaucoup de mal à trouver une session de planification.

Pour résoudre le problème #1, nous avons abandonné le concept des cérémonies de clôture. Au lieu de cela, nous avons décidé de conserver un document "Planification olympique" en cours d'exécution dans lequel nous gardions une trace chaque semaine des blocs qui devaient être utilisés pour quels sujets. Nous avons institué une nouvelle règle qui stipulait que :

• Chaque bloc est responsable d'ajouter à notre document de planification ce dont il a été question et d'ajouter un lien vers tous les tickets, documents de portée, etc. qui ont été mis à jour dans le cadre de la session de planification.

Leçons apprises

Dans l'ensemble, Catalyst considère la planification de style olympique comme un énorme succès. Un processus élastique qui optimise la planification du style de session de travail est exactement ce dont Catalyst a besoin en ce moment.

Quelqu'un a demandé dans notre récente rétro : « Devrions-nous réinventer davantage nos rituels hebdomadaires de la même manière ?

Nous avons brièvement parlé de nos processus actuels pour Standup et Retro, et avons décidé qu'il n'y avait pas de problème brûlant avec l'un ou l'autre pour le moment. Nous avons donc décidé de ne pas réinventer ces processus.

Je suis très enthousiasmé par la manière dont nous avons mis en œuvre les valeurs du manifeste agile sans trop nous encombrer de l'axel avec les pratiques courantes qui ont été confondues avec le concept de développement agile lui-même.

Il était une fois une équipe qui a inventé des sprints de 2 semaines (avec planification et raffinement) comme un processus qui répondait à leurs besoins et résolvait leurs problèmes. Malheureusement, je pense que trop d'équipes adoptent ce type de processus sous couvert d'agilité sans réellement se poser de questions difficiles sur leurs points faibles et les résultats qu'elles aimeraient obtenir grâce à la planification.

Si cela vous semble intéressant, j'encourage toute équipe qui n'aime pas leurs rituels de planification à essayer la planification de style olympique ; mais ce n'est pas vraiment le sujet . Le vrai point est le suivant : nous devrions tous réfléchir en permanence à nos processus et nous demander : « Est-ce que cela fonctionne pour nous ? »

Le génie d'Agile n'est pas dans ses processus par cœur. C'est que cela nous encourage à essayer rapidement de grandes choses audacieuses, sachant que rien de terrible ne se passera tant que vous pourrez rapidement déterminer si cette chose fonctionne ou non (et la changer/la remodifier aussi rapidement si nécessaire). Itération rapide informée par des boucles de rétroaction rapides. Un changement drastique n'est effrayant que si vous ne pouvez pas le modifier/le modifier rapidement.

Nous sommes toujours en train de planifier le style olympique ! Cela continuera d'être notre façon préférée de faire de la planification jusqu'à ce que ce ne soit plus le cas.