No scrum no win atbx 2015 v1.0

3 869 vues

Publié le

Appliquer Scrum est difficile.
Quelle démarche pour y arriver?

Publié dans : Direction et management
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 869
Sur SlideShare
0
Issues des intégrations
0
Intégrations
556
Actions
Partages
0
Téléchargements
12
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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?
  • No scrum no win atbx 2015 v1.0

    1. 1. NO SCRUM NO WIN? Appliquer Scrum est difficile. Quelle démarche pour y arriver?
    2. 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. 3. Scrum Simple à expliquer, complexe à mettre en œuvre
    4. 4. LA FIN
    5. 5. Le produit, les utilisateurs
    6. 6. La livraison du produit aux utilisateurs
    7. 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. 8. La vision du produit et des utilisateurs
    9. 9. Vision agile Construite par l’organisation Vision agile vue par l’équipe
    10. 10. Laisser des options ouvertes Les concepts Les pratiques Retarder les décisions au dernier bon moment
    11. 11. No Scrum No Win? 4!4! 3 ! 3 !
    12. 12. Choc des cultures • Scrum est simple à comprendre, complexe à mettre en œuvre • Plein d’outils, mais lesquels choisir?
    13. 13. Aligner les contraintes
    14. 14. Organiser l’espace & Travailler ensemble
    15. 15. Product Owner
    16. 16. Saute PO, on a préparé le parachute!
    17. 17. Story Map et MVP (MVP = Minimal Viable Product) Le MVP niveau MUST contient TOUTE la VERSION! MUST?
    18. 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. 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 »
    20. 20. The Development Team
    21. 21. Indicateurs agiles Suivi des Compétences, Maturité des principes, pratiques BurnUp façon Kanban, Temps de cycle Cynefin : probe (sonder)
    22. 22. Scrum Master Super Héros VS Facile’ It’ Acteur
    23. 23. Rétrospectives
    24. 24. Coach
    25. 25. Théorie VS Pratique
    26. 26. Canard en plastique ou pilule magique? Le coach
    27. 27. Lead by example
    28. 28. FIN
    29. 29. Prêts pour vous lancer dans Scrum?
    30. 30. Questions / Réponses Merci à tous – et merci à l’équipe d’orga de l’agile tour!

    ×