Comment gérer les imprévus … avec SCRUM ?

« Comment puis-je gérer le travail imprévu ? » est une question que j’entends très souvent de la part des équipes que je forme ou que j’accompagne. La réponse n’est pas aussi simple qu’il n’y paraît. La première chose à comprendre est que le travail non planifié est rarement un problème en soi. Habituellement, ce n’est qu’un symptôme des vrais problèmes qui ne sont pas évidents au premier regard. Il est crucial de comprendre ce qui cause le travail imprévu. Ce n’est qu’alors que nous pourrons nous attaquer à la source du problème sous le bon angle.

Vous pouvez-aussi décider de le laissez simplement pour de bon et de définir comment vivre avec (dans de nombreux cas, c’est l’option la plus raisonnable). Dans cet article, nous allons examiner différentes stratégies qu’une équipe peut utiliser pour gérer le travail imprévu.
Bien que ces conseils puissent être appliqués à n’importe quel processus de développement itératif, pour simplifier les choses, nous allons parler de la gestion des imprévus avec le framework SCRUM…après tout, selon « State of Agile », Scrum est la méthode Agile la plus répandue. Pour la même raison, j’utiliserai les termes “user stories” et “vélocité” tout au long de cet article.

Actions ponctuelles et solutions rapides

Les stratégies de cette catégorie vous aideront à stabiliser rapidement le flux de l’équipe à faible coût. Elles ne sont pas destinées à résoudre les racines des problèmes, mais bien souvent, c’est tout ce dont vous avez besoin. Cependant, souvent, après avoir appliqué une solution rapide, vous devriez rechercher une solution plus robuste.

1. Absorber

Exemple 1.1. Une équipe est à mi-parcours d’un sprint. Soudain, un utilisateur signale un bug pour une fonctionnalité récemment livrée. Ce n’est pas trop grand…. pas trop petit non plus. On a le sentiment que si ce n’est pas corrigé immédiatement, il sera enterré dans le Product Backlog. Le Product Owner aimerait que l’équipe corrige ce bug dès que possible.

Exemple 1.2. Une équipe finalise une user story et la présente aux parties prenantes afin d’obtenir un feed-back rapide. Il s’avère que certains détails importants avaient été négligés lors de son affinement. En conséquence, elle ne correspond pas exactement aux attentes. Les parties prenantes demandent à l’équipe de retoucher a la fonctionnalité pour que celle-ci soit considérée comme terminée.

Que faire ? Laissez l’équipe absorber ce nouveau travail.

Quand le faire ? L’incertitude est inhérente au développement de logiciels. La raison principale du travail de la scrum team et de la disponibilité du Product Owner est d’identifier les plus petites incohérences comme dans l’exemple 1.2 plus tôt afin que leur correction soit moins coûteuse. Une équipe “agile” doit être prête à exploiter l’opportunité d’utiliser les feed-backs à son avantage. L’autre chose que l’agilité nous enseigne est que si une équipe se sent à l’aise, aucun processus supplémentaire n’est nécessaire. Il peut être beaucoup plus facile de corriger le bug de l’exemple 1.1 que de démarrer une négociation et d’intégrer cette correction dans le backlog du produit. Ainsi, tant que la taille du nouveau travail est suffisamment petite ou qu’une équipe peut gérer l’augmentation de la portée sans mettre en péril l’objectif du sprint, aucune action spécifique n’est requise.

Où le faire ? Au sein du sprint en cours.

Type d’action. Pas d’actions.

Coûts et risques. Une équipe peut ne pas livrer tout ce qui a été prévu. Cependant, cela ne devrait pas être un problème à long terme. Si une équipe utilise des données historiques pour tenter d’être prévisible et planifier de futurs sprints, ces données devraient in-fine être prise en compte. En termes simples, la vélocité baissera un peu et se stabilisera à un nouveau niveau légèrement inférieur. Les planifications prendront automatiquement en compte ce fait et dans quelques sprints, l’absorption ne sera plus un problème.

2. Diviser et reporter

Exemple 2.1. Comme dans l’exemple 1.2, une équipe finalise une user story et la présente aux parties prenantes. Cette fois, ils découvrent qu’une grande partie de la fonctionnalité est manquante. Encore une fois, les parties prenantes demandent à l’équipe de la réaliser.

Que faire ? Finaliser la user story telle qu’elle avait été comprise lors du Sprint planning. Identifiez le nouveau besoin et créez  de nouvelles user stories qui intègrent le backlog et seront à planifier dans les sprints à venir.

