Le premier Scrum : s'agissait-il d'un Scrum ou d'un Lean ?

par Jeff Sutherland | Août 10, 2008,Aujourd'hui, j'ai reçu par courriel une question sur le Scrum et le Lean, conséquence du récent atelier que j'ai organisé avec Mary Poppendieck au MIT. Le Scrum est-il lié au Lean ? Découvrons-nous de nouvelles choses sur le Scrum ou sur le Lean ? Après avoir réfléchi aux premiers jours de Scrum, je pense que la racine de Scrum et de Lean est la théorie des systèmes adaptatifs complexes. Lorsque nous avons créé Scrum, nous n'avons pas parlé de Lean, mais de systèmes adaptatifs complexes. Je pense que Scrum et le Lean sont des mises en œuvre complémentaires de manières de traiter la réalité physique où les choses ne sont souvent pas linéaires, pas simples et pas prévisibles. Bien sûr, le nom de Scrum vient des professeurs Takeuchi et Nonaka qui ont étudié les équipes de Toyota, Honda, 3M aux États-Unis et d'autres entreprises "lean". De petites équipes interfonctionnelles avec un chef d'équipe facilitateur livrant des prototypes de production à intervalles rapprochés leur ont rappelé le jeu de rugby et la formation Scrummage. Le Scrum est donc "allégé" par définition, mais Takeuchi et Nonaka ne mentionnent jamais le mot "allégé". Ils le considèrent comme un concept occidental qui tente de décrire les pratiques de la chaîne de montage chez Toyota, lesquelles sont en constante évolution et ne constituent pas la valeur fondamentale du Toyota Way. 95% des bénéfices de Toyota sont réalisés par les ingénieurs en chef qui sont ceux qui font Scrum.,Le premier Scrum a mis en œuvre toutes les pratiques que nous connaissons aujourd'hui sous le nom de Scrum, plus toutes les pratiques connues plus tard sous le nom de XP, plus une sauce secrète qui crée des équipes hyperproductives.,La programmation en binôme était utilisée régulièrement avec Jeff McKenna, le consultant principal, qui passait une demi-journée avec chaque développeur lorsqu'il était à Easel une semaine par mois. Après l'une de ces sessions, les développeurs se plaignaient que 75% de leur base de code avaient été jetés dans une frénésie de refactorisation. Les 25% restants faisaient tout plus proprement et élégamment. L'intégration continue était la norme. Je suis toujours étonné que les développeurs pensent qu'ils peuvent programmer des systèmes de production sans cela. (Ils le peuvent, mais ils sont nuls !),Le concept d'" ensemble " était la clé de la conception basée sur les composants. Nous avions des stratégies de test sophistiquées basées sur la conception de puces de silicium.,Nous avions des ingénieurs expérimentés dans l'équipe d'assurance qualité qui automatisaient les tests au niveau des composants. Il s'agissait de tests au niveau des fonctionnalités. Il s'agissait d'un précurseur du test de fumée qui s'exécute sur chaque version dans mes entreprises ultérieures.,Nous avons déployé des versions à utiliser à la fin de chaque sprint mensuel. Chaque version avait suffisamment de fonctionnalités pour que les consultants d'Easel puissent l'utiliser dans le cadre de projets réels.,Mais le plus important, c'est que nous avons capturé l'effet d'"équilibre ponctué", ce que je n'ai pas encore vu une autre équipe Scrum faire. C'est l'un des secrets des équipes hyperproductives. Avant qu'un développeur ne choisisse une tâche lors de la réunion Scrum, l'ensemble de l'équipe discute avec lui pour savoir si cette tâche constituera le chemin le plus rapide vers une fonctionnalité observable de l'utilisation finale. Il s'agissait d'une mise en œuvre sophistiquée de l'"auto-organisation" et du développement "test d'abord".,Après que le premier Scrum a commencé à Easel en 1993, j'ai commencé à parler du processus dans les groupes de discussion Internet en 1994, en particulier comp.object, et en 1995, nous avions un fil bien documenté de mes discussions sur le Scrum dans comp.object, entrelacé avec des commentaires de Bob Martin, Kent Beck et d'autres.,Ainsi, les origines du Scrum sont bien documentées et peuvent être recherchées dans les groupes Google en cherchant dans les archives. Ma page web originale sur Scrum a commencé en 1994 et a été largement consultée sur le web tout au long de 1995 et mise à jour régulièrement jusqu'à la réunion du Manifeste Agile en 2001. En 1995, j'ai invité Ken Schwaber à jeter un coup d'œil à la première équipe Scrum, ce qui m'a amené à collaborer au premier article formel sur Scrum présenté à l'automne de cette année-là à l'OOPSLA. Mike Beedle a été influencé par la description en ligne de Scrum, a mis en œuvre le processus dans sa propre entreprise et a dirigé les efforts visant à faire passer Scrum par les conférences sur les langages de conception de programmation. Cela a fait de Scrum le premier (et le seul) modèle organisationnel formel décrivant un processus Agile complet. Les travaux récents de Jim Coplien montrent que Scrum est faussement simple tout en comprimant un ensemble complexe de modèles organisationnels dans son livre, ",Organizational Patterns in Agile Software Development,En regardant "scrum.txt" vous verrez que Scrum dérive directement des meilleures pratiques dans le développement de nouveaux produits documentées par Takeuchi et Nonaka dans leur article de 1986 de la HBR. L'exemple principal dans l'article était Honda (Toyota n'était pas aussi bien connu à l'époque). Takeuchi n'aborde pas spécifiquement la méthode Lean telle que nous la connaissons aujourd'hui.,En 1995, j'ai fait le commentaire suivant dans le groupe de discussion comp.object :,Les études d'utilisabilité ... nous ont convaincus qu'un seul article dans la littérature décrit l'environnement de développement d'applications rapide obtenu avec Object Studio (la combinaison d'Enfin Smalltalk et de Synchronicity Business Object Modeling and Persistent Object Mapping).,Takeuchi, Hirotaka et Nonaka, Ikujiro. The New Product Development Game. Harvard Business Review, Jan/Feb 1986, pp. 137-146. Takeuchi et Nonaka décrivent la méthodologie Scrum (un terme de Rugby) que nous utilisons en interne. Elle est très différente de tout ce que vous avez vu, car elle ne comporte pas de calendrier de gestion de projet, mais seulement un délai de livraison convenu pour une version. Les entreprises japonaises de l'automobile et de l'électronique l'utilisent pour nous remettre à l'heure dans l'économie mondiale. Avez-vous remarqué que les constructeurs automobiles américains ont connu une année record et qu'ils ont tout de même perdu des parts de marché en 1994 ? Elles prennent le logiciel existant (on ne construit jamais rien à partir de zéro) et de petits projets (2 jours à 2 semaines par personne) sont assignés en tant que SynchSteps. Les SynchSteps sont des impulsions dynamiques générées par rapport à la structure du code existant qui provoquent des mutations (comme dans un organisme biologique).Une équipe de projet est généralement composée de 3 développeurs, 3 personnes chargées de l'assurance qualité, 3 personnes chargées de la documentation et un ou deux utilisateurs. Ils se réunissent tous les jours et se mettent d'accord sur les étapes réalisées et les étapes suivantes. Pour les grands projets, de petites équipes de cette taille construisent des composants et une SCRUM de SCRUM se réunit moins fréquemment pour mettre au point les interfaces entre les composants. Les Developers doivent être moins nombreux dans l'équipe que les personnes chargées de l'assurance qualité et de la documentation, sinon ils génèrent trop de code trop rapidement (fonctionnalité maligne).,Le code évolue comme un système biologique par le biais d'un équilibre ponctué. Vous pouvez lire ce processus tel que modélisé par Denny Hillis sur une machine de connexion dans le livre "Artificial Life". Lorsque suffisamment de mutations se produisent dans plusieurs parties de l'organisme, le système passe à un niveau supérieur de fonctionnalité. Nous disons alors qu'un "paquet" est émis. Il s'agit d'un nouvel élément du système logiciel que nous sommes en train de construire. Par exemple, nous ajoutons des cas d'utilisation au produit Synchronicity à ce moment-là et lorsque le paquet apparaît, un objectif du cycle de lancement est atteint.,Un cycle de lancement, généralement de six mois, est constitué de paquets qui sont vaguement définis comme des objectifs au début du cycle de lancement.,La direction doit relâcher le contrôle de l'équipe et la laisser fonctionner comme une entité auto-organisatrice qui fait croître un système comme une plante. Nous avons constaté que cette approche nous permettait d'obtenir beaucoup plus de fonctionnalités en moins de temps et un produit beaucoup plus cool. Cette approche rationalise les commentaires formulés par Fred Brooks en 1987 dans son article intitulé "There is No Silver Bullet" (Il n'y a pas de solution miracle). Il y affirmait que le seul moyen d'accélérer le développement était de faire pousser un prototype comme une plante. Nous suivons le processus en comparant la vitesse d'assignation des SynchStep (éléments du Sprint Backlog) à la vitesse d'achèvement des SynchStep. Cela permet d'estimer le temps de réalisation du paquet, un peu comme si l'on lançait une fusée, que l'on observait sa trajectoire et que l'on prévoyait le point d'impact. Nous pouvons ajuster le point d'impact en abaissant l'arc (moins de fonctionnalités) ou en ajoutant du carburant (plus de ressources) afin de respecter le calendrier fixé par la direction.,Nous contrôlons régulièrement les progrès par le biais de démonstrations. Rien ne compte pour la direction si ce n'est un code livré qui fonctionne. Des paquets sont régulièrement livrés en tant que composants alpha que les utilisateurs peuvent intégrer dans la version actuelle de Synchronicity. Synchronicity change dynamiquement, menus et tout, afin que les gens puissent essayer la nouvelle fonctionnalité et voir s'ils l'aiment.,Avec SCRUM, les calendriers sont obsolètes (les développeurs l'adorent) et les dates de livraison ne dérapent jamais (la direction l'adore). Si cela semble trop beau pour être vrai, je suppose que c'est le cas, mais la direction reconnaîtra que ce processus offre plus de fonctionnalités et moins de dérapages que tout ce qu'elle a pu voir jusqu'à présent. Nos utilisateurs nous demandent d'allonger le calendrier de livraison des produits parce que nous livrons trop de nouvelles versions avec des mises à jour majeures, trop rapidement (ce qui ne les empêche pas de se plaindre de ne pas avoir obtenu tout ce qu'ils souhaitaient), Nous constatons que le changement de paradigme nécessaire à l'utilisation optimale du processus SCRUM est important. Le paridigme orienté objet nécessite un changement de mode de pensée, mais Scrum exige un changement dans l'organisation et dans la façon dont les gens travaillent et entretiennent des relations les uns avec les autres.,Scrum a été fortement influencée par la théorie des systèmes adaptatifs complexes - les travaux de Peter Senge au MIT, de Christopher Langdon au Sante Fe Institute, et de bien d'autres. Elle a également été influencée par la théorie des contraintes de Goldratt et par l'architecture de subsomption de Rodney Brooks, qui est à la base de la société iRobot, que j'ai aidée à démarrer peu de temps avant le début de Scrum. En commençant au bas de ma page web originale de Scrum, j'ai commenté : "SCRUM est basé sur la théorie de la complexité et les expériences de vie artificielle de Thinking Machines qui utilisent une simulation hautement parallèle de l'évolution des systèmes. Il induit le phénomène connu sous le nom d'"équilibre ponctué" observé dans l'évolution des espèces biologiques.",La raison pour laquelle la première équipe de Scrum appelait les éléments du Sprint Backlog "SyncSteps" était que les développeurs exécutaient le Sprint Backlog dans un ordre soigneusement choisi - l'ordre qui produisait le chemin le plus rapide vers l'apparition de la fonctionnalité suivante du point de vue de l'utilisateur. De la même manière qu'un ordre approprié du Backlog de produit optimise les revenus, un ordre approprié du Backlog de sprint optimise la production de valeur. Il accélère l'évolution des logiciels et peut produire des effets observés dans les systèmes biologiques,L'effet d'"équilibre ponctué" est obtenu chez Toyota grâce à l'ingénierie simultanée basée sur des ensembles. Par exemple, Toyota ne construit pas un radiateur pour une nouvelle voiture. Elle en fabrique six et attend le dernier moment pour choisir le meilleur radiateur à déployer dans la production. Cela ressemble à la compétition entre les espèces biologiques dans un écosystème et l'espèce qui s'adapte le mieux à l'environnement l'emporte. La communauté Scrum n'a pas encore mis en œuvre les stratégies d'ingénierie concurrente basées sur des ensembles qui ont été utilisées par la première équipe Scrum. Chez Google, on m'a demandé pourquoi aucune équipe Scrum ne mettait en œuvre cette stratégie d'ingénierie concurrente basée sur des ensembles. Cela m'a obligé à réfléchir sérieusement au problème. La réponse semble être que les équipes Scrum (1) n'ont pas d'architecture de composants claire et cohérente, (2) les membres de l'équipe n'ont pas une vision globale de l'architecture et de l'état de chaque composant, et (3) les équipes n'ont pas de méthode formelle pour les tests automatisés au niveau des composants.,Cependant, le développement par tests conduit le processus de création de logiciels dans la bonne direction car les tests précoces montrent immédiatement ce qui ne fonctionne pas et permettent le déploiement rapide de stratégies alternatives. La clé est l'évolution du logiciel comme un système biologique basé sur des constructions d'implémentation concurrentes et la survie du plus fort.,Le développement par tests est décrit dans mon article sur Scrum dans une entreprise CMMI de niveau 5 où les tests acceptés pour les fonctionnalités sont décrits en premier, la fonctionnalité est implémentée dans l'ordre de priorité et testée immédiatement. L'ingénierie logicielle systématique a montré que cela permettait de doubler la vitesse et de réduire les défauts de moitié. Le développement piloté par les tests consiste à écrire le code de test avant d'écrire la fonctionnalité et est utile dans les bonnes mains. Il tend à se concentrer sur le niveau de test unitaire et aide au remaniement. Comme l'a souligné Ron Jeffries lors de notre atelier commun au MIT, il laisse ensuite le code parler et l'architecture émerger. Cependant, de nombreux développeurs n'entendent pas le code parler et peuvent générer un désordre où il y a plus de code de test que de code de production et plus de bogues dans le code de test que dans l'application. Je peux voir la forme de la conception dans l'esprit de Ron lorsqu'il travaille sur le code et il est clair qu'il n'est pas un programmeur moyen. Il voit les alternatives de l'espace de conception se déployer au fur et à mesure qu'il code et il a le bon jugement pour prendre le bon chemin vers une architecture flexible et maintenable. Cela me rappelle pourquoi Jim Copien affirme que "l'architecte code" est un modèle d'organisation très important qui fait partie des meilleures pratiques dans les grandes entreprises. (Une analyse réfléchie de la relation entre les systèmes adaptatifs complexes et le Lean montrera que Scrum et le Lean sont tous deux des instanciations de la théorie des systèmes adaptatifs complexes. Un sous-ensemble de la théorie des systèmes adaptatifs complexes est la vie artificielle, un terme inventé par Christopher Langton à l'Institut Sante Fe dans les années 1980. Son article fondateur, qui montre que les organismes simulés sur un ordinateur évoluent plus rapidement lorsqu'ils s'approchent de régions chaotiques, a fortement influencé Scrum. Dans Scrum, nous introduisons le chaos dans le processus de développement et utilisons ensuite un système de contrôle empirique pour inspecter et adapter un système qui évolue rapidement. En essayant de décrire Scrum à JAOO en 2005, j'ai utilisé Lean pour montrer pourquoi Scrum fonctionne. Scrum est un moyen de mettre en œuvre le lean dans la construction de logiciels. En fait, il présente l'avantage que si vous le suivez de près et que vous le mettez bien en œuvre, vous appliquerez la méthode Lean telle qu'elle est décrite par Mary et Tom Poppendieck, sans même comprendre ce qu'est la méthode Lean. Il est difficile pour les gens de comprendre la théorie des systèmes complexes, il est donc difficile de l'utiliser comme facteur de motivation. En 1995, j'ai travaillé avec Hubert Smits et Jean Tabaka à Rallye pour développer un cours destiné aux personnes souhaitant faire passer leur mise en œuvre du Scrum au niveau supérieur, en se basant sur le Lean comme moyen le plus simple d'articuler ce sur quoi vous devez vous concentrer pour optimiser le Scrum. Ken Schwaber affirme qu'il suffit de se concentrer sur le cadre Scrum et la liste des obstacles pour y parvenir. C'est tout à fait exact. Il existe également un document sur le Scrum et le CMMI niveau 5 sur la mise en œuvre du Scrum par Systematic Software Engineering, une mise en œuvre entièrement basée sur le Lean. Au Danemark, la politique nationale consiste à introduire des pratiques d'allègement dans toutes les industries. Par conséquent, il est facile de vendre le Scrum comme un moyen de mettre en œuvre le Lean dans les logiciels,Scrum est un cadre d'inspection et d'adaptation qui est extrêmement simple de par sa conception pour permettre au développeur moyen de la société Ford Motor de commencer en quelques jours. Cependant, il est difficile à mettre en œuvre. Moins de 10% des équipes Scrum dans le monde peuvent passer le test Nokia, principalement parce qu'elles ne peuvent pas livrer un logiciel potentiellement expédiable (entièrement testé) à la fin d'un sprint. Parler aux gens des systèmes adaptatifs complexes ne semble pas les aider aussi bien que de leur parler de Toyota pour leur montrer comment leur mise en œuvre de Scrum est cassée, comment elle est criblée de perturbations dans le flux (muri), de stress partout (mura), et de gaspillage (mudah). L'exemple de Toyota, une entreprise prospère qui élimine systématiquement les muri, les mura et les mudah, leur montre la meilleure façon de corriger leur processus.,Le Lean est donc un outil pédagogique utile parce qu'il découle des lois fondamentales de l'univers qui sont articulées à un niveau théorique par la recherche sur les systèmes adaptatifs complexes. Le Scrum découle des mêmes principes fondamentaux. Le Lean propose des méthodes pratiques pour traiter la cartographie des processus, le coût des retards, les problèmes de file d'attente, les temps de réinitialisation, etc. Tous ces éléments sont utiles pour gérer les contraintes, le débit global du système et d'autres facteurs qui constituaient une préoccupation majeure pour Scrum lorsqu'il s'agissait de traiter le système adaptatif complexe appelé développement de logiciels. | Blog | 10 commentaires