Scrum mou
Auteur : Martin Fowler
Source : Flaccid Scrum
Date : 29/01/2009
Traducteur : Fabrice Aimetti
Date : 15/06/2009
Traduction :
Récemment, j’ai entendu parlé d’une pagaille sur un certain nombre de projets. Le sujet est remonté ainsi :
- Ils veulent utiliser un processus agile et choisissent Scrum.
- Ils adoptent les pratiques de Scrum, et peut-être même les principes.
- Après un certain temps, les progrès sont lents parce que le code développé au départ était de mauvaise qualité.
Ce qui s’est passé, c’est qu’ils n’ont pas attaché suffisamment d’importance à la qualité interne de leur logiciel. Si vous faites cette erreur, vous verrez bientôt votre productivité tomber en chute libre en constatant qu’il est bien plus difficile que vous ne pensiez au départ d’ajouter les nouvelles fonctionnalités souhaitées. Vous venez de prendre un gros handicap de Dette Technique et votre équipe est à genoux (et si vous faites vraiment du Scrum, vous savez que c’est une mauvaise chose).
J’ai mentionné Scrum, car quand on constate ce problème, Scrum semble être le processus le plus fréquemment suivi par l’équipe. Pour de nombreuses personnes, cette situation est aggravée par Scrum parce que le processus est centré sur les techniques de gestion de projet et omet délibérément toutes pratiques techniques, contrairement à l’eXtreme Programming (par exemple).
Pour défendre Scrum, il est important de souligner que ce n’est pas juste parce qu’il n’englobe pas les activités techniques dans son périmètre d’application qu’il ne doit pas laisser penser qu’elles ne sont pas importantes. Chaque fois que j’ai écouté d’éminents Scrumistes en parler, ils ont toujours insisté sur le fait que vous devez avoir de bonnes pratiques techniques pour réussir un projet Scrum. Ils ne peuvent pas vous imposer ces pratiques techniques, mais sachez que vous en avez besoin. Après tous, les projets rencontrent des problèmes de faible qualité interne tout le temps, le fait que beaucoup tombent sous la bannière Scrum est peut être plutôt dû au fait que Scrum est très populaire en ce moment et n’est donc pas lié à Scrum lui-même. Popularité et "Diffusion Sémantique" ont tendance à aller de pair.
Alors, que faire ?
La communauté Scrum doit redoubler d’efforts pour veiller à ce que les gens comprennent l’importance de mettre en oeuvre de solides pratiques techniques. Tout audit de projet devrait inclure l’examen des pratiques techniques utilisées. Si vous êtes impliqué sur un projet, remontez une alerte si le côté technique est négligé.
Si vous cherchez à introduire Scrum, assurez-vous de bien prêter attention aux pratiques techniques. Nous avons tendance à appliquer majoritairement celles de l’eXtreme Programming qui marchent parfaitement. Les eXtreme Programmers blaguent souvent, avec raison, que Scrum c’est juste XP sans les pratiques techniques qui le font fonctionner. Blague à part, les pratiques d’XP constituent un bon point de départ – et certainement beaucoup plus que de ne rien faire du tout.
J’aime souligner que ce ne sont pas les méthodes qui réussissent ou échouent, mais ce sont les équipes qui réussissent ou échouent. Choisir un processus peut aider une équipe à appliquer les règles du jeu, mais à la fin, c’est l’équipe qui prend la responsabilité de mettre en œuvre ce qui fonctionne pour elle-même. Je suis sûr que les nombreux projets en cours mettant en œuvre du "Scrum mou" (Flaccid Scrum), nuiront à la réputation de Scrum, et probablement également plus largement à la réputation de l’Agile. Mais depuis que je considère la "Diffusion Sémantique" comme une fatalité, je ne suis plus trop inquiet. Les équipes qui échouent, échoueront probablement quelle que soit la méthodologie, qu’ils appliqueront mal; les équipes qui réussissent fonderont leurs pratiques sur de bonnes idées et le rôle de la communauté Scrum est de diffuser ces bonnes idées largement autour d’elle.
Beaucoup de gens se tournent vers le Lean comme la dernière mode de l’Agile. Mais plus le Lean sera populaire, plus il sera confronté au même genre de problèmes auxquels Scrum fait face aujourd’hui. Cela ne rend pas le Lean (ou Scrum) sans valeur, mais il nous rappelle que "les Individus et les Interactions sont plus précieuses que les Processus et les Outils".
