Que faire lorsque Scrum ne fonctionne pas
Auteur : Henrik Kniberg
Source : What to do When Scrum Doesn’t Work
Traducteur : Fabrice Aimetti
Date: 05/02/2011
Traduction :
Cet article est basé sur mon discours fait lors du Scrum Gathering à Cape Town l’automne dernier.
Scrum c’est super ! Sauf quand il ne l’est pas. Que faites-vous quand Scrum ne semble pas fonctionner ?
Diagnostic 1 : Mal utiliser le processus
Si votre réponse immédiate à l’échec est "Oh, ça veut dire que vous utilisiez mal Scrum", alors soyez prudent.
Scrum est en effet souvent mal utilisé (dans ce cas, le remède est clair). Mais si vous arrivez à cette conclusion trop vite sans examiner la situation en jeu, alors vous êtes coupable de Scrum-fondamentalisme (la croyance erronée que Scrum est toujours la bonne solution). La déclaration "Si votre projet a échoué, alors c’est que vous appliquiez mal Scrum" se transforme, par transposition logique, en "Si vous appliquez bien Scrum, votre projet aurait réussi". Rappelez-vous ce que Fred a dit au sujet des balles d’argent !
Alors, que faire si Scrum est bien utilisé et que le projet semble encore être un échec ?
Diagnostic 2 : Blâmer le messager
Scrum est conçu pour révéler les problèmes. Une fois, un client a annulé un projet après le premier sprint. En se basant sur la vélocité de l’équipe et de sa future vélocité estimée, le product owner a réalisé que ce projet prendrait beaucoup trop de temps pour être rentable. Alors il l’a annulé.
Parfois, nous sommes tentés de tirer sur le messager : "Regardez, dès qu’ils ont commencé à faire du Scrum, le projet a explosé !". Heureusement, ils n’ont pas fait cela, ils ont réalisé que Scrum les avait aidé à économiser beaucoup d’argent en tuant un mauvais projet très tôt. Scrum a généré une « douleur saine ».
Quand un problème est révélé par Scrum, concentrez-vous sur le problème, pas sur Scrum.
Mais que faire si le problème semble être causé par Scrum ?
Diagnostic 3 : Être impatient
Le premier sprint, pour une nouvelle équipe, est généralement un véritable gâchis. Cela prend quelques sprints avant qu’une nouvelle équipe apprenne à collaborer efficacement. Des personnes impatientes pourraient tout de suite arriver à la conclusion que Scrum ne fonctionne pas : "Hé, regardez ce gâchis ! L’équipe n’a rien produit d’utile au cours du premier sprint, et ils ont passé la moitié du temps à discuter sur des chiffres sur des post-its !". Soyez patient, donner à l’équipe le temps de faire des erreurs et d’apprendre à partir de ces erreurs.
Lorsque vous apprenez à jouer de la guitare (ou tout autre instrument de musique), cela ne sonne pas très bien au départ. Cela ne signifie pas que l’instrument ne fonctionne pas, cela signifie seulement que vous devez continuer à pratiquer et à veiller à continuellement vous améliorer.
Donc, que se passe-t-il si nous sommes à bout de patience ? Que se passe-t-il si l’équipe a déroulé plusieurs sprints sans livrer quoi que ce soit ?
Diagnostic 4 : Ne pas adapter le processus
Supposons que vous appliquez Scrum "à la lettre" depuis maintenant plusieurs mois, et que vous vous tapez la tête constamment contre le même problème. Si vous continuez ainsi, vous allez être victime de Scrum-masochisme (l’hypothèse erronée selon laquelle la douleur provoquée par Scrum est toujours une "douleur saine").
Il est temps de faire évoluer votre propre dialecte de Scrum.
Oui, vous pouvez modifier Scrum. Et vous le devez. Mais seulement après vous être assuré que les diagnostics 1, 2 & 3 ne s’appliquent pas.
Vous passez trop de temps à discuter pendant l’estimation des tâches ? Eliminer l’estimation des tâches, ou éliminez les tâches tout court.
Vous passez trop de temps à discuter pendant l’estimation des stories ? Estimez alors en taille de T-shirt (S / M / L), ou arrêter d’estimer tout court. La vélocité peut se baser sur le nombre de stories plutôt que sur des points de story.
Vous avez de la difficulté à comprendre la façon de répartir de manière cohérente 15 personnes dans de plus petites équipes ? Laissez-les se former et se réformer, comme un organisme vivant, au gré des fonctionnalités à implémenter.
Est-ce que le product owner a désespérément besoin de changer quelque chose dans le sprint ? Laissez-les échanger la nouvelle story contre une story qui n’a pas encore été commencée au cours du sprint.
Est-ce que ces changements amélioreront la situation ? Vous ne le saurez pas tant que vous n’aurez pas essayé.
Est-ce encore du Scrum ? Je ne sais pas, mais est-ce vraiment important ? Tout ce qui fonctionne pour vous est bon, tout ce qui ne fonctionne pas pour vous est mauvais. Méfiez-vous de la Scrumbut-phobie (peur de mal faire du Scrum ; symptôme : coincé au niveau Shu).
Diagnostic 5 : Utiliser le mauvais processus
Il ya des contextes où Scrum n’est tout simplement pas approprié.
Supposons que nous ayons une équipe d’exploitation, de maintenance ou de support dont l’objectif principal est d’être réactif. Elle fait du correctif et de l’évolutif mineurs chaque jour. Cette activité ne peut pas être rythmée dans des sprints parce que les priorités changent trop vite. Lorsque l’équipe a un peu de temps, elle travaille sur de longues tâches d’amélioration. Ces longues tâches ne sont pas bien dimensionnées pour s’adapter parfaitement à un sprint; elles sont divisés en morceaux de taille différente qui représentent la valeur client.
Dans ce contexte, les sprints et les réunions de planification associées peuvent apparaître comme une perte de temps.
Les autres principes de Scrum – des équipes multidisciplinaires, des mêlées quotidiennes, ... – peuvent être conservés. Les itérations et d’autres rythmes de travail peuvent être appliqués. Mais un sprint est une boîte de temps de durée fixe, avec un périmètre fixe et parfois ce n’est pas le bon outil pour travailler.
Dans ce contexte, Kanban se propage rapidement. Les limites WIP de Kanban fournissent le même type de "stress positif pour livrer" que les sprints en Scrum, mais d’une manière différente. Les itérations ne sont pas la seule façon d’être Agile, en fait les itérations ne sont même pas mentionnées dans le manifeste Agile ou dans les principes de l’Agile.
Résumé : Que faire lorsque Scrum ne fonctionne pas
Le point clé est de ne pas sauter hâtivement aux mauvaises conclusions. Comme tout bon médecin, diagnostiquez le problème avant de suggérer un remède (les diagrammes de causes à effet marchent très bien dans ce cas).
Faites bien la différence entre "Mal utiliser l’outil" et "Utiliser le mauvais outil".
Et quoi que vous fassiez, ne blâmez pas l’outil. Scrum ne réussit pas ou n’échoue pas, ce sont les gens qui le font. Les gens choisissent où, quand, comment et pourquoi appliquer Scrum.
