Le sport ce mois-ci dans la blogosphère, c’est de d’annoncer l’échec ou la mort prochaine de Scrum. Chacun y va de son article, soit vraiment inspiré et intéressant, soit complètement à côté de la plaque. C’est un mouvement amorcé sur les blogs anglophones qui va sans doute arriver dans les semaines qui viennent chez nous. Je vous propose un résumé des questions soulevées ces derniers temps afin de faire avancer le débat.
En novembre dernier, James Shore a publié un article intitulé « The Decline and Fall of Agile« . En substance, James explique que les clients qu’il rencontre et qui disent avoir mis de l’Agilité dans leur gestion de projet sont souvent en souffrance. En passant d’une conception où le design et l’architecture sont fait en amont à un processus itératif comme Scrum, ses clients emmagasinent une énorme dette technique. Certes les fonctions clés du logiciel sont livrées mais il regrette que ses clients ne prennent pas en compte aussi les bonnes pratiques de la conception Agile proposées par l’eXtreme Programming (XP).
Scrum est un formidable bâton de dynamite.
Pour peu que votre projet soit un peu bancal, mettez en place Scrum, laissez exploser cette dynamite et les poissons morts viendront à la surface. C’est un catalyseur qui mettra en avant l’ensemble des points faibles d’un projet ou d’une équipe, chose que l’on ne voit pas aussi vite avec un projet au forfait classique.
Alors que faire pour éviter cela ou se corriger ? La question est : comment durer ?
James explique que l’introspection est l’un des principes les plus importants souvent oublié ou négligé par les personnes qui débutent avec Scrum.
Le souci numéro un, et je le vois aussi aujourd’hui dans ma mission, c’est que l’on est tenté de ne choisir qu’une partie des règles de Scrum. Imaginez jouer au foot mais en ajoutant que vous pouvez ramasser la ballle avec la main et que la durée des mi-temps n’est pas fixée à 45mn mais à votre bon vouloir…
Premier principe : suivre dans un premier temps le processus. Agile ne veut pas dire « je peux faire n’importe quoi ».
Une critique faite à Scrum est aussi de ne pas avoir de pratique d’ingénierie. Oui en effet, Scrum n’est pas XP (eXtreme Programming). Scrum est un framework léger de gestion de projet. Ce n’est pas votre mère. Si vous souhaitez coder comme un cochon, libre à vous de faire ce que vous voulez. Jeff Sutherland explique qu’il voit que les équipes Scrum s’équipent en complément de méthodes XP, mais qu’il ne faut pas tomber dans le dogmatisme à outrance. J’ai fait l’expérience de faire du Scrum avec des pratiques de l’extreme programming (intégration continue, tests unitaires) sans non plus appliquer les 13 Principes d’XP car mon équipe marchait très bien sans. Et je ne suis pas le seul à le dire.
Regardons nos méthodes de développement : il est acquis en 2009 que l’industrialisation, l’intégration continue, les tests unitaires et le travail en binôme sont importants. Je me souviens de l’excitation autour d’XP que les gens ont un peu oublié. En 2002 un livre écrit par des français comment Laurent Bossavit plutôt bien écrit m’a fait découvrir XP. Aujourd’hui nous sommes tous d’accord pour dire que les tests unitaires, la pratique du TDD, la refactorisation sont des pratiques importantes, indispensables et professionnelles.
Donc pour moi, je considère comme acquis dans notre conscience ce besoin, et qu’il n’est pas forcément nécessaire de cristalliser les personnes qui font du Scrum en leur disant « ET FAITES AUSSI DU XP NOM DE DIEU… ».
La majorité des équipes qui appliquent Scrum utilisent déjà tout ou partie des pratiques XP. Un développement au forfait fonctionne aussi bien avec des bonnes pratiques proposées par XP.
Revenons à Scrum : l’importance de l’environnement.
Je travaille depuis quelques mois dans une nouvelle équipe. Scrum ne fonctionne pas comme je l’ai vu fonctionner avant. Pour l’instant je dis que cela ne fonctionne pas encore. Je m’interroge et je me demande si c’est de ma faute, si c’est la faute des gens, des managers… Pourquoi cette recette de cuisine ne semble-t-elle pas fonctionner pour l’instant ?
Parce que justement ce n’est pas une recette.
Je pense maintenant que Scrum donne un cadre et des pratiques simples. En modifiant ce que faisait l’équipe auparavant, le premier effet est de voire surgir les problèmes que nous n’avions pas identifié. Merci à Scrum. Ensuite je pense que bien que la recette soit définie, je dois m’autoriser à adapter une partie de Scrum à la vraie vie, ce que je fais. En faisant cela, j’ai bien conscience de prendre le risque de rendre les choses encore plus terribles… ce sera la faute de Scrum à la fin non ?
Alors j’ai regardé mon environnement : les équipes, le produit, les managers. Et c’est là qu’il faut travailler, redoubler d’efforts pour que la mise en place de Scrum ne soit pas partielle mais complète. Expliquer, rassurer, accompagner, coacher, écouter, parler, dessiner, dialoguer, diriger… mais ne pas faire du Scrum light.
Je l’ai dit au départ à un stand-up un matin: il n’y a pas de « on fait un peu de Scrum, il faut s’engager complétement et suivre toutes les pratiques ».
Si vous pensez à Scrum pour gérer votre projet, je vous conseille d’y aller complètement et de ne pas suivre qu’une partie du framework Scrum. Ne prenez pas que le dessert. Prenez l’entrée, le plat de résistance et le dessert. Avant de critiquer un sport, assurez-vous de bien en connaître toutes les règles, de l’avoir pratiqué et d’avoir aussi accepté toutes les contraintes.
Nous en venons maintenant à ce que je dirai devant pas mal de monde en avril : scrum est un pétard qui a deux effets : euphorisant d’une part, explosif d’autre part.
Dans les équipes qui travaillent encore avec des méthodes classiques de développement en cascade, le passage à une méthode Agile est un vrai explosif. Imaginez un chef de projet qui travaille 4 semaines sur une spécification technique. Il écrit noir sur blanc toutes les idées du client. Ensuite il rencontre les développeurs, qui ne sont pas d’accord ou qui objectent une partie du cahier des charges… Il réécrit alors ce cahier… Et ainsi de suite.
Basculez ce projet à Scrum et la vie sera plus rose, le client sera impliqué et acteur de ses décisions. Nous livrerons moins mais mieux et plus souvent…. Scrum dans ce cas dynamite un peu l’organisation. Les cycles sont plus courts, la vélocité de production augmente et la satisfaction des clients augmente… C’est le premier effet Scrum.
Dans une équipe complètement déstructurée, chaotique, qui travaille dans l’urgence avec la méthode LaRACHE, la valeur de chacun est estimée sur le temps qu’il passe à réaliser son travail. Souvent le principe est de répondre aux demandes du client afin de s’assurer que celui-ci soit satisfait.
Je pense dans ce cas que Scrum apporte un effet apaisant en structurant le dialogue entre les clients externes (les chickens) et les chefs de projets (les pigs).
Dans une équipe chaotique pour ne pas utiliser un autre mot, le client peut venir voir le développeur et demander une modification au nom du principe édicté par une personne qui n’a jamais codé : « le client est roi ».
Ce principe consomme beaucoup d’énergie, produit de la valeur sur le court terme mais n’est pas viable à terme. Imaginez une équipe de foot où les spectateurs pourraient venir sur le terrain pour expliquer au défenseur comment jouer…
L’apport de Scrum dans ce type d’équipe est donc une structuration relativement légère qui permet un recadrage en douceur.
Regardons un peu plus loin : au delà de Scrum, honnêtement je n’imagine pas travailler, diriger une équipe ou même demain une entreprise sans au moins réfléchir aux pratiques, aux valeurs et aux techniques de cette méthode. Et parce que c’est une méthode simple, je me dis qu’il n’y pas de coûts excessifs à l’utilisier.
Il reste cependant important d’intégrer des pratiques industrielles et des pratiques XP mais je pense que cela fait maintenant partie de nos habitudes. Il faut encore attendre et laisser mûrir Scrum.
Pour terminer, imaginez que vous êtes skipper, que je vous confie la mission de traverser l’Atlantique en bateau. Pour cela, pensez comment cela se passerait dans le cadre d’un projet au forfait classique puis ensuite sous la forme d’un projet Agile utilisant Scrum…
Moi je dis que le bonhomme qui chaque jour corrige son cap fait de l’itération car il sait qu’il n’y a pas qu’un seul cap pour traverser l’atlantique. Sa carte marine est son burndown-chart : il a dessiné la route idéale avant de partir, et il reporte chaque jour le trajet réalisé afin de savoir le « reste à faire »…
Sur ce, bonne journée.
Références:
Hervé Lourdin OCTO Technologies
http://blog.octo.com/index.php/2009/02/05/233-la-faute-a-scrum
Martin Fowler, sur XP et Scrum
http://martinfowler.com/bliki/FlaccidScrum.html
James Shore
Scrum met en avant des problèmes existants, attention à sa fausse simplicité
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
Le Chaos et l’ordre, Scrum vient déplacer votre ecosystème (merci à Gabriel Kastenbaum)
http://www.noop.nl/2009/02/the-decline-and-fall-of-agilists.html
Scrum ou XP ? Scrum ET XP
Guillaume Bodet, Xebia
http://blog.xebia.fr/2008/01/10/scrum-ou-xp-scrum-et-xp/
Pourquoi les projets Agile ne peuvent pas être vraiment menés au forfait
http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-forfait/