Quand le faire ? Si la taille de ce nouveau travail est comparable à la taille d’une user story, il doit être transformé en un nouvel élément de backlog. L’un des concepts cruciaux derrière un sprint est de laisser l’équipe se concentrer sur le travail. Des changements suffisamment importants peuvent et vont briser le flux de l’équipe. L’autre raison est d’empêcher la dérive. Une user story doit rester centrée sur sa cible (la clause « Je veux »). Si on lui ajoute plus d’exigences, il y a toujours le risque de la faire grandir tellement qu’elle ne sera jamais finalisée. C’est pourquoi reporter le travail au prochain sprint est une meilleure approche ici.

Où le faire ? Le sprint actuel et les prochains.

Type d’action. Découpage/affinage à effectuer dès que vous identifiez le travail à faire.

Coûts et risques. La grande taille de ce nouveau travail signifie probablement que livrer uniquement la user story initiale n’a pas de sens pour l’utilisateur final. Les parties prenantes ne seront pas ravies de savoir que la livraison de l’intégralité de la fonctionnalité qu’elles souhaitent réellement va être retardée. Dans le même temps, il n’est pas rare qu’une nouvelle user story s’avère moins critique qu’il n’y paraît à première vue. Dans un tel cas, elle peut attendre quelques sprints supplémentaires. Dans tous les cas, il est de la responsabilité du Product Owner de définir des attentes correctes avec les parties prenantes.

3. Remplacer

Exemple 3.1. Lors de la deuxième semaine d’un sprint, les parties prenantes signalent un bug critique. Il devient clair que la correction ne sera pas facile à implémenter. Les développeurs estiment que cela prendra un temps considérable. Mais l’équipe n’a pas le choix. Ils commencent à corriger le bug.

Exemple 3.2. Au milieu d’un sprint, le Product Owner vient voir l’équipe avec une demande très urgente. Cette nouvelle fonctionnalité doit être réalisée en priorité et il faut l’ajouter au sprint.

Que faire ? Ajoutez la nouvelle user story ou le nouveau bug au sprint. Ensuite, décidez quelles autre user stories environ de même taille peuvent être sacrifiées et retirez-les du sprint. De préférence des user stories non commencées. Vous pouvez placer les éléments supprimés directement  en haut du backlog car il semblent néanmoins prioritaires.

Quand le faire ? L’utilisation de cette stratégie est assez simple. Chaque fois qu’il est nécessaire d’insérer un travail suffisamment grand, retirez du sprint quelque chose de la même taille. Vous vous demandez peut-être ce qui est « assez grand ? ». Le product owner ne connaîtra pas la réponse. Il est de la responsabilité de l’équipe de développement de prendre cette décision.

Où le faire ? Le sprint actuel et les prochains.

Type d’action. Intervention sur place.

Coûts et risques. La user story remplacée ne sera apparemment pas livrée dans le sprint prévu. Comme pour la séparation et le report, il faut prévenir et gérer les retours des parties prenantes.

4. Prévoir un tampon

Exemple 4.1. L’équipe a terminé le sprint planning et a commencé le développement. Quelques jours plus tard, un utilisateur signale un bug critique. L’équipe remplace une user story planifiée par le bug et continue de travailler. Quelques jours plus tard, d’autres bugs sont trouvés. La situation se répète plusieurs fois et une grande partie du backlog de sprint finit par ne pas être livrée. Cette situation se répète régulièrement.

Exemple 4.2. Une équipe possède depuis longtemps un système back-end et est devenue le centre d’expertise pour toutes les questions liées à ce système. Sans surprise, dès qu’un sprint commence, l’équipe est bombardée par d’autres équipes demandant de l’aide.

Que faire ? Pendant le sprint planning, prévoyez un tampon, de la bande passante, du mou … Il y a deux façons de faire ça. Tout d’abord, vous pouvez planifier un élément “virtuel” au sein de votre backlog de sprint, d’une taille fixée et qui comptera dans votre vélocité. C’est votre tampon. Chaque fois qu’une nouvelle user story ou un nouveau bug entre dans le sprint, vous soustrayez sa taille à l’élément tampon jusqu’à ce qu’il atteigne zéro. À partir de ce moment, tous les nouveaux travaux seront rejetés par l’équipe et mis dans le backlog du produit. Deuxièmement, vous pouvez simplement planifier moins d’éléments que votre vélocité habituelle. Pendant le sprint, vous absorbez simplement de nouvelles user stories. Cette différence entre l’engagé et le prévu agira comme un tampon implicite.

