Faire face aux urgences dans les équipes Agile

Auteur : Serge Beaumont
Source :"Dealing With Emergencies In Agile Teams"
Date : 28/02/2011

---

Traducteur : Fabrice Aimetti
Date : 25/05/2011

---

Traduction :

Toute équipe Agile doit faire face à tout ce qui passe à côté de son travail "normal". Comment manipuler cette charge inconnue (par définition) générée par des urgences en production alors que dans le même temps vous essayez d'atteindre un rythme stable ? Vous pouvez faire face aux urgences en effectuant un tri préalable pour rejeter, reporter ou accepter. Vous pouvez prévoir une provision pour absorber une partie de cette incertitude, et finalement vous assurer que vous prenez le temps de réduire le nombre d'urgences en construisant la qualité intrinsèque[1]. Si vous faites surtout de la maintenance, vous pouvez envisager de faire du Kanban.

Le Contexte

Dans mes jours anciens sur des projets en cycle en V, je n'ai jamais eu à faire face à cette horreur parmi les horreurs, la maintenance. J'ai fait partie d'équipes construisant des choses nouvelles, et je pouvais continuer ainsi jusqu'à la fin du projet. C'était en fait à la charge du département maintenance de faire face à l'absurdité que j'avais créée. Ah, c'était le bon temps... que du plaisir et sans la gueule de bois après :-)

Mais les équipes Agile, ou en fait n'importe quelle équipe qui livre tôt et régulièrement (plus tard dans ma période cycle en V, j'avais commencé à comprendre que la maintenance démarrait en gros après les deux premières semaines... :-) ), livrent bien longtemps avant qu'il ne soit même possible de passer le relai à une autre équipe. Le fait de livrer régulièrement signifie que l'équipe doit faire face à toutes les questions qui se posent à elle. Premièrement parce que ce sont ses membres qui peuvent le faire, deuxièmement parce que vous voulez de toute façon intégrer des tâches correctives dans le travail de l'équipe : dans tous les cas, ils ont toujours besoin de livrer de nouvelles versions du logiciel...

En tant que consultant, j'ai vu cette question s'adresser à toutes les équipes Agile que j'ai connues, ce n'est donc pas une situation unique concernant un petit nombre d'équipes. Toutes les équipes Agile doivent apprendre à gérer ce problème !

Le Problème

Dans une équipe Scrum, le problème va généralement émerger après un ou plusieurs Sprints avec un certain nombre d' "incidents de production" ou toutes sortes de choses imprévues prenant tellement de temps à l'équipe qu'elle ne parviendra pas à atteindre l'objectif du sprint en cours. Le résultat c'est que l'équipe va avoir beaucoup de mal à planifier les sprints à venir. Le premier problème c'est qu'elle ne connaît pas sa Vélocité "réelle", le second problème c'est qu'elle va devoir apprendre, d'une manière ou une autre, à gérer des incidents de production, par définition imprévisibles.

Mais attention, il y a un piège caché dans le paragraphe précédent. La capacité à prédire n'est pas l'objectif final en Agile ! Il est important de savoir quand une version doit être déployée et comment rythmer l'équipe. Mais j'ai trop souvent vu des équipes tenter de "prédire péniblement" alors qu'elles auraient dû apprendre à mieux s'adapter. Lorsqu'on parle d'imprévisible, vous devez d'abord vous concentrer sur le fait de vous adapter, et non sur le fait de planifier encore plus à l'avance. Ce serait un retour à la Méthode du Cycle en V...

Le But

Ca y est, nous y sommes : le but est d'être capable d'absorber une quantité raisonnable d'incertitude, en s'efforçant de trouver un équilibre entre la robustesse et la vitesse.

Solution 1 : Faire le tri et rejeter

La première chose à vérifier est de savoir si vous voulez ou non régler ce problème de production. Ce n'est pas aussi idiot que cela y paraît au premier abord. Il y a tellement de cas où une urgence en production n'est pas une urgence du tout et n'est même pas importante ! Quelques exemples de "faux-incidents" :

