Scrum Shu Ha Ri (ScrumDay 2015)
•
2 likes•1,155 views
S'engager sur la voie de l'agilité ce n'est pas "faire de l'agile", c'est être agile, c'est devenir agile. Ce n'est pas une destination, mais un voyage. Scrum est remarquable car il nous accompagne de manière appropriée sur les trois grandes étapes de ce voyage : le Shu, le Ha et le Ri. Le Shu est destiné à l'apprenti : appliquer correctement une méthode fournie. Le Ha est perfectionnement : Adapter ou adopter les pratiques en visant l'amélioration. Atteindre le Ri, c'est être au stade de la maîtrise où l'on innove et crée une façon d'être agile en se guidant sur les valeurs et le sens de l'agilité. En voyageant ensemble, nous allons découvrir ou redécouvrir Scrum sous des jours différents au long de ces trois étapes.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Scrum Shu Ha Ri (ScrumDay 2015)
Similar to Scrum Shu Ha Ri (ScrumDay 2015) (20)
More from Christophe Addinquy
More from Christophe Addinquy (14)
Scrum Shu Ha Ri (ScrumDay 2015)
- 2. Christophe Addinquy Scrum Shu Ha Ri
- 3. MERCI À NOS SPONSORS et partenaires
- 4. Qui suis-je ? Graves antécédents : développeur, analyste, expert UML, chef de projet, design patterns fan-boy, formateur, directeur de projets, etc. Coach agile @ Zenika Computer addict depuis 1980 Agile maniac depuis 2001
- 5. L’agilité, c’est quoi ? Etre agile ≠ Faire de l’agile Etre agile = Devenir agile
- 6. L’agilité : une rupture Modèle Cynefin Pour franchir ce fossé : 3 étapes ✤ Faire = processus ✤ Etre = culture, état d’esprit
- 7. Shu Ha Ri ✤ Shu : Suivre l’exemple (apprendre) ✤ Ha : Se détacher (franchir les limitations) ✤ Ri : Etre fluide (créer, innover)
- 8. Scrum et le voyage agile ✤ Pas un processus, mais un «framework» ✤ Nous accompagner dans notre voyage : la vertu méconnue de Scrum
- 9. Scrum Shu
- 10. Scrum : Suivez le guide ! ✤ Un framework simple ✤ 3 rôles ✤ 2 artefacts (obligatoires) ✤ 4 réunions ✤ 2 cycles
- 11. Le cadre Scrum
- 12. Scrum : les rôles Le Product Owner ✤ Est le maître du backlog ✤ Répond au «quoi» et prend des décisions sur le produit ✤ Valide ce qui est réalisé L’équipe ✤ Est responsable de la réalisation ✤ S’organise elle-même pour mener à bien ses travaux ✤ Possède les compétences nécessaires pour mener à bien sa mission Le Scrum Master ✤ Veille à l’application de Scrum ✤ Protège l’équipe ✤ Est un facilitateur
- 13. La recette du Sprint ✤ Un Scrum Meeting chaque matin pour faire le point et s’organiser pour la journée ✤ Un Sprint Review en fin de Sprint pour montrer ce qui a été réalisé ✤ Une rétrospective pour tirer les leçons de ce qui s’est passé et s’améliorer ✤ Un Planning Meeting en début de Sprint pour s’organiser, fixer l’objectif et le contenu du Sprint
- 14. Ce qui risque d’arriver...
- 15. Le «mini V» « Un Sprint, c’est comme un cycle en V, mais sur 2 ou 3 semaines. »
- 16. Y’a plus qu’à passer les tests... « Le résultat d’une itération doit être déployable en production »
- 17. Scrum, but... « Nous avons adapté Scrum à nos besoins »
- 18. Le mode « rush » L’équipe doit conserver un rythme soutenable d’un bout à l’autre d’un Sprint. Et le conserver d’un Sprint au suivant.
- 19. Stories trop longues ! ✤ Découper finement ... tout en gardant une finalité ! ✤ Une story n’est pas un mini cahier des charges
- 20. Scrum Ha
- 21. Le forfait de base
- 22. Scrum « et » Renforcer à l’intérieur Renforcer à l’extérieur
- 23. Renforcer Scrum à l’intérieur
- 24. Développement guidé par les tests d’acceptation Spécifications Tests d’acceptation ✤ Ecrire les tests fonctionnels AVANT le développement ! ✤ Les cas de tests (exemples) sont une partie de la spécification et la renforce ✤ Ecrire en collaboration pour partager la compréhension
- 25. Analyse causale Programmation neuro-linguistique BPMModèle de Kano Design Thinking Creativity workshop Biais cognitifs Pyramide de Leffingwell Brainstorming Personas Mind maps Analyse contextuelle Use Cases Story boards Archéologie documentaire Gap analysis Exigences non- fonctionnelles Contraintes Questionnement Liste d’attributs Mesures Vision Analyse de risques Liespotting Glossaire Prototypage Story maps Stakeholders assessment Elevator statement Analyse système Product features Cartes CRC Arbre de décision Modèle de traçabilité Business case Usability engineering Analyse quantitative Goal modeling Service-Oriented requirements Integrated requirements engineering Agent- oriented requirements Use Cases maps UML Collaborative reqt. gathering Screenwriting Card sort Spécifications formelles Analyse cognitive Analyse structurée EARS Social modeling Event-oriented reqt. Contextual inquiry Reqt. driven design Problem frames Domain Driven Design HCI analysis Stakeholders taxonomy
- 26. Le pouvoir des jeux ! Des jeux pour apprendre Des jeux pour faire
- 27. Management visuel Visuel Partage La où se passe le travail
- 28. Renforcer Scrum à l’extérieur
- 29. De Scrum à Kanban ✤ Passer de l’itération au flux pour le produit ✤ Garder le rythme des itérations pour l’équipe ✤ Focaliser sur la valeur et le temps de cycle plutôt que sur l’estimation
- 30. Agilifier la définition du produit Partir de l’objectif : le « pourquoi » Prendre en compte toutes les dimensions du produit
- 31. Lean Startup L’agilité étendu au niveau du modèle business
- 32. Du développement à la production avec devops Une question d’outils... Mais d’abord une question de personnes et de collaboration 2 visions du monde complémentaires mais difficiles à concilier
- 33. Scrum Ri
- 34. Briser les règles !
- 35. Inventez votre façon d’être agile ✤ Comprendre ce que Scrum peut nous enseigner ✤ Les règles ne sont plus nécessaires ✤ Vous créez votre façon d’être agile
- 36. Mes repères agiles Feedback Focus Plaisir
- 37. Scrum hors du développement Extreme Manufacturing : Une voiture customisée par client en 7 jours !
- 38. Transformation agile avec Scrum © Laurent Sarrazin / Rupture 21
Editor's Notes
- Quand on parle d’agilité, on évoque souvent Scrum. Cette session a pour but de vous le faire découvrir si vous ne le connaissez pas du tout, et de vous le présenter sous un jour qui vous paraitra (j’espère) original si vous connaissez un peu le sujet !
- On vous a probablement souvent parlé de « faire de l’agile ». mais non on ne fait pas de l’agile ! On fait de pâte à crêpes, mais on ne fait pas de l’agile ! On est « est » agile. Et être agile, c’est « devenir » agile, c’est un chemin et non une destination et c’est que nous allons aborder aujourd’hui. Etre et faire, c’est la différence principale entre un processus classique et l’agilité ! En quoi cette différence importe, car les processus « dits prescriptifs » ont peut-être leur raison d’être ?
- Il montre les différentes situations, les différents contextes qui peuvent caractériser le projet. Les contexte « simples » sont celles où travail peut être entièrement décrit et décomposé de manière prédictive. Dans ce contexte, l’optimisation vient de l’analyse fine des gestes et de l’enchainement des tâches. Il n’y a pas de place pour une réelle réflexion, c’est la place du « management scientifique du travail » et sa déclinaison moderne : les processus prescriptifs du type « cascade ». Les contextes « compliqués » nécessitent de nombreuses décisions, la relation entre cause et effets nécessite une analyse. C’est le domaine des processus itératifs. Les contextes complexes ne présentent pas de relations à priori entre cause et effets. L’expérimentation et l’analyse à postériori sont les outils principaux, c’est le domaine de l’émergence et des méthodes agiles. Le chaos est le domaine des situations imprévisibles. Ce sont les situations de type guérilla et des réponses de type reflexe. L’approche agile couvre les domaines « complexes » et « compliqués ». C’est une approche différente de celle des systèmes « déterministes ». Il faut désapprendre nos anciennes manières pours ‘engager sur la route de l’agilité.
- Une longue route comporte des étapes. Alistair Cockburn a popularisé l’emprunt des 3 étapes d’apprentissage des arts martiaux : ce sont le Shu, le Ha et le Ri. Le Shu est l’apprentissage ; on suit l’exemple en se conformant exactement au modèle. Le Ha est le perfectionnement : on franchit les limites du modèle initial en essayant des choses ; c’est le détachement. Le Ri est le niveau de maîtrise. Se conformer au modèle n’est plu nécessaire, on invente sa propre façon d’être agile, car on est imprégné des valeurs et de la culture agile. Comment Scrum peut-il nous aider ?
- Scrum n’est pas un processus. En fait, comme le dit Tobias Mayer : « Scrum ne nous dit pas comment faire du Scrum » ! Je comparerais plutôt Scrum à un meuble. Un bon meuble : pratique et utile avec des étagères et des tiroirs. Mais ce meuble ne deviendra réellement utile que lorsque nous l’utiliserons pour y ranger nos livres, nos affaires ou nos outils. Sa valeur et son utilité augmenterons au fur et à mesure que nous en faisons bon usage ! Scrum Excelle a nous accompagner dans notre voyage, car nous pouvons le regarder différemment à chaque étape de notre voyage agile. C’est probablement la vertu que j’apprécie le plus dans Scrum et pourtant une des plus méconnues.
- Prenons notre bâton et débutons maintenant notre voyage !
- Débuter avec Scrum c’est suivre ses indications. Rien de plus simple : Cela ne va nous prendre que quelques minutes pour en faire le tour ! Que trouvons-nous à l’intérieur de ce framwork ? 3 rôles, 2 supports obligatoires, 4 réunions et 2 niveaux de rythmicité imbriqués.
- Tout commence par un backlog, sorte de liste à la Prévert de tout ce que nous voulons faire ou avoir dans notre produit. Il est initié par une vision et entretenu et modifié tout au long du projet. A partir de là, nous allons enchainer des cycles de 2 ou 3 semaines, en prélevant du backlog des éléments les plus importants pour constituer le « sprint backlog » de cette période à venir. Le fruit de chacun de ces cycles est un produit qui fonctionne augmenté des fonctionnalités réalisées, car en agile la seule mesure légitime de l’avancement est le logiciel qui fonctionne. Comment s’organise une équipe Scrum pour mener cela à bien ?
- Il y a juste 3 rôles : Le Product Owner est le garant du volet fonctionnel : qu’est-ce qui doit être fait ? Quelles sont les priorités ? Quels critères valident la réalisation des fonctionnalités ? Le Scrum Master est littéralement le « maître du scrum » : c’est à fois le guide de l’équipe sur le chemin de l’agilité, un facilitateur pour créer les conditions d’une bonne collaboration à l’intérieur et à l’extérieur de l’équipe et un pare-feu qui va protéger l’équipe des perturbations indésirables. L’équipe : on ne parle pas d’analyste, d’architecte, ni même de testeur. L’équipe est polyvalente et possède en son sein toutes les compétences nécessaires à l’aboutissement du projet. En pratique, comment cela s’organise-t-il durant les sprint ?
- Le sprint débute avec le planning meeting, un moment pendant lequel l’équipe et le Product Owner fourbissent leur plan d’action pour les 2/3 semaines à venir : quelle quantité de travail pouvons-nous prendre ? En quoi consistent les fonctionnalités à développer ? Comment se découpent-elles en tâches. Pas d’affectation ou Gantt pour séquencer cela : juste une liste d’items découpée en tâches et estimée, et juste pour le Sprint à venir, pas plus. L’équipe se focalise sur la réalisation des fonctionnalités par ordre de priorité. Chaque jour elle fait le point pour se synchroniser, comment les membres de l’équipe peuvent s’entre-aider et s’il y a lieu de modifier le plan d’action. En fin de Sprint, le Sprint review permet de partager largement l’état d’avancement avec toute personne portant un intérêt au projet. Le Sprint se clôt par une rétrospective : le moment où l’équipe regarde la façon dont les choses se sont passer et réfléchit aux actions à mener pour améliorer le fonctionnement de l’équipe. Cela paraît simple. Mais les opportunités de se rater son bel et bien là.
- Il faut du temps et souvent de l’aide pour ne pas tomber dans l’embuches qui se dressent sur notre chemin. Allons-y pour un petit « best of ».
- Faire des cycles de 2 ou 3 semaines est parfois interprété par des mini-phases de 2 ou 3 semaines : quelques jours d’analyse, puis quelques jours de conception, ensuite le développement et les tests à la fin ! Et que se passe-t-il si les tests montrent que l’on s’est raté ? L’analyse et la conception résisteront-elles à la réalité de l’implémentation ? Réaliser un projet en approche agile, c’est fabriquer son produit de manière incrémentale jour après jour au niveau des fonctionnalité et heure après heure au niveau technique, épaulé par une intégration continue qui nous retourne la météo du produit en permanence, au sein même des itérations !
- Certains pensent que Scrum ne concerne que le développement, que les tests c’est autre chose et que cela peut et doit être traité en dehors du Sprint ! C’est faux. Tant que l’on ne l’a pas prouvé via des tests fonctionnels, le produit non testé d’une itération n’est pas déployable ! En fait, on ne saurait considérer ce réalisé comme terminé. Du point de vue de notre avancement : il vaut zéro. Pas 64% , non 0 ! Pire encore : n’ayant prouvé sa viabilité, ce code qui ne vaut rien « encombre » le repository de code. Sa valeur est donc même négative. Scrum n’est pas là pour vous aider à vous donner bonne conscience. Au contraire il augmente le contraste de la situation pour nous aider à y remédier !
- Parfois, je vais en avant-vente et je rencontre des prospects qui ont initié une démarche agile. Assez régulièrement, j’ai droit aux phrases suivantes : « nous avons adapté Scrum à nos besoin ». « nous avons pris le meilleur de différentes approches ». Lorsque j’entend cela, je sais déjà ce que je vais trouver : les anciennes pratiques déguisées avec le vocabulaire agile : La MOA s’appelle désormais Product Owner Le cahier des charges est renommé Backlog Et le planning … bah, il reste le planning, mais il est découpé en itérations ! La réponse agile au processus n’est pas un déguisement du processus, c’est moins de processus et plus de « savoir être ».
- La durée limitée des itérations Scrum est souvent interprété de la part même des équipes comme une mise sous pression permanente pour rentrer aux forceps un maximum de contenu. Hélas la mot « sprint » employé par Scrum n’aide pas tellement à ce niveau ! Certes, parfois la partie cliente ne joue pas le jeu. Mais souvent aussi, c’est l’équipe elle-même qui est son propre bourreau. Elle s’engage sur trop de choses et finit l’itération avec des journées de plus de 12 heures. Ne pas oublier que : Le rythme doit être soutenable d’un bout à l’autre du projet. On fait des journées normales. Ne pas abdiquer sur la discipline et ne pas terminer en bâclant. Etre plus productif c’est aussi (et surtout) se focaliser sur les bonnes choses et ne pas faire ce qui sert peu ou pas.
- La clé de l’approche incrémentale, c’est le découpage fin. On hérite parfois (souvent) de morceaux fonctionnels trop gros, qui même peuvent ne pas rentrer entièrement dans une itération. On a 2 grandes causes à cela : Un manque de pratique : on pense que ce n’est pas possible ou que cela n’a pas de sens de découper plus finement. L’expérience montre que c’est bel et bien possible et permet de bénéficier de feedback plus tôt. Une volonté « d’en faire rentrer plus » qui traduit un manque de confiance dans l’équipe. Si on en demande plus, on en aura plus, n’est-ce pas ? En fait, cela ne marche pas !
- Au-delà du minimum syndical que nous avons décrit, nous avons des axes d’enrichissement. Mais nous avons aussi un forfait de base. Nous allons commencer par ça.
- Pour délivrer régulièrement un logiciel qui fonctionne il faut nécessairement s’adosser à une discipline de développement très rigoureuse. Les pratiques agiles sont généralement empruntées à une autre approche agile : l’extreme programming. Nous en avons déjà évoqué certaines : l’équipe, le rythme soutenable, les petites releases, le planning game. Elles font déjà partie de Scrum. Au niveau du développement : Le TDD : il va de pair avec le simple design et le refactoring Le pair programming : va de pair avec le collective code ownership et les standards de code et l’utilisation des métaphores (peu usité) Les customer tests est un ajout récent. Il n’y a pas qu’XP qui peut nous servir de source d’information, de nombreux ouvrages traitant de Craftmanship peuvent nous aider…
- Au delà de ce forfait de base, vous pouvez poursuivre votre « voyage Ha » pour faire progresser au sein du cadre Scrum (à l’intérieur) ou étendre ce cadre Scrum à l’extérieur ! Voyons cela…
- Et commençons par voir comment étendre à l’intérieur !
- L’un des sujets hype du moment, c’est le développement guidé par les tests fonctionnel, ce que Gojko Adzic appelle la spécification par l’exemple. Ils nous apportent 3 facteurs clés : Les tests d’acceptation sont une partie majeure de la spécification. Ils sont une sorte d’instanciation de ces spécifications et révèlent presque mécaniquement de nombreux oublis et inconsistances ! Les tests d’acceptation sont écrits collaborativement entre développeurs, représentants métiers, etc… On aligne en séance la compréhension des fonctionnalités ! Finalement, on produit aussi des tests, bien sûr.
- En parlant de recueil des besoins : pensez aussi que rien ne vous oblige à vous limiter aux techniques disponibles dans l’univers agile. L’ingénierie des exigences est un domaine dont le corpus de connaissance est riche de plusieurs dizaines d’années de travaux. Nombre de techniques, agiles ou non à la base peuvent vous venir en aide !
- Les techniques d’ingénierie ne sont pas nos seuls leviers. Nous pouvons aussi nous appuyer sur les approches ludiques : Que ce soit pour apprendre et comprendre le pourquoi de nos approches et techniques. Ou pour « faire » : faire émerger le besoin en se projetant dans le futur, prioriser en achetant nos fonctionnalités comme dans un monopoly, etc..
- L’agilité c’est aussi la transparence. Plutôt que d’enfouir l’état du projet dans un ordinateur, l’approche « management visuel » emprunté au Lean vous propose de l’afficher sur les murs, et de créer l’opportunité de conversations ! On n’envoie plus non plus de rapport au management : on les fait venir sur le terrain pour qu’eux aussi comprennent et sentent ce qui se passe en sortant de leur tour d’ivoire.
- Scrum limite implicitement le cadre de l’approche au développement logiciel. Mais il existe des réalités au-delà. Progresser c’est aussi contaminer les activités amont et aval pour ne pas devenir agiles dans un carcan rigide.
- Beaucoup d’équipes font évoluer leur pratique Scrum vers un approche dite « Kanban » : plutôt que penser notre réalisation logicielle en terme de lot de travail pour 2 ou 3 semaines, on l’appréhende sous forme de flux dans lequel on insert une nouvelle demande dès qu’une place se libère. On peut continuer à travailler sur un rythme itératif, bénéfique pour les personnes, tandis que le produit lui évolue de manière réellement continue.
- Penser Agile, c’est penser feedback. Mais notre définition de produit l’est-elle réellement ? Scrum n’intègre pas cette dimension dans sa démarche, ou si peu. Si Scrum parle de prioriser le produit « par la valeur », il faut aussi accepter l’idée que cette valeur peut être une fonction de plusieurs dimensions : bénéfice financier, positionnement marketing, réputation, augmentation du savoir-faire sur un domaine pointu, acquisition de la connaissance du client. Le produit lui-même est souvent vu selon une dimension unique de périmètre. L’adaptabilité que permet l’approche agile permet de faire mieux : d’aligner ce qui est réalisé sur un objectif et d’utiliser le feedback pour déterminer comment s’en rapprocher … ou invalider cet objectif. Bref, subordonner le périmètre au « pourquoi » et non l’inverse !
- On peut même repousser la frontière un cran plus loin : pourquoi ne pas agilifier la définition du business model lui-même ? Lean startup nous propose une approche itérative autour du business model, une démarche d’apprentissage validé où nous cherchons à valider des hypothèses sur nos clients et notre positionnant, afin de poursuivre (persévérer) ou changer de cible (pivoter). Scrum se marrie à Lean Startup pour couvrir un spectre agile allant du business model à la réalisation. Mais au-delà de la réalisation ?
- Les relations entre développement et opérations sont traditionnellement tendues. Chaque équipe a des contraintes opposées et poursuit des objectifs différents. Le mouvement devops cherche à faire travailler ensemble ops et développement afin de mettre en production de manière très fréquentes les évolutions ou les fixes.
- Dernière étape de notre voyage, le Ri est la maitrise.
- John McEnroe, dont on voit le service sur cette photo utilise une technique bien particulière : il est pratiquement dos au cours et ne voir pas son adversaire. Au moment de frapper la balle, il pivote le buste pour lui donner plus de force. Personne d’autre n’utilise une telle technique, et il est inutile de chercher quelqu’un capable de vous l’enseigner. Lorsqu’il a commencé à courir en compétition, le coach de Richard Fosbury a vainement essayé de parfaire sa technique du rouleau. Excédé, il lui a alors proposé de « faire comme il voulait ». C’est ainsi que Fosbury est devenu champion olympique en passant la barre sur le dos. Le point commun entre ces deux sportifs est la maitrise de leur discipline, qui leur a permis de s’affranchir des techniques classiques en n’en gardant que l’essence pour développer leur propre savoir-faire !
- Au niveau « Ri » il n’est plus nécessaire de suivre les règles rigides de Scrum, on crée sa propre façon d’être agile ! Pour Alistair Cockburn, la Scrum « Ri », c’est : Livrer régulièrement S’améliorer continuellement. Laisser l’équipe décider.
- Mes propres repères « Ri », quand je veux observer une équipe agile, sont : Le feedback : l’équipe pense en terme de boucle de feedback, aussi bien pour vérifier son travail que pour s’améliorer et pouvoir corriger le tir rapidement. Cela s’applique à de multiples niveaux et de multiples échelles de temps. Le focus : Un équipe et des équipiers agiles se concentrent sur des fonctionnalités fines, à l’impact chirurgical. Chaque tâche est elle-même définie pour obtenir un incrément sélectif d’une fonctionnalité. Il en va de même pour les nombreuses actions prises en charge par l’équipe. Le plaisir : C’est le carburant qui permet aux équipiers d’être réellement productifs.
- C’est en Scrum, avec des itérations de 7 jours que Joe Justice produit des voitures customisées à ses clients. Et les stand-up incluent les intervenants et sous-traitants répartis sur tout le pays !
- On peut aussi utiliser Scrum pour agilifier les organisations : Une équipe agile et un produit, on peut créer un backlog d’actions pour y arriver et procéder par itération. Une organisation agile est aussi un produit. On peut procéder de même !
- Vous trouverez sur mon blog la présentation, mais aussi un article développant le contenu de cette présentation en suivant « ShuHaRi » sur le nuage de tags.