Quand le faire ? Essayez un tampon lorsque la situation est répétitive, que le travail non planifié est intrinsèquement inévitable et que la taille des user stories non planifiées est importante. Exemples possibles : l’équipe détient une expertise unique et doit consulter d’autres équipes ; les fluctuations du marché rendent difficile la production de prévisions fiables, même pour quelques semaines. La règle générale est que la mémoire tampon ne devrait pas prendre plus de 20 à 30 % de la vélocité de l’équipe et, en même temps, les objectifs de sprint doivent rester réalisables.

Où le faire ? Cycle de vie du produit.

Type d’action. Solution rapide. Solution temporaire.

Coûts et risques. Évidemment, le taux de livraison des éléments de la roadmap agile diminuera proportionnellement à la taille du tampon. Ce n’est peut-être pas un problème en soi, mais il y a un côté sombre. Le travail inattendu provient souvent d’inefficacités organisationnelles ou techniques, telles que les dépendances inter-équipes, le code legacy ou la faible qualité du produit. Lorsque nous introduisons des tampons, nous perdons effectivement jusqu’à un tiers de notre temps à combattre les incendies au lieu de produire de la valeur et de résoudre les vrais problèmes. C’est pourquoi vous devriez toujours considérer cette stratégie comme une solution rapide. Une autre raison d’être prudent avec les tampons est qu’ils sont difficiles à entretenir. La taille du tampon de planification repose sur l’hypothèse implicite qu’une équipe sera en mesure de contrôler la demande lorsque la taille du buffer atteint zéro. En réalité, je n’ai jamais vu une équipe capable de contrôler efficacement la pression des travaux urgents non planifiés une fois le tampon est consommé. Ce qui se passe essentiellement, au lieu de prévoir une seule variable très volatile – la vélocité – vous êtes maintenant obligé d’en prévoir deux.

Si vous visez une solution à long terme, vous devez toujours rechercher des moyens d’appliquer les actions d’amélioration continue de la liste ci-dessous.

Actions d’amélioration continue

Les stratégies de cette catégorie nécessitent des efforts importants et beaucoup de temps pour apporter des résultats positifs. Ils visent des dysfonctionnements. Le point commun à toutes ces stratégies est qu’elles sont mieux adaptées lorsque le travail non planifié est important, que la situation est répétitive, qu’elle casse constamment le flux de l’équipe et entrave la bonne exécution des sprints.

5. Améliorer la priorisation

Exemple 5.1. Une équipe finalise son sprint planning. Trois jours après le début du sprint, le product owner arrive soudainement dans l’équipe avec tout un tas de nouvelles user stories. Le product owner dit que les priorités ont changé de façon inattendue. A la fin du sprint, l’équipe se rend compte qu’elle n’a rien à livrer.

Exemple 5.2. Quelques jours après le début d’un sprint, le Product Owner demande à inclure une user story dans le sprint. Certaines parties prenantes ont demandé de la réaliser de toute urgence. Quelques jours plus tard, le product owner présente une demande similaire. Cette fois, c’est une fonctionnalité différente, cette user story est aussi urgente que la première. Cela se répète plusieurs fois pendant le sprint. Le résultat n’est pas une surprise. A la fin du sprint, l’équipe a peu produit.

Que faire ? Accompagnez votre product owner pour l’aider à apprendre à dire « non ». Travaillez avec les parties prenantes pour définir des attentes correctes concernant les releases. Expliquez que l’équipe ne peut accepter les demandes urgentes qu’occasionnellement. Si nécessaire, convenez de la signification, des critères qui font qu’une demande est considérée comme urgente et de la fréquence à laquelle l’équipe peut les traiter.

Quand le faire ? Il peut y avoir différents exemples, mais la caractéristique qu’ils partagent est qu’ils proviennent presque exclusivement soit du product owner, soit de parties prenantes. Ensuite, une fois les nouveaux éléments terminés, ils restent inactifs et attendent que quelque chose d’autre se produise. Par exemple, pour qu’une autre équipe complète ses user stories pour qu’une fonctionnalité plus importante devienne commercialisable. En réalité, le plus souvent, les nouveaux éléments ne sont pas aussi urgents et peuvent facilement attendre le prochain sprint.

Où le faire ? Cycle de vie du produit.

Type d’action. Correction de la cause première.

Coûts et risques. Nécessite le coaching du Product Owner et la négociation avec les parties prenantes. Cela peut être une tâche difficile. Puisqu’il s’agit de changer le comportement humain, ne vous attendez pas à des résultats rapides.