• Le commercial déboule avec "l'affaire du siècle" : "Si nous développons la feature X TOUT DE SUITE, nous pouvons gagner le client X !". Selon mon expérience, c'est toujours dû au fait que le service commercial est mal éduqué et indiscipliné. Ici, la cause racine est que les commerciaux promettent des choses qu'ils n'auraient pas dû, et qu'ils ont maintenant besoin de sauver leur propre peau. Il est TOUJOURS possible d'attendre deux semaines pour une nouvelle fonctionnalité.
• Certains intervenants "repriorisent" des demandes normales en urgences de production pour éviter les négociations autour du backlog. "C'est complètement bloqué et je ne peux pas utiliser cette feature!". "Ah bon ? Est-ce-que le système a planté ? Est-ce-que quelque chose ne fonctionne pas ? ". "Euh... non, mais ça me bloque dans mon travail !". Cet utilisateur a un besoin bien réel, mais cela n'en fait pas une urgence de production.

Donc, la Solution 1 est la suivante : un solide Product Owner qui fait le tri sur tous les problèmes de production. Si c'est un problème réel en production alors corrigez-le par tous les moyens. Mais je peux vous garantir que vous trouverez un bon nombre de problèmes qui ne devraient pas être des urgences du tout... A propos, un Product owner qui trie de cette manière est ce que James Coplien appelle un Pare-feu dans son livre sur les schémas organisationnels.

Solution 2 : Faire le tri et reporter la correction dans le sprint suivant au minimum

"Nous considérons qu'il s'agit d'un très gros problème ! Nous avons besoin de la correction tout de suite !". "Bien sûr, nous allons traiter le problème. Depuis combien de temps ce problème existe-t-il dans le système ? ". "Eh bien, depuis plus d'un an, mais nous venons juste de le découvrir !". "C'est là depuis un an ? ... Et vous ne pouvez pas attendre deux semaines de plus pour la correction ?"

La solution 2 est une extension de la Solution 1. Il peut être effectivement important de corriger une urgence, mais il y a un critère important dans ce cas : c'est une urgence, uniquement si elle doit être corrigée dans le Sprint courant. Si vous pouvez reporter le problème au Sprint suivant, alors il n'y a pas de problème ! L'équipe peut l'intégrer à son processus, le planifier, le corriger et le livrer à la fin du Sprint suivant. C'est encore une fois de la responsabilité du Product Owner : en dehors de la décision de rejeter, un bon Product Owner fera en sorte que tout ce qui peut être reporté le soit effectivement.

Solution 3 : prévoir une provision pour gérer les problèmes inattendus

Si vous êtes passé par les Solutions 1 et 2, alors tout ce qui reste devrait être considéré comme de vrais problèmes que vous devez corriger le plus tôt possible. La meilleure manière que je connaisse pour gérer cette situation c'est de prévoir une provision de temps ou de points de story non planifiée. Cela fonctionne particulièrement bien si l'historique de la charge de travail dédiée à la résolution des problèmes est raisonnablement stable. Vous ne savez pas ce que vous ferez, mais vous savez quel effort il faudra fournir.


Mais attention en utilisant une provision, ça peut vous exploser au visage ! Le premier risque est la taille de la provision. Si la provision est un pourcentage important de la capacité du Sprint, disons plus de 1/5ème de votre vélocité, vous vous retrouverez alors avec un grand trou dans votre processus de planification. Appliquez donc la Règle n°1 : la provision ne concerne pas les items du backlog. Essayez de garder une provision qui soit la plus petite possible.

Le deuxième risque, c'est ce que j'ai déjà dit en décrivant la Solution 1 : dès que l'utilisateur voit une solution pour contourner le processus normal, vous pouvez être sûr qu'il va se jeter dessus. Une provision doit vraiment, vraiment être protégée de toute utilisation involontaire. Donc, triez bien !

Le troisième risque, c'est de dépasser la provision. Ce qui conduit à l'explosion du processus. Si la provision est utilisée, vous aurez besoin de déterminer quelle proportion de la provision a été utilisée, sinon vous allez avoir une drôle de surprise à la fin du Sprint.

