Le monde idéal…

Dans une précédente mission, je suis arrivé dans une équipe auto-organisée, autonome, avec un Product Owner totalement intégré à l’équipe. Il participe aux daily meetings, est donc informé au plus tôt de l’avancée des itérations, l’équipe est mûre, élimine les obstacles qu’elle rencontre toute seule, la communication se fait bien avec toutes les équipes de l’entreprise. Le monde idéal en somme… Mais, je fais quoi moi ?

Mon rôle de Scrum master n’est jamais le même d’une équipe à l’autre, d’un produit à l’autre. Tantôt formateur, tantôt protecteur, tantôt leader, tantôt facilitateur, tantôt coach… Ce dont cette équipe avait besoin, c’était plutôt d’un facilitateur, animateur d’équipe, mais qui n’interfèrerait pas sur son fonctionnement, puisque « tout fonctionnait bien » a priori.

… oui, sur le post-it !

Mais ce que j’ai appris pendant mes 5 années dans ce rôle, c’est qu’une façade idéale cache toujours des problèmes et de multiples axes d’améliorations possibles. C’est ce qui fait tout l’intérêt des méthodes agiles : sur un projet Agile, il n’y a pas moins de problèmes que sur un projet classique, mais la méthode les met en évidence, les fait remonter à la surface, aux yeux de tous, pour qu’on les corrige. Vu de l’extérieur, on pourrait même avoir l’impression qu’un projet agile a plus de problèmes ! Non, ni plus ni moins, mais il les montre.

Dans cette équipe Agile, des problèmes étaient donc bien visibles, et ne demandaient plus qu’à être traités.

Des tickets reportés, ah bon ?

Le premier, qui m’a sauté aux yeux, c’est que des tickets étaient reportés d’une itération à l’autre, que certains très complexes pouvaient même s’étaler sur plus de deux itérations, et surtout, que cela ne posait de problème à personne, que c’était la normalité.

Observation…

J’ai donc discuté de ce point avec le PO : si des tickets sont régulièrement reportés, comment fais-tu pour annoncer des dates à tes utilisateurs ? Impossible pour le PO de s’engager de son côté si les dates ne sont pas respectés.

Mais alors pourquoi l’équipe ne tient pas ses engagements ? La réponse est apparue lors de mon premier sprint planning avec l’équipe.

Le Scrum master arrive à la réunion avec un nombre de points réalisables pour le prochain sprint. Il a travaillé en amont avec le Product Owner pour la sélection des User stories prioritaires et appropriées. Au moment du planning, l’équipe prend connaissance du nombre de points et des tickets à réaliser. Et puis c’est tout…

Suite à cette réunion, je me retourne vers le PO et lui demande : est-ce que l’équipe ne s’engage pas sur le périmètre du sprint ? Son engagement, c’est le nombre de points, donc son estimation.

Mais n’y-a-t’il pas des tickets qui ont été estimés il y a plusieurs mois, et dont le travail à accomplir maintenant n’est pas le même que ce qui était prévu à l’époque ?

Voilà, nous avons un début de réponse : des tickets sont reportés et c’est normal, car à aucun moment l’équipe n’est impliquée dans le contenu du sprint à venir, à aucun moment l’équipe s’engage véritablement. La réunion de planning de sprint n’est qu’une présentation des tickets à réaliser.

Action !

Ma première action a donc été de réintroduire un vrai planning d’itération, où je présente une estimation du nombre de points qui devrait pouvoir être pris par l’équipe, mais où je laisse le Product Owner et l’équipe se mettre d’accord sur le contenu du sprint. L’équipe s’engage alors véritablement sur le contenu, en posant plus de questions au Product Owner, en se posant elle-même les bonnes questions par rapport à la difficulté des tickets à réaliser, à leur possible parallélisation ou non, à l’organisation pendant le sprint (binômage ? si oui, sur quels tickets ?), etc…

Des résultats

Le résultat a été très positif :

• le report de tickets n’était plus aussi fréquent (mais arrivait encore parfois, « monde imparfait » je vous ai dit !).
• mais surtout, l’équipe avait conscience des éventuels reports, et c’était systématiquement le premier problème remonté lors des rétrospectives : l’équipe a plus conscience des problèmes et cherche des solutions pour s’améliorer.

Deux complexités, ah oui ?

Observation…

Le second problème : l’hétérogénéité de l’équipe. L’équipe est constituée de 2 développeurs Front et de 4 développeurs Back. Les compétences techniques entre les 2 profils sont bien différentes, et un développeur Back ne peut pas réaliser ni estimer un développement Front, et réciproquement.