6. Améliorer la qualité

Exemple 6.1. Une équipe reçoit de nombreux rapports de bugs au cours d’un sprint. Beaucoup d’entre eux semblent critiques et nécessitent une correction immédiate. Lors de la rétrospective, l’équipe met en lumière que cela s’est produit encore et encore au cours des derniers sprints. Les bugs sont devenus une nuisance majeure. Ils perturbent le flux de l’équipe, son rythme et affectent la livraison. Vous pouvez le voir clairement dans les burn down. Les sprints sont chaotiques. L’équipe perd le contrôle de ce qu’elle fait.

Que faire ? Analysez les causes de la mauvaise qualité (par exemple, en utilisant des diagrammes de boucle causale). Est-ce parce que l’équipe subit trop de pression de la part de l’organisation ? Subit trop de pression pour tenir les délais ? S’agit-il de tests automatisés qui n’offrent pas une couverture suffisante ? Peut-être est-ce parce qu’il y a un problème d’infrastructure qui fait planter l’application de temps en temps ? Une fois les sources identifiées, consacrez du temps à les corriger. Essayez différentes stratégies. Très probablement, il n’y a pas de source unique de bugs et vous aurez besoin de différentes approches pour remédier au problème.

Quand le faire ? Il n’est pas si difficile de remarquer quand la qualité est le coupable. Vous commencerez à voir des bugs critiques apparaître de plus en plus souvent pendant les sprints. Ils briseront le flux et rendront presque impossible l’atteinte de l’objectif du sprint.

Où le faire ? Cycle de vie du produit.

Type d’action. Correction de la cause première.

Coûts et risques. Trouver la source des défauts peut ne pas être facile. Il est encore plus difficile de mettre en œuvre les actions correctives. Si une équipe constate un afflux de bugs suffisamment massif pour perturber le flux, cela signifie qu’il a déjà fallu suffisamment de temps pour que les effets négatifs de mauvaises décisions s’accumulent. Il va falloir des efforts considérables pour inverser la situation. Cela entraînera un ralentissement de la livraison, parfois de façon spectaculaire. À ce stade, une équipe devra faire le compromis. Veulent-ils résoudre le problème et remettre le produit dans un état maintenable au détriment de la production ? Ou prendront-ils le risque et espèrent-ils pouvoir tenir les bugs à distance jusqu’à la fin du cycle de vie des produits ? Si une équipe choisit la deuxième option, elle devra se rabattre sur la “stratégie du tampon”. Vous devez cependant vous rappeler que le ralentissement causé par une mauvaise qualité peut dépasser le ralentissement causé par une correction beaucoup plus tôt que prévu.

7. Supprimer les dépendances

Exemple 7.1. Comme dans l’exemple 4.2, une équipe d’experts possède un système back-end. Une équipe en aval a récemment commencé à développer un nouveau microservice. Ce microservice utilise le back-end comme source de données. Très vite, ils se rendent compte que le back-end manque de beaucoup de données dont ils ont besoin. Les demandes d’ajout d’un autre champ ou autres deviennent trop fréquentes et commencent à perturber sensiblement l’équipe.

Exemple 7.2. Une équipe possède l’infrastructure du système. Ils sont constamment interrompus par d’autres équipes. Une demande typique consiste à mettre à jour les paramètres d’un sous-système. Des tâches comme celles-ci sont assez simples mais prennent du temps et il y en a beaucoup.

Que faire ? Tout d’abord, vous voulez que l’équipe dépendante s’approprie autant que possible son travail et qu’elle devienne le plus autonome possible. Donnez-lui donc toutes les autorisations nécessaires, déléguer les responsabilités et la prise de décision. Par exemple, laissez-les déployer eux-mêmes le sous-système qu’ils gèrent au lieu de réserver ce droit à une équipe d’infrastructure dédiée. Formez-les à développer dans la base de code partagée. Déterminez le processus de révision du code pour éviter les baisses de qualité du code. Un développeur d’une équipe d’experts peut rejoindre une équipe dépendante pour renforcer rapidement son expertise et rendre les revues de code inter-équipes moins nécessaires. Deuxièmement, recherchez des moyens technologiques pour réduire la dépendance entre les deux équipes. Sans cela, la plupart des étapes mentionnées ci-dessus ne seront pas possibles.