Solution 4 : Corriger les causes racines, améliorer la qualité

Cette solution est présentée comme la numéro 4, car les trois premières sont dans l'ordre logique lorsque vous essayez de maîtriser les dégâts, mais finalement vous aurez envie de faire la chose la plus importante de toutes : corriger définitivement les problèmes et construire la qualité intrinsèque de sorte que vous n'aurez plus d'urgence du tout ! C'est quelque chose que nous devrions faire de toute façon, et ce n'est pas réservé aux projets Agile : vous voulez le faire dans n'importe quel type de projet ! Mais il y a une Règle supplémentaire qui est pertinente pour la provision (je remercie d'ailleurs au passage Jeff Sutherland, puisque j'ai appris cette règle lorsque nous faisions des formations CSM). Règle n°2 : Si vous dépassez la provision, arrêtez le Sprint. Si vous avez tellement de problèmes que vous ne pouvez même plus limiter le traitement des urgences à une petite provision, ce n'est plus la peine de chercher à vous améliorer pour développer des features. Arrêtez-tout et utilisez le Sprint pour corriger les causes racines, puis essayez à nouveau dans le Sprint suivant. C'est une coïncidence, mais la Règle n°2 fait également des merveilles pour tous les utilisateurs qui essayent de "reprioriser" : "voulez-vous vraiment corriger ce problème maintenant ? L'équipe estime que cela coûte deux points de travail, et cela va déborder de la provision. Il faudrait alors arrêter le Sprint, et vous n'aurez donc pas les stories utilisateurs que vous avez demandées ! Oh ... euh ... eh bien, je pense que ce n'est pas un problème si important que cela ... " (Et ça ne l'était effectivement pas ... il s'agit d'une véritable anecdote !).

Bonus : dimensionner correctement l'équipe

La taille de l'équipe n'est pas centrale dans le traitement des urgences, mais ça reste un critère dont il faut être conscient. Une petite équipe fonctionne bien mieux lorsqu'il n'y a pas de redondance, mais elle est moins robuste lorsqu'elle perd certains de ses membres. Une petite équipe est moins robuste contre la maladie ou des choses qui éloignent un membre de l'équipe comme ... des urgences en production peut-être ? Une équipe de 10 personnes qui perd une personne se traduit "seulement" par une baisse de productivité d'environ 10% (c'est un calcul grossier bien sûr, cela suppose que tous les membres de l'équipe sont totalement interchangeables en un clin d'œil), une équipe de trois personnes qui perd cette même personne se traduit déjà par un énorme 33% ! La taille idéale se situe plutôt autour de 7 à 9 personnes. Assez petite pour réduire la redondance, assez grande pour absorber une partie des pertes de productivité.

Pour finir ... envisager d'utiliser Kanban à la place de Scrum

Si vous pensez que votre équipe fait davantage de maintenance que de "nouvelles choses", vous pouvez envisager d'utiliser Kanban à la place. Parce que la granularité de Kanban est la story, pas le sprint. S'il y a une urgence en production, le délai d'attente avant prise en compte est intrinsèquement plus court pour cette raison. Kanban agit sur le flux, tandis que Scrum agit sur des itérations. Les deux styles sont si proches que j'ai vu une équipe Scrum progressivement passée en "mode flux" lorsqu'elle baissait en taille pour uniquement faire de la maintenance, et repasser en Scrum quand une nouvelle version était planifiée et qu'elle montait en taille.

Pour conclure

Toute équipe Agile doit faire face à tout ce qui passe à côté de son travail "normal". Vous pouvez faire face aux urgences en effectuant un tri préalable pour rejeter, reporter ou accepter. Vous pouvez prévoir une provision pour absorber une partie de cette incertitude, et finalement vous assurer que vous prenez le temps de réduire le nombre d'urgences en construisant la qualité intrinsèque. Si vous faites surtout de la maintenance, vous pouvez envisager de faire du Kanban.