Hiérarchie des estimations, malaise à l'échelle !

A chaque mission d'agilité à l'échelle à laquelle je participe, la même question : Combien de temps dure une initiative ? une EPIC ? une US et une tâche … ?

En soi, la question n'est pas inintéressante et mérite d'avoir des réponses. Mais, 90% du temps, la question se pose dans de mauvaises conditions et n'apporte que des réponses un peu vaseuses ou souvent fausses… voir très problématiques !

Année après année, on observe des PI-Plannings faits dans la douleur qui débouchent sur des plans… complètement imaginaires.

Nous allons revenir ici dans un premier temps ces fameuses configurations qui rendent difficiles voir impossibles les estimations “à l’échelle”. Dans un 2e temps, nous proposerons des “astuces” pour sortir de ces problématiques.

* Par facilité, nous utiliserons ici le terme de “tâches” pour parler de “choses à faire” qui peuvent être de tailles, de complexités ou de longueurs différentes.

* Je vais parler souvent de "développeurs" dans l'article. C'est à prendre au sens "scrum" du terme , c'est-à-dire tous ceux qui produisent quelque chose de réel. Des lignes de code ou autre chose. Cela exclut les managers, les PO, les PM…

1 - Seuls les développeurs peuvent estimer

Ce sont elles et eux qui vont développer ces "tâches" et personne d'autre. Ce qu'un stakeholder voit comme une epic ou Initiative, va peut être prendre 1/2 journée pour un dev ! Ou peut-être 8 mois…

Ma première question est donc la suivante : Est-ce bien les développeurs qui définissent et/ou rédigent les epics et initiatives ? Ou - comme on le voit beaucoup - des PO, PM, grands chefs et managers en chambre ?

Au doigt mouillé, dans 60% des missions auxquelles nous participons, la définition des epics et initiatives n'impliquent pas les développeurs. Dans ces cas-là, les estimations en temps sont quelque peu foireuses légères…

2 - Si votre équipe n’est pas capable d’estimer à l'échelle du sprint, pourquoi essayer d’estimer l'échelle de l’EPIC ou de la Feature ?

On ne compte plus le nombre d'équipes qui ont des taches de sprint qui durent plus d’un sprint.

Ce n'est pas dramatique en soit si ça reste peu fréquent et que ces tâches sont résolues rapidement au sprint suivant.

Malheureusement, dans de nombreuses équipes, on trouve ces fameuses tâches-à-rallonge qui sont là en trop grande quantité et/ou qui sont présentes depuis plus de 2 sprints.

Cela montre que l’équipe n'arrive pas - pour le moment - à découper ses tâches en plus petites tâches terminables.

Exemple :

“Actuellement, dans cette configuration d'équipe de P personnes, avec qui nous travaillons depuis plusieurs mois. Nous en savons assez sur nous-même pour connaître notre productivité. Nous pouvons dire que ce que nous appelons “User Story” met en moyenne J jours à être terminée.

Si cette EPIC est un regroupement de N User Stories, nous pouvons estimer (mais pas garantir) que nous terminerons cette EPIC dans J x N jours (si il n'y a pas d'autres tâches à faire auparavant).

A cela, il faut rajouter le reste du backlog à terminer ! - Disons RB jours.

Travailler sur plusieurs épic implique du Contexte Switching qui varie selon les développeur et le nombre de personnes travaillant dans l’équipe

Avec ces informations, nous estimons pouvoir estimer le Jour de Livraison JL jours.

JL = RB + CS + (J x N)

