"L'équipe n'était pas à 100% dessus"

On vous avait promis que cette fois, juré, craché, vous seriez à 100% sur le projet. Même que la direction s'est mis d'accord et que c'est affiché dans une grande salle de réunion.

Le product owner a pris une marge de 20% car les estimations sont à la louche et préfère assurer ses arrières.

Cette fois, j'ai ouvert les yeux et aies épluché les stories passées. Ces "petites" demandes courantes que nous casons à droite à gauche représentent en réalité 55% de l'engagement de l'équipe, en moyenne sur les deux derniers mois. 45% sont consacrés au vrai projet priorisé. Viennent s'ajouter ensuite les imprévus "urgents" en cours d'itération. Ceux là représentent une journée de dev par semaine.

Pour avoir une date, il ne suffit donc pas d'additionner les points et de diviser par la vélocité de l'équipe. Regardez à quoi ressemblent vos itérations précédentes pour de vrai : quel est la part de projet, de bugs, de courants, d'imprévus ? La projection de la date doit tenir compte de ces chiffres.

Deuxièmement, un développeur me chuchote à l'oreille que c'est ennuyeux et démotivant de travailler plusieurs mois sur le même sujet. Que certaines tâches ne sont pas parallélisables, qu'elles ont un ordre, des dépendances et que cela ne sert à rien de mettre 100% de projet dans ces cas là. Tâtez donc le terrain pour moi s'il y a beaucoup de stories "non parallélisables". Le corollaire de cela veut aussi dire qu'il est tout à fait improductif de rajouter des personnes sur un projet en retard : au mieux, ils vont devoir attendre, au pire, ils vont prendre du temps à ceux qui avance pour leur formation.

"La spécification était incomplète"

"La spécification n'était pas claire / a changé" peut aussi être invoquée par quelques perfectionnistes. L'erreur est humaine et la personne qui rédige la spécification aussi. Avec le temps, elle peut avoir de nouvelles informations et changer d'avis. C'est pire de coller au "contrat" et d'aller au bout d'un projet qui ne servira juste à rien...

Le produt owner ne pense pas à tout, le développeur fait des bugs, le marketeur se trompe parfois de cible, bref il faut arrêter d'exiger des autres d'être irréprochables. C'est une très mauvaise habitude que j'ai aussi. Chercher la perfection, cela s'appelle juste être chiant.

La méthodologie agile est un excellent médicament : nous livrons un petit incrément (peut être imparfait), puis récoltons du feedback, puis ajustons en fonction. Ce cycle permet de taper plus juste. Si à la fin tout ne peut pas être livré, ce n'est pas grave. Premièrement parce que 80% de la valeur est construit avec 20% d'efforts. Deuxièmement, parce que ce qui aura été produit sera plus pertinent que le projet original fait à 100%.

"Nous nous sommes mal compris"

Voir "Le projet est en retard parce que la spécification était incomplète". En faisant tester le plus tôt possible, les malentendus sont limités. Mieux : faire relire les spécifications exécutables au product owner avant de développer. Lâchez aussi votre clavier pour discuter de vive voix de temps en temps avec "l'autre".

"L'exploit n'a pas préparé les machines à temps"

C'est le problème dont la solution est la plus simple : il faut poser à plat toutes les dépendances extérieures et les prévenir au plus tard au début du projet. Le SMIC consiste à leur envoyer un mail. Le luxe à faire un point avec eux en amont du projet.

"Les développeurs ont glandé"

Autrement appelé "le syndrôme de l'étudiant" : Nous trainons doucement au début et speedons comme des malades les derniers jours. Certaines personnes travaillent mieux sous le stress et aiment l'adrénaline à l'approche de la deadline. Il y a de la fierté à en avoir baver. Malheureusement, quand un souci apparait quand nous sommes déjà un peu justes, la date ne peut alors être que décalée.

Que l'on ait besoin de stress ou pas, il est difficile de se projeter sur un projet qui sort six mois plus tard. Nous nous rendons compte trop tard que nous sommes en retard. Nous avons besoin de voir des avancées. Livrer des incréments régulièrement n'est pas suffisant. Je pense important que ces lots aient du sens, qu'il y ait quelque chose à célébrer.

Plus un projet est gros, plus il y aura du retard dessus. Attention aux gros chiffrages. Ils reflètent surtout de l'inconnu et nous amènent tout droit vers un effet tunnel. Pour les éviter, je tente en général une de ces trois options :

  1. les découper
  2. créer un story de prototype intermédiaire
  3. faire une timebox.

"C'était mal codé"

Les développeurs non plus ne peuvent pas penser à tout. Il y aura des bugs. Le tout est de réserver suffisamment de temps pour la recette et corriger les bugs avant la mise en production.

"Le tech lead a eu une angine"

L'estimation du projet doit être valable pour l'ensemble de l'équipe. Si une tâche est très facile pour Jeanne et compliqué pour Jean, se baser uniquement sur l'estimation positive de Jean est une grave erreur. S'il y a des dépendances internes (des spécialisations), il vaut mieux les aborder en début de projet tant que tout le monde est là.

Il y a aussi beaucoup plus de chances pour que des stories soient plus longues que prévues que l'inverse. Mieux vaut se prévoir une petite marge d'erreur sur les estimations si la deadline est dure.

Je répète néanmoins que la deadline ne doit pas être trop lointaine, c'est aussi démotivant (revoir la section "Les développeurs ont glandé") . Un copain me disait que dans sa banque, aucun projet ne dépassait 30 jours car, au delà, la date n'était jamais tenue.

"Un développeur est en vacances / Le designer est en congé"

C'est une variante évidente mais un homme avertie en vaut deux : ayez une idée des vacances des parties prenantes afin de les répercuter sur le projet et d'organiser le projet au mieux.

Conclusion

Je ne dis pas que ces solutions suffisent à limiter les retards. Mais sans en tenir compte, on est quasi certains de se planter. Vous pouvez aussi ne pas piloter le projet, masquer les retards dans de nouveaux lots ou les abandonner en plein envol pour "tenir la date".... Je précise également que l'on peut faire dire ce que l'on veut aux métriques. Pour cette raison, elles doivent être internes et évolutives.

Et vous, quelle est votre formule magique ?