L’équipe utilise donc une double complexité : les tickets Back sont estimés en complexité Back, les tickets Front en complexité Front, et les tickets Back/Front contiennent 2 complexités différentes.

L’équipe produit donc 2 vélocités sur chaque sprint. Le problème d’une telle « complexité » de complexité est double :

• Difficultés pour la planification et la priorisation du backlog pour le PO avant les réunions de planning : il doit jongler avec 2 complexités, 2 vélocités.
• Division de l’équipe et des cérémoniaux : les développeurs Back ne s’engagent pas sur les estimations des développeurs Front, et réciproquement. L’engagement de l’équipe n’est pas total, et la notion même d’équipe est floue, elle n’est pas totalement soudée.

Action !

Mon objectif était donc que chaque membre de l’équipe s’engage sur l’ensemble du scope de l’itération, et que les séances d’estimation impliquent l’ensemble de l’équipe, et ce pour chaque User Story. Pour ce faire, nous avons sélectionné ensemble une User Story de référence, ni trop petite, ni trop grosse, bien maitrisée par l’équipe dans son ensemble car déjà réalisée et avec du développement Back et Front. Cette User Story valait 8 points, et lors des réunions d’estimation suivantes, l’ensemble de l’équipe se mettait d’accord sur une complexité unique pour chaque ticket.

Des résultats

Le résultat a été très positif :

• Le PO n’avait plus à jongler avec 2 vélocités, même s’il devait toujours s’assurer d’alimenter l’équipe à la fois en développement Front et Back.
• L’équipe était plus solidaire dans l’engagement, et il est arrivé qu’un développeur Front émette des doutes sur l’engagement de l’équipe à cause de la difficulté d’un ticket Back, tout simplement parce qu’un référent Back était absent une bonne partie de l’itération par exemple. On avait alors une vraie équipe soudée où chacun est impliqué dans le travail et l’engagement commun.

L’estimation, c’est long

Observation…

Voilà, on a une équipe plus soudée qui s’engage pour de bon et a conscience des reports. Oui, mais voilà, les réunions de Planning et Backlog Refinement, où l’équipe s’engage pour un sprint ou pour une estimation, durent plus longtemps qu’avant, et la fatigue aidant en fin de réunion, on est moins productif et on perd du temps.

Je me dois alors de préciser un peu : comment se passent les séances d’estimation ?

L’équipe se réunit, et pour chaque ticket à estimer, débat pour se mettre d’accord, parfois pour des broutilles, pour 1 point ou 2, quelque soit la taille du ticket d’ailleurs. Mais à demander de l’engagement et à impliquer les gens, on crée du débat voir des frictions, car oui, si on me demande de signer un contrat, je le lis en long en large et en travers, évidemment…

Action !

Mon action a donc été de mettre en place une nouvelle méthode d’estimation : l’estimation sous stéroïdes. Le Product Owner détaille tout d’abord les différents tickets à estimer, l’équipe pose les questions nécessaires à sa parfaite compréhension, puis on passe à l’estimation. Les cartes de points de complexité sont disposées en plusieurs colonnes sur une table, toute l’équipe se met autour de cette table, et tour à tour, chacun positionne un ticket dans une des colonnes de complexité ou modifie le positionnement d’un ticket déjà posé.

Des résultats

Le résultat a été très positif :

• C’est rapide, on ne discute plus des petits tickets, mais seulement des gros
• On discute mieux des gros tickets car toute l’énergie du groupe est focalisée sur leur estimation, rien est perdu sur un 1 ou un 2 (un 1 est aussi imparfait qu’un 2 et ne modifiera pas l’engagement de l’équipe lors d’un prochain planning)

Voilà trois actions concrètes que j’ai mises en place pour obtenir un engagement total et efficace d’une équipe soudée, et une meilleure implication.

D’autres actions ont été mises en place lors de mon intervention sur le projet, essentiellement décidées par l’équipe lors des rétrospectives.

Conclusion

Dans un monde Scrum idéal, on pourrait penser que le Scrum master n’est plus nécessaire. L’équipe est auto-organisée, s’améliore constamment, élimine elle-même les obstacles, et le Scrum master devient un animateur, facilitateur, et puis c’est tout.

Heureusement, le monde idéal n’existe pas, et toute équipe a des problèmes qu’elle ne peut pas régler toute seule, par manque de recul. Et il apporte quoi le Scrum master alors ? Justement, ce recul sur la pratique de l’Agilité.