Attention, tout ce calcul n’a de sens que si le nombre de personnes dans votre équipe (P) ne bouge pas. (pas de vacances, pas d'arrêt maladie, pas de démission…)…

Comme vous pouvez le constater, il est possible de mesurer sa productivité et donc son estimation !

Résumons :

P : Nombre de personnes stables dans l’équipe

J : Temps moyen observé pour réalisé une user story

N : Nombre de User Story nécessaire pour faire une EPIC

RB : Reste du Backlog à faire

CS : Nombre de jours perdu pour passer d’une tâche / d’un sujet métier à l’autre

JL : Jour de livraison estimé de l’Épic

Tant que vous ne maîtrisez pas ces 6 variables, vous aurez du mal à maîtriser votre estimation à l'échelle.

Disons le clairement, s’engager sur des PI-Plannings sans maîtriser la productivité d’une équipe, c'est aller au casse pipe.

3 - Tout ce qui se planifie au-delà de 3 mois s'appelle de la science-fiction

Vos estimations de sprint-planning sont-elles maintenant justes ? Le nombre de story-points engagés sont terminés à 100 % à la fin du Sprint ?

Non. Il y a toujours une marge d’erreur.

Multipliez maintenant cette marge d'erreur par 6 (6 Sprints de 2 semaines => 3 mois).

Maintenant, multipliez cette marge d'erreur par le nombre de vacances et / ou événements perturbateurs qu'il va y avoir pendant ces 3 mois.

On est d’accord qu’on est sur du n’importe quoi ?

Très bien, maintenant, multipliez cette marge d’erreur par le nombre d'équipes que vous invitez au pi-planning. 😭

Et donc vous voulez planifier des choses au-delà de 3 mois ?

4 - Hiérarchie des estimations et hiérarchie tout court

La hiérarchie des tâches / US / EPIC / initiative répond très souvent à une hiérarchie dans l'entreprise :

• Les “grands-chefs" veulent piloter des initiatives,
• Les “moyen-chefs" le font avec des EPIC,
• Les développeuses et les développeurs, en bas de l'échelle, s'occupent des tâches techniques ou des "*user stories" (*qui n'en sont plus vraiment)

Au cours des différentes missions "d'agilité à l'échelle", nous avons fait le constat suivant : plus la structure hiérarchique est grande, moins les sprint-review sont faites. Rare sont les Sprint Review où un utilisateur final faisait un vrai feedback à la fois au développeur et en même temps au grand-chef-qui-a-écrit-l'epic ! Encore moins à celles et ceux qui ont écrit l'initiative et/ou la feature !

Cette hiérarchisation des estimations tâches casse aussi l’essence même de la User Story :

Kent Beck et Ron Jeffries qui ont inventé le concept de User Story imaginaient des cartes qui ne contenaient que des idées écrites seulement par des gens du métier et qui devait tenir dans moins de 3 phrases.

Entre l’initiative, l’EPIC et la User Story : qui détient l’essence du métier ? Où se trouve la volonté du client ? Nul part .

Résultat ? Quand le métier n'est pas content, il est très difficile de pointer la responsabilité. Par facilité on se penche sur les développeurs (ou l'ops) en bout de chaîne et rarement sur la hiérarchie…

La hiérarchie des estimations porte en son sein une déresponsabilisation des acteurs face au métier.

5 - Plus grande est la hiérarchie des estimations, plus les indicateurs sont bidonnés

Qui à envie de montrer de mauvais chiffres à son N+1 ?

Nous l’avons vue plus haut, la hiérarchie des estimations implique une dé-responsabilisation générale. Quand un problème arrive, il est très facile d’accuser le niveau du dessus ou du dessous d’avoir mal fait son travail.

Pire que tout : lorsqu’il commence à y avoir un mécontentement sur de mauvais chiffres de la part des clients ou des grands chefs, une certaine pression s’installe et redescend jusqu’au développeur… Ce qui a pour conséquence automatiquement une surestimation des prochaines tâches. Parce qu'à la fin, ce sont toujours les développeurs qui estiment.

Il nous est arrivé de discuter avec un PO qui nous expliquait qu’il remontait des estimations à sa directions sous-évalué de 10 % parce qu’il partait du principe que ses développeurs sur-évaluait de 20% les estimations ! Estimation qui arrivait toujours bonne - par miracle - jusqu'à à la direction une fois convertie en initiative.

C’est ce qu’on appelle des indicateurs pastèque : vert à l'extérieur, rouge à l’intérieur.

6 - Le mythe de la tour de contrôle financière

Ne passons pas par 4 chemins, l'objectif d'une entreprise est de faire de l'argent et c'est tout à fait normal.

Dans la théorie, un des objectifs des estimations à l'échelle devrait permettre de comptabiliser la capacité à faire d’une organisation et donc de pouvoir ajuster les ressources humaines en fonction des priorités et de la stratégie du moment.

Dans la pratique, on se rend vite compte que la connaissance de la capacité à faire est rarement liée à un pouvoir de modifier les équipes sur le terrain.

Prenons un exemple : A la suite de cette estimation à l'échelle, une DSI remarque qu’elle met trop d’argent sur une équipe qui produit quelque chose qui a peu de valeur.

Elle va donc naturellement souhaiter diminuer l’argent mis dans cette équipe, ce qui va se traduire par une diminution du nombre de personnes dans l’équipe.

Si ce sont des personnes employées par la société, il va falloir transférer ces personnes dans une autre équipe ou un autre service. Il risque d’y avoir tout d’abord des résistances côté management. Ensuite, des résistances côté RH, voire syndicale. Enfin la personne en question n’a peut être pas du tout envie de changer d’équipe. Dans tous les cas, il est fort à parier que ce changement d’équipe dure plus de 3 mois - Soit plus d’un PI planning ! - et créer de nombreux remous internes.

Si ces personnes sont des prestataires externes, il faut s'assurer que les contrats ne durent pas plus de 3 mois pour pouvoir le retirer ou ajouter des gens au besoins suite aux résultats de ces estimations. Soyons honnêtes, nous n’avons que très rarement vu des contrats de 3 mois.

A cela, il faut avoir en tête que tout changement dans une équipe, que ce soit en ajoutant ou en retirant une personne dans une équipe, produit de la désorganisation et du ralentissement de la production.

A quoi peuvent donc servir les estimations si derrière on n’a pas le pouvoir réel d’y faire quelque chose ?

7 - Alors que fa****ire ?

A ce stade on se rend compte que les estimations servent 3 grands principes :

• Rassurer les directions sur l’argent dépensé
• Organiser la planification des fonctionnalités
• Ajuster les ressources

Partons de ces finalités pour repenser nos estimations

8 - Rassurer les direct****ions - Appliquons le 7e principe

Quand un dirigeant, un haut manager, investit de l’argent dans un projet informatique, il joue une partie de sa carrière. Sa crédibilité est engagée avec cet argent.

Il est donc tout à fait normal qu’un dirigeant cherche à vérifier que cet argent dépensé soit bien utilisé. Mais, les estimations échouent à répondre à ce besoin fondamental qui est d’être rassuré.

Une estimation en nombre de jour/homme ou un point de complexité est toujours une abstraction - une mise à distance de la réalité.

Le 7e principe du manifeste du manifeste Agile nous le dit clairement :

Working software is the primary measure of progress.

Est-ce que vos dirigeants ont vu le logiciel en question fonctionner ? Est-ce qu’ils l’ont testé ? Est-ce qu’ils ont pu cliquer dessus ? Est-ce qu’ils ont déjà croisé le regard d’un développeur fier de sa nouvelle feature lors d’une démo ? Est-ce qu’ils ont parlé avec des utilisateurs finaux lors des démos ? Qu'ont-ils vu sur leur visage ? Qu'ont-ils entendu dans leur voix ?

Croyez-nous, même chez les plus des comptables habitué·es à la froideur des chiffres, ce genre d'interactions vaut 1000 chiffres perdus dans un excel, un jira ou un reporting sur PowerPoint.

9 - Planifier à l'échell****e - sans estimation - c’est possible !

Le PI planning est un très bon outil pour planifier à l'échelle, malheureusement, il est souvent fait à l'envers :

Revenons au pourquoi : un pi-planning sert à 2 choses :

1. Clarifier la priorisation des tâches à faire pour les 3 prochains mois
2. Planifier les dépendances techniques entre équipes

Rien d’autre ne doit être fait dans un pi-planning.

Pour faire cela, il faut :

1. Un backlog ordonnancé (et pas priorisé)
2. Un lieu pour afficher les tâches à faire et leur dépendances
3. Des personnes qui font le produit : développeuses et développeurs, testeuses et testeurs, ops, …

Avoir un backlog priorisé n’est pas simple : il faut d'abord savoir découper puis ordonnancer son backlog à l'échelle.

Pour découper le backlog en taches de tailles similaires, rien de plus simple et de plus efficace qu’une séance de extreme quotation avec les développeurs de toutes les équipes.

Pour l'ordonnancement à l'échelle. Là, on rentre dans des questions politiques.

Si vous ne voulez pas que les animaux dangereux décident de l'ordonnancement du backlog, nous vous conseillons de faire ces PI planning qu’avec des développeurs.

Plus vous aurez de chefs, de managers, de Product-QuelqueChose , plus vous allez avoir de personnes qui se battent pour défendre des intérêts contradictoires : Les grands chefs défendrons les intérêts des financiers, les petits chefs défendrons le pré-carré de leur équipe de développeurs, les développeurs etc...

Cela vous semble utopique ? C’est pourtant ce que propose LeSS, le framework d’agilité à l'échelle très proche de SCRUM et du manifeste Agile mais ayant une vision radicalement opposée à la bureaucratie de SAFe.

10 - Gérer ses ressources par produit, pas par Ressource Humaine

Si une équipe ne produit pas de valeur, la désorganiser en ajoutant ou retirant des personnes n’aidera en rien la productivité globale.

Comme nous l'avons fait à la TOTAL Digital Factory, nous préférons avoir des petites équipes qui travaillent sur des cycles courts, idéalement de 3 mois. A la fin de ces 3 mois un comité métier vient voir sur le terrain le travail fait et regarde si de la valeur pour un utilisateur final à été créée. A la suite de cela, le comité décide s'il faut continuer avec ce produit ou en lancer un nouveau.

L’équipe reste inchangée, mais elle change de produit.

Il est à noter que personne dans l’équipe n’est “trop spécialisé”, tous les développeurs sont autonomes et crosse fonctionnelle.

Tout cela nécessite d’avoir des engagements financiers capacitaires (on finance une équipe) et non orienté produit.

Cela permet de sortir facilement des tunnels inutiles qu’il faut finir “parce qu’on a commencé”.

Conclusion

En se lançant dans cet article, nous ne pensions pas être aussi véhéments. Force est de constater qu’une conclusion s’impose : il faut arrêter les estimations à l'échelle.

Nous avons conscience que tout le monde ne partagera pas cette conclusion. Mais nous espérons avoir apporté dans cet article des arguments pour penser cette question.

Enfin, nous tenons à rappeler ici que ce sont les estimations que critiquons, pas les analyses quantifiées de backlog. Les estimations sont des paris sur le futur, les analyses sont des observations du passé.

La pensée lean comme SCRUM nous invite à analyser la “météo d’hier” pour apprendre et comprendre notre travail et notre organisation. Nous sommes aussi très intéressées par l' analyse de type "pareto des causes" ou des calculs de lead time… Mais cela n'était pas le sujet du jour.

Cela fera sans doute l’objet d’un prochain article !