Cérémonies agiles et agrandissement des équipes
Chez Captain, nous travaillons depuis le début en agile avec la méthode Scrum. L’équipe a atteint une efficacité satisfaisante grâce aux différentes cérémonies. Cependant, avec l’augmentation des effectifs, nous avons rencontré des difficultés pendant certaines d’entre elles. Mettant à profit les rétrospectives et réorganisant nos équipes en squads, nous avons tenté de résoudre ces problèmes. Voici le résumé de nos difficultés et les solutions apportées.
Attention: si dans le cadre d’une solution globale nous avons divisé notre équipe en deux groupes de trois personnes pour rendre les choses plus gérables, nos solutions proposées ne sont pas nécessairement exclusives aux squads et devraient rester pertinentes pour d’autres organisations.
Un daily standup bien cadré pour commencer la journée
Le daily standup est un élément clé dans les méthodologies agiles. Beaucoup de gens disent que quand ce dernier perd en efficacité, c’est parce qu’il n’est plus fait dans les règles (par exemple limité à 15 minutes). Avec 6 développeurs et 2 product owners, la communication est devenue un peu plus compliquée. En se forçant à tenir en 15 minutes, nous nous sommes rendu compte que l’information ne circulait plus assez, les appels à l’aide n’étaient pas répondus et certains d’entre nous perdaient en attention.
Le problème était principalement dû à la masse d’informations à exprimer dans un court interval de temps, et les gens n’avaient pas assez de recul pour formuler une réponse.
Quand l’équipe s’agrandit, les points clés d’un daily standup réussi sont selon nous:
- Être synthétique mais s’engager à rediscuter des problèmes plus tard.
- Être explicite sur le fait d’avoir besoin d’aide ou non et déclarer à haute voix “Je n’ai pas besoin d’aide”
- Si possible, diviser les participants (probablement sur la base des épics sur lesquels les différents membres travaillent) et animer les standups en parallèle
Des rétrospectives plus équitables
Nos rétrospectives ont vu naître deux problèmes. Lister les sujets de discussion prenait trop de temps et les membres de l’équipe produit étaient frustrés car les sujets leur tenant à coeur n’étaient pas abordés par manque de temps. Une solution aurait été de lier la durée de la rétrospective au nombre de participants, mais nous avons préféré une approche moins contraignante au niveau du temps.
Pour assurer une bonne efficacité, nous avons décidé que chacun devait venir avec une liste de sujets à aborder préalablement préparée. Au moment de les lister, il faut éviter d’ajouter trop de commentaires à l’oral (si ce n’est pour déclarer que quelqu’un a le même sujet). Cela nous a fait gagner 15 minutes de débat sur les solutions.
Pour limiter la frustration du pôle produit, nous avons décidé qu’au moment du vote des sujets à aborder en priorité, nous allions leur accorder plus de votes, puisqu’ils sont minoritaires par rapport aux développeurs. Nous avons trouvé un équilibre de respectivement 3 et 2 dans notre cas. Nous nous laissons la liberté d’ajuster le ratio en fonction des participants mais en gardant un minimum de deux votes par personne. Cela marche très bien pour nous et tout le monde est content.
Enfin, comme nous nous sommes divisés en deux équipes mais que leur composition n’est pas figée, nous gardons la totalité des membres dans la même cérémonie, certains sujets étant liés à notre division en squad et requièrent la présence de tous. Jusqu’ici, nous avons en moyenne le temps d’aborder 90% des sujets votés ce qui nous satisfait largement. Si nous sommes assez nombreux pour créer une troisième squad et nous trouvons en manque de temps, il faudra essayer de paralléliser la rétrospective (du moins en partie).
Un sprint planning bien préparé
Avec la croissance de notre équipe, notre vélocité a augmenté, ce qui veut dire plus de tâches effectuées, et donc des sprint plannings plus long. Plus de questions sont posées, les tâches sont remises en question et nous dépassons rapidement notre durée standard de deux heures. Après une analyse attentive, nous avons isolé différents problèmes et trouvé une réponse pour chacun d’entre eux.
- Nous prenions trop de temps à présenter les tâches et poser des questions à propos des différentes fonctionnalités. Nous avons décidé de lire et remettre en question les tâches avant le sprint planning (au plus tard un jour avant) et de façon asynchrone.
- Nous passions environ 15 minutes à regarder la complétion du sprint terminé, à regarder le calendrier des congés et calculer l’engagement en points. Désormais, nous déterminons notre engagement à l’avance pour ne pas perdre ces précieuses 15 minutes.
- Comme le gain n’était pas encore suffisant, nous avons décidé de paralléliser l’estimation de l’effort en attribuant les tâches par avance aux différentes squads. Certaines restent non attribuées et servent de variable d’ajustement durant le planning pour compléter l’engagement de chaque groupe. Nos squads ne sont en effet pas pleinement indépendantes : les tâches techniques, la réduction de la dette et la résolution de bugs sont une responsabilité partagée.
Nos démonstrations changent peu
Pour la revue du sprint, nous effectuons une démonstration devant le reste de l’entreprise. Au début nous présentions une slide par tâches et un exemple en live dès que possible. Mais le nombre de tâches a bien augmenté et le tout ne rentrait plus dans 30 minutes. Nous avons évolué vers un format d’une slide par epic, présentant en live tous les changements conséquents pour ce sujet d’un seul coup.
Cela nous a fait gagner en temps et a permis au public de prendre du recul, poser des questions et nous faire des retours intéressants.
Le mot de la fin
Les solutions que nous avons apportées pour résoudre nos problèmes ont un certain nombre de points communs. Nous essayons de suivre plus rigoureusement les règles, mais aussi de mieux préparer chaque cérémonie de façon individuelle. Quand c’est pertinent, nous essayons aussi de paralléliser le plus possible pour nos deux squads.
Plus de préparation préalable peut sembler une perte de temps mais au final ce n’est pas le cas. On pourrait objecter que ce temps est autant de temps supplémentaire virtuellement ajouté aux cérémonies, mais il est dilué dans notre quotidien, et une préparation individuelle a tendance à être plus efficace que des discussions s’éternisant en début de cérémonie, ce qui nous fait gagner un précieux temps au final. D’autre part, lire et remettre en question les tâches au calme permet aux gens de prendre du recul et d’être plus pertinent.
Pour finir, nous utilisons la rétrospective pour ajuster le sprint à un degré supérieur : il ne s’agit pas juste d’à quel point le sprint s’est bien passé mais aussi comment les gens se sentent par rapport à sa structure. C’est peut-être le conseil le plus générique que nous pouvons donner, et aussi le plus adapté à tous. Si vous faites de l’agile, n’hésitez pas à changer ce qui ne fonctionne pas pour vous, essayez d’adapter différentes solutions pour trouver ce qui convient le mieux à votre équipe. Toute frustration devrait mener à une discussion ouverte avec le reste de l’équipe. N’oubliez pas que quand l’équipe s’agrandit, les besoins changent, l’adaptation doit être continuelle.
Vous avez aussi vécu la croissance d’une équipe et l’adaptation des process qui en découle ? Faites-nous part de vos remarques !
