Un peu d’histoire et quelques réflexions autour de Scrum. Vous savez sans doute que Scrum en anglais, se traduit par mêlée comme au Rugby. Mais savez-vous pourquoi ? Nous parlerons ensuite de la différence entre les méthodes Lean et les méthodes Agile, et comment il est possible de rejoindre ces deux mondes.
La première apparition du mot Scrum date d’un article de janvier 1986 de douze pages que vous pouvez trouver sur internet : « The New New Product Development Game » publié par Hirotaka Takeuchi et Ikujiro Nonaka. Il n’est pas question dans l’article de définir une méthodologie, simplement de rendre compte d’observations sur le terrain effectuée par les 2 professeurs de l’université Hitotsubashi au Japon.
Scrum et le rugby sont cités afin d’expliquer la différence entre une méthode séquentielle et une méthode itérative par recouvrement. L’image pour expliquer le mieux possible la méthode séquentielle est par exemple le relais 4x100m aux Jeux Olympiques. La réussite de l’équipe dépend de l’enchaînement de séquences d’efforts individuelles. Par analogie avec le développement informatique, les 2 chercheurs expliquent donc qu’il y a un risque lors du passage de témoin et que par ailleurs, pendant qu’une équipe (un coureur) réalise un effort, les autres ne peuvent quasiment rien faire. Cette méthode séquentielle est utilisée depuis le début des années 70. Elle est fortement influencée par les travaux de la NASA et le développement PPP (Phase Program Planning). L’article traite de l’observation de nouvelles pratiques de développement de produits, à aucuns moment il n’est fait mention de développement logiciel, nous sommes en janvier 1986…
Le mot Scrum est utilisé afin d’expliquer comment travaille une équipe de Rugby sur le terrain : l’effort collaboratif est global, l’avancement se fait par petites itérations, les spécialités des joueurs sont mélangées et ils doivent s’accorder pour réussir ensemble dans un intervalle de temps limité. Ceux qui font déjà du Scrum voient où je veux en venir.
Les 2 chercheurs identifient (en 1986) 6 facteurs clés novateurs pour l’époque :
– l’instabilité intrinsèque
– des équipes auto-organisées
– le recouvrement des différentes phases du cycle de développement
– l’apprentissage global et multiple
– le subtil contrôle
– le transfert de la connaisance dans l’organisation
L’instabilité intrinsèque signifie qu’il faut tout d’abord challenger une équipe avec un objectif précis, réaliste mais qui donne un fort challenge à l’équipe. Il s’agit de bousculer le développement en fixant un objectif. Les 2 auteurs citent ainsi que la créativité est décuplée s’il y a un challenge. Il s’agit de pousser l’équipe. Ils citent le cas d’Honda : soit faire un véhicule pour les jeunes, soit faire une voiture pas cher. Finalement les décideurs ont demandé les deux, de faire une voiture pour les jeunes pas chère…
L’importance d’une équipe auto-organisée est surtout novateur pour l’époque. ll s’agit de sortir d’un cadre stricte où l’initiative individuelle n’a pas lieu d’être, où le manager omniscient sait tout et décide tout, pour déléguer à l’équipe plusieurs rôles. Aujourd’hui on voit encore des chefs de projet qui estiment le temps nécessaire pour coder une nouvelle fonction, ce qui est une erreur à mon avis. Il est plus logique de demander à son équipe, à ses développeurs de réaliser une estimation. Tout d’abord un développeur ne donne pas le même engagement si c’est lui qui a estimé la tâche, et par ailleurs le fait de demander à plusieurs personnes permet aussi de s’assurer que l’estimation, et donc la tâche à réaliser, a bien été comprise par le développeur et le chef de projet.
Une équipe auto-organisée met en place des processus de communications que le monde extérieur ne va pas percevoir. Sur un terrain de foot, dans un régiment de commandos, la coordination et la communication sont important pour la bonne réussite du match ou de la mission. A votre avis pourquoi cela devrait être différent parce que nous sommes développeurs ?
Enfin il y a ce que l’on appelle simplement l’esprit d’équipe qui permet de réussir. C’est l’idée qu’un groupe de personnes est plus fort que la somme de chacune des personnes, ce que l’on appelle la vision holistique. On verra tout à l’heure qu’il est important de regarder Scrum dans son ensemble et pas en prenant chacun de ses éléments un par un.
Le recouvrement des différentes phases du cycle de développement est cité par les 2 professeurs comme l’un des premiers éléments novateurs de leurs observations. En fait c’est l’idée d’itération. Ils constatent que des compagnies comme Xerox ou HP qui dès les années 1980 ont fait le choix d’utiliser des itérations, ont obtenu de meilleurs résultats, chiffre à l’appui. Ce qui me frappe c’est de lire ce texte qui a 23 ans et de voir à quel point il est d’actualité aujourd’hui. Fuji-Xerox a raccourci le développement d’une imprimante la FX-3500 de 38 mois à 28 mois en basculant d’une méthode séquentielle classique type waterfall vers une méthode itérative. Cependant il n’y a pas autant d’extrême que ce que l’on voit dans Scrum aujourd’hui. Je m’explique : les auteurs expliquent que le développement conserve ses phases globales qui sont par exemple : prototype, pré-maquette, maquette et commercialisation. Il y a donc bien un investissement initial dans de la recherche, il n’y a pas une mise en marche dès le départ dans l’idée de sortir au bout de deux sprints une version d’un logiciel qui marche… Hé bien oui, c’est peut-être une critique de Scrum, c’est que parfois pour de nouveaux développements on axe trop l’énergie afin de livrer du code rapidement qui répond à la demande du client, sans prendre le recul nécessaire ou le temps de valider de A à Z que la solution sera pérenne. La méthode PUMA de Jean-Pierre Vickoff met en avant justement l’importance de l’itératif tout en conservant une approche en 4 phases. Pour défendre aussi Scrum, je pense qu’il appartient ensuite à chacun selon le contexte de son projet et le type de développement, d’envisager s’il est nécessaire ou non de travailler par phase. Enfin pour être certain d’être bien compris : je pense qu’il est possible de faire du Scrum en intégrant des phases et qu’il faut appliquer ce découpage selon le type de projet et de développement.
L’apprentissage global et multiple est l’une des valeurs de Lean qui rappelle l’importance d’améliorer le niveau de ses équipes en permanence. Hier par exemple, en production j’ai rencontré un souci. C’est grâce à l’aide d’un senior sur le projet que j’ai appris comment résoudre le problème en regardant comment il travaille.
Dans l’article un passage m’a frappé car il a cassé le mythe du Google Friday. En quelques mots, le vendredi chez Google chacun peut consacrer une partie de son temps à faire autre chose que son travail habituel. Voici ce que l’on peut lire dans l’article de Takeuchi et Nonaka page 7 :
[…] Learning at the individual level takes place in a number of ways. 3M, for example, encourages engineers to devote 15% of their company time to pursuing their « dream ».
En clair : dès 1984 une compagnie comme 3M prend conscience qu’en donnant 15% de temps libre passé sur le lieu de travail, les salariés pourraient se consacrer à autre chose que leur mission principale…
Le contrôle subtil est ensuite exposé. Bien qu’une équipe soit autonome, elle est en fait encadrée et pilotée par des règles et des repères qui permettent aux managers de contrôler l’activité. C’est tout simplement les règles du Rugby qui en font un sport subtil plutôt qu’un pugilat, et c’est bien les règles qui assurent, avec la présence d’arbitres, que chaque match se déroule dans une ambiance où l’on respecte son adversaire.
Dans l’article on retrouve là aussi une valeur de Lean, à savoir l’importance du casting d’une équipe. En sélectionnant les bonnes personnes pour constituer une équipe, en essayant d’obtenir un équilibre où chaque personne a sa place, les chances de réussir un projet sont plus grandes. Il est important d’encourager ensuite l’équipe à aller sur le terrain afin de rencontrer les clients, d’utiliser un système d’évaluation global afin de noter non pas l’individu mais le groupe dans son ensemble. Lors d’un match de foot, l’équipe gagne ou perd. On ne parle pas d’individualité. Il faut aussi anticiper et accepter les erreurs, ce qui est plus difficile dans la culture anglo-saxonne qu’au Japon.
Là où un américain se congratule d’avoir lancé son logiciel, un japonais s’inquiète de ce qui n’a pas été parfait et pense comment améliorer la prochaine fois ce qui n’a pas été parfait… Et le français est en RTT, en grève, entrain de prendre un café et se bat avec sa AMOA/MOE/MERD dont lui seul a la connaissance…
Le transfert de connaissance enfin est le dernier point abordé dans l’article. L’osmose est la première source de diffusion des bonnes pratiques. C’est aussi le choix d’une technologie ou d’un produit, qui fait qu’une autre équipe vient vous voir et se demande ce qu’il se passe. La propagation des bonnes pratiques est donc un autre facteur de réussite.
Enfin, l’article se termine par une liste de limitations et de cas limites où il ne sera pas possible d’appliquer ces principes. Je suis tenté de traduire mot à mot ce que j’ai lu afin de ne pas en déformer les propos. Comme tout bon médicament, les 2 auteurs ne recommandent pas ce qu’ils ont observé à tout le monde.
L’approche holistique (l’ensemble est plus fort que la somme de chacun des bonhommes) du développement a cependant un certain nombre de limitations et d’effets secondaires :
– dans un premier temps, ils constatent que cela demande un effort considérable de l’équipe qui se manifeste par un nombre d’heures de travail beaucoup plus important. Cela va à l’encontre de Scrum qui préconise de ne pas épuiser ses équipes, mais on explique là clairement que la mise en place de ces pratiques va s’accompagner d’une surcharge de travail.
– ces principes ne peuvent peut-être pas s’appliquer dans certains domaines qui demandent trop d’innovation ou de recherche comme la chimie ou la biologie.
– il ne s’appliquerait pas à des projets mamouths comme la conquête spatiale où les engagements ne peuvent pas se résoudre au sein d’une équipe, où les décideurs externes doivent faire partie de l’équipe
– ces principes ne s’appliqueraient pas à une organisation dont le développement d’un produit se repose sur la connaissance d’un génie, d’une personne particulièrement forte qui créé le projet, l’invente, et qui donc fonctionne en mode monarchique.
Enfin l’article se termine sur une réflexion de l’importance des managers, des encadrants et de la hiérarchie d’une entreprise. On peut lire par exemple que les top-managers ne doivent pas intervenir dans le développement, qu’ils doivent accepter une erreur en partant plutôt qu’en licenciant une équipe par exemple. Encore un principe Lean au passage.
Conclusion
Cet article de janvier 1986, qui repose sur de l’observation, fait le constat que les entreprises ayant adapté le processus de développement de leurs produits ont obtenu de meilleurs résultats. Tout comme Lean qui a une approche industrielle, cet article ne parle pas de développements logiciels. On parle bien de développement de produits, ce qui a son importance.
Le dernier point qui me semble important, c’est l’importance de regarder Scrum dans son ensemble et pas sur certaines de ses caractéristiques. Si vous prenez le product backlog, c’est une perte de temps que de lister 250 histoires, si vous savez que votre équipe ne fait que 20 histories par développement. Pourtant c’est une perte de temps encore plus grande que celle de ne pas lister du tout par priorité les fonctions à développer.
Les critiques que l’on peut lire sur Scrum en ce moment sont normales, mais elles sont souvent construites sur la démonstration qu’un des points de Scrum ne fonctionne pas.
La vision holistique (cela fait 3 fois que je vous bassine avec ce mot) veut tout simplement dire qu’il faut regarder l’ensemble d’une méthode, qu’il faut lire, l’expérimenter, ne pas tomber dans le piège facile de la critique de la partie commerciale de Scrum, et simplement réfléchir à ce que la méthode peut changer dans votre développement logiciel.
Si demain je me permets de critiquer le foot au nom de la règle du hors-jeu, en ne regardant pas son apport dans le jeu, en n’essayant pas de regarder un match pour apprendre, en restant sur mes positions en pensant qu’il y a mieux, franchement je ne serai pas crédible.
Je vous recommande d’aller lire l’article des 2 chercheurs, car il y a l’essence même de Scrum et des méthodes Agile.
Références:
The New New Product Development Game
Controlled Chaos Software Development
http://www.entreprise-agile.com/ méthode PUMA
Article Wikipedia sur Scrum
Le French Scrum User Group est gratuit, ouvert à tous, dont je fais parti, et vous propose de parler de Scrum et des méthodes Agile sur Paris.
Belle réponse aux récents retours dit « négatifs » sur Scrum, une autre article intéressant sur l’essence de Scrum : http://www.controlchaos.com/download/Emergence%20of%20Essential%20Systems.pdf
Bonjour!
Le fait d’effectuer des itérations rapides, de laisser de l’espace aux équipes pour s’organiser, ou d’affecter des priorités sur une liste de demandes n’est pas spécifique à SCRUM je pense… De plus, l’approche holistique (une très bonne chose en soi) est souvent utilisée dans le milieu SCRUM pour excuser le fait de ne pas atteindre les objectifs industriels d’une entreprise. A mon humble avis.
Bonsoir Nicolas, J’ai lu ton article. C’est extrêmement intéressant et tu m’as aussi fait comprendre que je ne suis pas clair dans mes explications concernant PUMA. En effet, PUMA ne comporte pas 4 phases, mais effectivement le dessin le laisse penser. J’ai donc modifier mon site en conséquence : http://www.entreprise-agile.com/