Quand faire ? Comme son nom l’indique, cette stratégie convient bien lorsque le travail non planifié se présente sous la forme de demandes d’une équipe en aval. Généralement, ces requêtes bloquent l’équipe qui les crée.

Où le faire ? Cycle de vie du produit.

Type d’action. Correction de la cause racine.

Coûts et risques. Les deux équipes devront dépenser et faire des efforts pour supprimer les dépendances. Cela comprend des sessions de transfert de connaissances et des formations, l’étude de la nouvelle base de code et la mise en œuvre d’améliorations technologiques. Déplacer un membre de l’équipe d’une équipe à une autre prend également du temps pour que les deux équipes s’habituent à la nouvelle configuration. Cela peut influencer la vélocité des deux équipes. De plus, comme tout changement dans la structure de l’équipe il y a toujours le risque de déclencher un conflit qui nécessitera une attention particulière.

8. Adapter la manière de travailler

Exemple 8.1. Une équipe subit des interruptions constantes pendant les sprints. Les objectifs de sprint deviennent obsolètes et les backlogs de sprint sont complètement remaniés plusieurs fois par sprint. Le travail non planifié provient principalement du product owner. Une analyse approfondie amène l’équipe à comprendre qu’elle ne peut rien y faire. Le fait est que l’équipe développe un produit dans une jeune industrie où la concurrence est féroce. Retarder une fonctionnalité critique même de quelques jours peut pénaliser l’entreprise.

Exemple 8.2. Une équipe travaille sur un produit de longue durée avec une énorme legacy. Ils ont essayé toutes les bonnes pratiques connues et travaillent dur pour s’améliorer. Malgré tous les efforts, la dette technique et l’échelle du produit rendent presque impossible de terminer même la plus petite user story dans un sprint. Le problème est hors de portée de l’équipe. Il a été aggravé à plusieurs reprises et une initiative spéciale a été lancée pour atténuer le problème. Certains effets positifs sont déjà visibles, mais les progrès sont tout simplement trop lents. L’équipe se rend compte que ça ne va pas s’améliorer du jour au lendemain. Ils doivent faire face à la situation actuelle d’une manière ou d’une autre.

Que faire ? Essayez quelque chose de différent. Débarrassez-vous des itérations et commencez à utiliser la méthode Kanban. L’exécution de sprints, itérer, n’est pas la seule façon de faire du développement. Modifier : comme suggéré dans les commentaires, vous pouvez également essayer des sprints plus petits, tester Scrumban avant de passer au Kanban complet ou choisir votre propre option. Généralement, adaptez-vous au processus le mieux adapté à votre contexte.

Quand faire ? L’objectif principal de cette stratégie est de s’adapter à la réalité. Vous souhaitez l’appliquer lorsque le travail non planifié est intrinsèquement inévitable et dicté par des conditions externes qui échappent à votre contrôle. Voici la mise en garde, cependant. Dans des circonstances idéales, vous ne devriez avoir recours à la modification de votre processus que lorsque vous souhaitez vous adapter au marché ou obtenir un effet de levier sur le marché. Dans la vraie vie, il y a toujours une variété de facteurs et le choix d’adapter le processus peut toujours être justifié. Vous pouvez décider d’employer cette stratégie dans la situation de l’exemple 8.2. Cependant, vous devez réaliser qu’il s’agit d’une mesure temporaire qui vous aidera à supprimer le fardeau inutile des personnes et à gagner du temps pour mettre en œuvre de véritables améliorations.

Où le faire ? Cycle de vie du produit ou temporaire, selon l’objectif.

Type d’action. Correction de la cause racine.

Coûts et risques. Il y a une raison pour laquelle cette stratégie est répertoriée en dernier. Bien que cela puisse être la solution réelle pour vous, vous devez l’appliquer avec prudence et en pleine conscience. Vous devez être absolument certain que ce sont les circonstances extérieures qui provoquent le changement. Ne tombez pas dans le piège de confondre vos propres problèmes avec des circonstances objectives. N’oubliez pas que l’application de cette stratégie est toujours coûteuse et peut être risquée, car elle place une équipe dans un nouveau contexte et peut déclencher une réforme. Les performances de l’équipe diminueront très probablement et il faudra du temps pour s’adapter aux nouvelles méthodes de travail. Donc, avant d’essayer de changer le processus, effectuez toujours une analyse approfondie de la situation et essayez d’autres stratégies de cette liste. Sinon, vous risquez de simplement masquer les problèmes existants sans résoudre le vrai problème.

Pour aller plus loin

Coaching Agile : L’intelligence du Burn-down Chart