No scrum no win atbx 2015 v1.0
•Download as PPTX, PDF•
1 like•6,916 views
Appliquer Scrum est difficile. Quelle démarche pour y arriver?
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to No scrum no win atbx 2015 v1.0
Similar to No scrum no win atbx 2015 v1.0 (20)
No scrum no win atbx 2015 v1.0
- 1. NO SCRUM NO WIN? Appliquer Scrum est difficile. Quelle démarche pour y arriver?
- 2. INTRO Olivier Picaud Scrum Developer et/ou Scrum Master @opicaud1 Olivier Patou Coach Agile, Formateur Scrum et Kanban @olivierpatou No Scrum No Win Avec A la recherche d’un Mindset Agile pour traquer nos anti-patterns dans la mise en œuvre de Scrum
- 3. Scrum Simple à expliquer, complexe à mettre en œuvre
- 4. LA FIN
- 5. Le produit, les utilisateurs
- 6. La livraison du produit aux utilisateurs
- 7. Tests, Environnements, gestion de conf… PROD Recette Qualification SCM Intégration SCM Master SprintN US1.1 US2.5 Defecta Defectb GO PROD Defecte KO Defectk US 3.4
- 8. La vision du produit et des utilisateurs
- 9. Vision agile Construite par l’organisation Vision agile vue par l’équipe
- 10. Laisser des options ouvertes Les concepts Les pratiques Retarder les décisions au dernier bon moment
- 12. Choc des cultures • Scrum est simple à comprendre, complexe à mettre en œuvre • Plein d’outils, mais lesquels choisir?
- 14. Organiser l’espace & Travailler ensemble
- 15. Product Owner
- 16. Saute PO, on a préparé le parachute!
- 17. Story Map et MVP (MVP = Minimal Viable Product) Le MVP niveau MUST contient TOUTE la VERSION! MUST?
- 18. Release plan Plus de place pour ajouter ou retirer des items, ce n’est plus un outil qui nous aide, il devient un cadre qui nous contraint
- 19. User Stories US 1.0 US 1.4 US 1.3 US 1.1 US 1.2 • Independent • Negotiable • Valuable • Estimable • Small • Testable « Nous pensons quantique »
- 21. Indicateurs agiles Suivi des Compétences, Maturité des principes, pratiques BurnUp façon Kanban, Temps de cycle Cynefin : probe (sonder)
- 22. Scrum Master Super Héros VS Facile’ It’ Acteur
- 23. Rétrospectives
- 24. Coach
- 26. Canard en plastique ou pilule magique? Le coach
- 27. Lead by example
- 28. FIN
- 29. Prêts pour vous lancer dans Scrum?
- 30. Questions / Réponses Merci à tous – et merci à l’équipe d’orga de l’agile tour!
Editor's Notes
- OPI Pour commencer il partir de la fin A la fin on offre un service à l’utilisateur La fin donc le début Quel produit on livre? comment on livre aux utilisateurs, comment on fabrique, comment on travaille ensemble
- OPA Produit / utilisateurs LES QUESTIONS QUE SE POSE OPA : Qui sont nos utilisateurs, comment vont-ils utiliser notre système? Bien connaître ses utilisateurs, les processus métiers pour avoir des interactions pertinentes et efficace C’est aussi savoir à quelle fréquence ils sont capable d’accepter (digérer) nos livraisons, quelle cadence convient à l’équipe ET aux utilisateurs. Comment sont-ils organisés ? Doit-on prévoir une phase de recette utilisateur à chaque itération, livrer directement en production? L’organisation, la maturité de l’équipe, du client nous donne des pistes de réflexion. Quelles sont les bonnes questions qui se posent à nous?
- Temps : 6’ OPI A développer C’est donc aussi comment on travaille ensemble, comment teste t on nous développements, comment corrige-t-on, sur quel environnements. Quelles sont les conditions pour que notre produit soit Done à chaque étape? Quels Done avons-nous en fonction du scope(testeurs, env, périmètre, timebox livrée) que nous mettons à disposition? Exemple d’étapes : Comment je livre Installation OPS, A quelle fréquence Qui je livre PO,DEV, Test .. Définition de fini Le comment et le qui peut être séparé Equipe: Pluridisciplinaire? Colocalisée, plusieurs équipes Emergence de l’organisation concrète du projet
- Différents contextes Différentes solutions possibles, différentes complexités… Etre done à chaque US, à la fin du sprint/release choix techniques expliqués avec du fonctionnel : Qui livre le produit, pour qui, pour quoi, permet de répondre à comment on travaille : environnements de déploiement, stratégie de branche, de tests Intégration en continue? Stratégie de test, pas de reliquats en S+1 -------- Exemples de 2 équipes différentes dans le cadre de contextes différents. Ici on mise sur le quoi et le comment 2 solutions : Dépend de la taille de la stack Maturité des équipes Conséquence : un sac de noeuds
- OPA Tous ces éléments constituent la vision du produit, des utilisateurs et donc la vision du projet Loi de Conway Vision Produit VS Vision Projet? Absence de vision Vision connue mais non partagée ou trop tardivement dans le projet, ou à quelques ressources/équipes VS Vision du Produit, des utilisateurs, des objectifs, des moyens de mise en œuvre La vision Produit engage tout le monde , c’est le guide vers l’idéal de notre produit. L’organisation du projet doit être tirée des contraintes du produit et des utilisateurs des attentes du client plutôt qu’un produit fabriqué par une organisation projet qui fabriquera un produit à son image. Commencer au plus juste de l’organisation optimale puis l’amender en fonction de la réalité plutôt que l’inverse Ne être feignent , c’est du travail essentiel pour la réussite du projet Besoin d’avoir cette complexité Conséquences de ne pas en avoir? Exemples : ? Vision Produit VS Vision projet
- OPA Vision de l’orga « lourde » disséminée dans des docs. Identifier les éléments importants et reconstruire VS Vision qui va à l’essentiel et qui s’adapte. VISION DYNAMIQUE
- OPA Parce que la vision bouge, Garder de l’énergie GPS : des virages, de nouveaux paysages, long trajet Equilibre entre vision = temps (cf release plan) qu’elle embrasse On part pour Dublin et on se retrouve à Berlin. C’est super! Les outils concrètement ----------------- La vision doit laisser des options ouvertes et ça matérialise dans un backlog, une roadmap, un release plan Exemple d’un projet multi-applications (client/serveur, tablettes mobiles, BI, selfcare …) Le plan n’offre aucune option, il est une suite de jalons précédé de phases. Le contenu de la version est fixé Le release plan est une suite d’Epics avec des jalons intermédiaires imposés par la direction transverse Le release Plan agile bouge en permanence. Au fur et à mesure que les sprints sont réalisés les épics sont rafinées en US plus fines. Certaines sont ajoutées, certaines sont enlevées. La vision bouge (A3 mis à jour) Roadmap et Release Plan La Story Map et Le Backlog de Sprint Pour se poser les bonnes questions Possibilité de rater un embranchement et de retrouver sa route : prise de recul, relocalisation, …
- Temps : 13’ OPA -> OPI OK pour la vision (c’est déjà du boulot!) Maintenant on va affronter le travail à faire Nos pratiques Ayons une pensée complexe, changeons de perspective pour avoir une vision à 360° des situations et des problèmes que cela pose à nos équipes, essayons, itérons, analysons. Changeons de perspective, plusieurs fois! Il peut exister plusieurs causes à un même problème. Découpons les en petits éléments, traitons les un par un, faisons nos bilans et nous progresserons ensemble. No Scrum, No Win : Individus différents : perspectives différentes Coach <> SM <> Attentes différentes Ne pas voir la même perspective, c’est pas grave, on va les construire petit à petit et les partager.
- OPA /OPI Outillages de l’organisation projet !Agile <> Agile Types d’outils : pratiques, techniques, informatiques Limiter la perte d’énergie Erreurs/pbs : c’est pas grave, mais il faut les corriger vite. L’expérience (et le coach) font gangner du temps. Les erreurs/pbs qui perdurent trop longtemps usent les équipes : fatigue Construire le chemin pour faire mieux Nouvelles itérations et bilans/ nouveaux champs d’application Effort pour ne pas y …? OPI? Pour ou on commence? Plein d’outils, de pratiques, de méthodes, de mots barbares. Les quels choisir? Dans quel contexte? Si on les utilise pas tous est-on agile quand-même? Aurons nous des bénéfices?
- OPI -> OPA -> OPI Aligner les contraintes business, marketing projet, équipe, organisation compétences de l’équipe, taille de l’équipe, durée des itérations vision produit et projet partagée, Intégration d’un nouveau « junior » dans l’équipe : faciliter l’intégration, adaptation des pratiques (ex: tâches plus explicites) Product Owner surchargé, seul face à l’équipe. Découverte de l’agilité qui « bouscule » les habitudes. Sortir de sa zone de confort, en jusqu’à la limite de la zone de risque pour être agile. Rompre avec la routine. Action du Scrum Master ou du Coach qui demande de changer de comportement => Bouscule/agression Être bon élève malgré les contraintes non agiles pour influer sur les choix / tendances de l’organisation Limiter les dépendances avec les autres équipes, les intervenants en dehors de votre équipe. Si vous avez une dépendance extérieure, vous avez un problème! Planifier dans le sprint précédent les développements les échanges nécessaires afin d’avoir toutes les entrées en début de votre sprint, pas pendant. Sinon : attente, blocage et Story !done à la fin
- OPI Organiser l’espace Story Map, Release plan, tableau scrum, impediments, Vision, indicateurs Scrum … Tout le monde travaille ensemble quotidiennement sur le projet : PO/Dev/SM Refacto du mgt visuel : sens de lecture, vision produit, orga projet, indicateurs De la place! PO, SM, Dev, OPS, TechLeads Le coach prend la photo
- Temps : 23’ Ce qu’il doit être, le rôle qu’il doit porter et la réalité. Une personne, avec son passé sa culture, ses habitudes de travail. Seule face à une équipe qui vient vers elle pour l’aider. Décalage des perceptions : l’équipe peut(doit) aider le PO pour la rédaction, le rafinage des US si il manque de temps pour le faire. C’est le rafinage des US. Le devoir ultime du PO sur lequel il doit garder la main est la priorisation des items du Backlog, s’assurer que les items de plus forte importance sont pris en premier. Il doit pouvoir comprendre pourquoi l’équipe lui propose de réaliser des histoires techniques, des Spikes, pourquoi telle histoire doit être priorisée avant les autres de la fonctionnalité. Être aidé n’est pas un déshonneur c’est une nécessité. Pour cela il faut de la confiance en soi et dans l’équipe! C’est un échange permanent sur Prioriser et découper : Epics, User Stories, Technical Stories, Tâches, Impédiments Laisser du mou dans les plans pour accueillir le changement comme un avantage VS subir les changements et tout remettre en cause dans les décisiosns. ce qu’il convient de faire après, avec pour objectif de délivrer le plus de valeur possible en un minimum de temps. Pourquoi 1 seul PO? 1 Produit, 1 Backlog? Plusieurs PO = Plusieurs Visions Différentes priorités, objectifs, versions d’une histoire (déjà qu’on pense quantique!) Beaucoup de travail S’appuie sur le SM pour apprendre les outils, sur toute l’équipe pour faire des histoire Ready To Dev et INVEST,
- La confiance du PO envers l’équipe est indispensable Les développeurs doivent le protéger, le rassurer Le PO à l’écoute de l’équipe. Pour savoir si on peut faire confiance, il n’y a qu’une solution : faire confiance! Le PO aidé par le SM : Outils, démarche, techniques : Story Map, Release Plan Utiliser en laissant du mou sinon vite inutile/obsolète, beaucoup de travail pour tout replanifier Rédiger des US INVEST, 3C…
- Temps : 27’ La Story Map est un super outil pour se focaliser sur le plus important du moment : quelques sprints de visibilité MUST maximum pour construire des fonctionnalités et recueillir du feedback La ligne MUST est le stricte nécessaire pour recueillir du feedback sur le produit, une fonctionnalité du produit. C’est le MVP. Le MVP est un objet en permanente construction. A chaque itération des US sont Done, de nouvelles US de moindre importance sont repriorisées. La Story Map permet de construire un MVP, mais c’est aussi un outil très puissant de gestion du backlog. C’EST LE BACKLOG MVP et Story MAPS permettent de définir un produit minimal viable afin de recueillir du feedback (déjà dit) : Utilisateur (OK on sait) Quelles sont les fonctionnalités Correspondent-elles à mon besoin Comment l’améliorer, que faire ensuite De l’équipe (Mais aussi!) quoi (fonctionnel), comment (on le fabrique), quelle taille (pour l’estimer et le planifier) Anticiper les fonctionnalités pressenties pour les prochains sprints Comment se focaliser sur le MVP? Travail difficile En contrepartie plus de visibilité – d’estimation pour l’équipe Mettre en should ne veut pas dire oublié. Dialogue Travail du ROI : CPX/Valeur-importance
- Symptômes J’ai plus de place sur mon release plan Les post-its sont les un sur les autres Je n’arrives plus à les lire Raison Les itérations sont trop petites (surface au mur) et/ou les post-its sont trop gros Effets nocifs : On perd la vision globale et on ne voit pas apparaître d’objectif pour le sprint On n’ose plus ajouter/déplacer de post-it, la vision se fige Solution Faire des cases plus grosses, utiliser des post-its moins grand PO et US / Backlog Lorsque les histoires utilisateur (US) sont trop complexes, riches en exigences et intégrées telles-quelles dans les sprints Les US ne sont pas done en un Sprint Les démos ne sont pas possibles, car les tests ne peuvent pas être réalisés : manque de stabilité applicative Une Us qui n’est pas « Done » à la fin d’une itération est continuée au sprint suivant. Son périmètre peut être renégocié entre l’équipe et le PO et donner lieu à plusieurs US afin qu’une fraction de la valeur métier soit délivrée dans le sprint.
- Temps : 35’ Un besoin utilisateur : Carte efficace Une description du produit : CA Un élément de planification : Release Plan Un élément de discussion : rafinage Un mécanisme pour reporter les discussions : Story Map et release Plan User Stories, Technical Stories, Defect Stories, Backlog Découpage, rafinage L’importance de la taille des US
- Temps : 41’ Le rôle le proche du CP en agile est le PO. Le SM facilite, est le garant de la méthode, il coach sont équipe et apporte son aide. Il n’anime que la rétrospective (parfois une partie du bilan : indicateurs/vélocité). Toutes les réunions sauf la rétro apprtiennent à l’équipe de développement et au PO. Le SM est juste là pour faciliter, aider, favoriser l’usage de nouvelles pratiques etc… Pas un tech Leader Pas un team Leader Pas un manager (sauf du process Scrum;-) Pas Project Manger / CP Maitre de la méthode Bien entrainé Il pense agile ! vu comme un chef de Projet Il rend compte de l’avancement du projet à la place du PO Il est tenu pour responsable des avancées de l’équipe Il est conforté dans une posture interventionniste plus que facilitatrice Il mène toutes les réunions Il distribue le temps de parole à la mêlée Même si c’est fait avec bienveillance, cela a pour effet : Bride la parole, sentiment de confort pour chacun, les lignes sont bien marquées et connues. Le résultat sera probablement bon mais le courage, l’innovation, la spontanéité, la prise de risque (calculée) serons bridés à ceux estampillés « Expert » VS créer de la confiance, du partage, de la communication, de l’émulation collective. Le résultat semble moins « déterministe » mais c’est pourtant terriblement plus efficace. Créer une équipe, une identité, une culture commune est essentiel, cela réduit le temps nécessaire pour se comprendre, permet d’anticiper les actions des autres membres de l’équipe, diminue le besoin d’outiller. Plus une équipe devient mature, moins elle a besoins d’outils pour gérer le processus, les détails, et plus elle s’outille pour industrialiser ses pratiques, ses déploiements, mesurer les écarts et résoudre les problèmes.
- Apprendre à les animer, les jouer On peut varier, on doit varier les points de vues, les formats pour qu’elles restent vivantes, pour changer d’angle Ne pas croire que tout se dit en rétrospective Exercice collectif ou ne ressortent que les choses déjà partagées, implicitement ou explicitement Ne permet pas (toujours) d’identifier les plus gros obstacles Nécessité de les préparer tout au long du sprint en consolidant la mémoire collective et individuelle Entretiens « One and One » pour aller chercher un nouvel éclairage sur le projet, prendre du recul et connaitre les attentes individuelles Avoir des retours critiques sur sa propre action Entretien = échanges, questions réponses dans les 2 sens. Permet de compléter la vision que l’on a de l’équipe et la vision que l’équipe a de sa propre action de SM, de coach. Le seul moyen selon Dave Snowden pour faire vivre à l’équilibre un système Chaotique essayer de nouvelle pratiques (émergence) et validation par retour d’expérience, mesures etc..
- Temps : 43’
- OPI : Trop théorique Valeurs et principes agiles Appliquer les Règles Scrum, mais pourquoi je dois faire ça? La rétro est-elle obligatoire? Une mêlée tous les jours en plus des fois elle dure 25 minutes! Relever les indicateurs tous les jours, ca ne sert à rien VS Faire à la place du SM et du PO Perte de confiance en soi Perte de confiance dans le coach Outiller l’équipe, organiser l’espace, faire monter en compétences Parfois au début le coach doit faire à la place et avec le PO, le SM. Il est dans l’éqiupe pour binômer, éviter les premiers pièges faciles, accélérer la prise de marque. Il impose alors son style . Il doit aussi préparer sa sorti de l’équipe pour que chacun se retrouve dans les marques qu’il a posé, les outils mis en place. Il doit donc transmettre ses sources documentaires, former, donner de l’autonomie et faire grandir. Alors il peut se retirer de plus en plus et offrir une aide pontuelle, montrer d’autres voies intéressantes ex: devOps
- Assez déroutant, la plus value du coach est simplement d’être présent Il n’est pas toujours nécessaire d’intervenir Faire grandir chacun : travail sur le questionnement ( Le coach ne sait pas tout, ne voit pas tout Les attentes de l’équipe : Une prescription VS La mission du coach Faire grandir, donner le l’autonomie, monter en compétences, changer les comportements VS la réalité Aller vite et éviter les pièges connus
- Temps : 48’ Donner l’exemple, oui mais attention, tous nos comportements sont sujet d’exemple! Niveler par le pire, ou par le meilleur?