Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile grenoble 2012scrum_kanban on_live_agile_grenoble
Similar to Agile grenoble 2012scrum_kanban on_live_agile_grenoble (20)
Agile grenoble 2012scrum_kanban on_live_agile_grenoble
- 1. Avant la session … Avez-vous un point d’insatisfaction dans votre expérience de la méthode Scrum ? Si oui, notez le sur le post-it à votre disposition ! Scrum à Kanban: 3 retours d’expériences
- 2. Scrum à Kanban: 3 retours d’expériences Elise Vanholsbeeck / Véronique Mosnier / Nicolas Warzagier / 8 Novembre 2012
- 3. Qui sommes-nous? Véronique Elise Nicolas Travel Backend Shopping
- 5. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 6. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 8. Rappels sur Kanban WIP Flux
- 9. Historique des méthodes de développement chez kelkoo Cycle en V Scrum Kanban 2007 2011 Aujourd’hui: 4 équipes en Scrum 3 équipes en Kanban
- 10. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 11. 3 équipes – 3 profils Travel Backend Shopping Effectif 4 développeurs 4 développeurs 7 développeurs 1 QA 1 PO 1 QA 1 PO 0 SM 1 PO 1 SM 1 SM Localisation Grenoble - Londres Grenoble Grenoble - Londres Spécialisation Oui Non Non Équipe dédiée 50% 100% 80% Type de projet Stabilisation Maintenance Amélioration Visibilité du produit Moyenne Basse Haute Rythme des releases 1 semaine 2 semaines 1 semaine Maîtrise de Scrum Débutante Experte Moyenne
- 12. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 13. Les raisons du changement Quels sont les points d’insatisfaction rencontrés avec la méthode Scrum? Partage du Impédiments: Definition of Done Site instable Routine Temps passé en Manque de cérémonials visibilité sur le Envie d’améliorer travail de chacun la productivité
- 14. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 15. La transition Travel Backend Shopping Motivation Toute l’équipe Volonté du manager Toute l’équipe mais Équipe curieuse diluée Préparation Inspiré de shopping Formation sur une journée Aucune Déroulement Big Bang One Shot En douceur ? Impediments Goal du Sprint Sprint + formalisation du flux Sprint Planning
- 16. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 17. Kanban Travel
- 18. Kanban Backend Definition of Done Definition of Done de chaque colonne de chaque colonne WIP WIP WIP
- 19. Kanban Shopping Une colonne Une colonne « pense-bête » surchargée ! Une colonne optionnelle
- 20. Cérémonies d’équipes Travel Backend Shopping Stand-up Demo Retro Poker planning Scenarii / Backlog review N/A Abandonné Régulier Journalier À la demande
- 21. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 22. Conclusion Travel Visualisation du flux Capacité à faire de la QA Incapacité à évaluer les tâches avant
- 23. Conclusion Backend Sortir de la routine Productivité identique Métriques mal exploitées
- 24. Conclusion Shopping Intégration des imprévus au flux Flux formalisé et évolutif Mauvais usage du WIP
- 25. Agenda Rappels Retours d’expériences Qui? Pourquoi? Comment? Quoi? Et maintenant? Bilan général
- 26. Avantages • Visualisation Étapes de développement Bloqueurs Spécialisations • Souplesse Gestion de la priorisation des stories Répartition du temps en réunion
- 27. Inconvénients • Organisation à la demande Travail constant du PO et du Scrum Master Mauvaise compréhension des Stories • Reporting Métriques différentes de Scrum Manque d’engagement de l’équipe • Gestion du WIP difficile
- 28. Ce qui ne change pas • Les rôles et le Product Backlog • La productivité Temps de développement équivalent Temps total passé en réunion • L’effort sur la qualité des User Stories Critères d’acceptance Estimations
- 29. Référence Disponible gratuitement http://www.infoq.com/minibooks/kanban-scrum-minibook Kanban and Scrum: making the most of both Henrik Kniberg & Mattias Skarin
- 30. L’essentiel Formaliser le flux et limiter le WIP Conserver les bonnes pratiques de Scrum Pas de recette miracle – chacun implémente à son rythme et comme il veut
Editor's Notes
- L’objectif de cette présentation est de vous donner un retour d’expérience sur la manière dont 3 équipes de Kelkoo sont passés de Scrum à Kanban.Contrat-Est-ce que je dois faire du Kanban avec mon equipe?Comment faire pour passer de Scrum à Kanban?Quelles sont les bonnes pratiques que je pourrais implémenter chez moi?Ce que vous ne verrez pas-la théorie Kanban & la théorie Scrum
- Qui sommes nous-Véronique: SM travel – SM shopping – 10 ans de conseil & de facilitation chez Capgemini – SM Yahoo – SM kelkoo-Elise: Scrum master. Je travaille chez kelkoo depuis 8 ans et demi. J’ai commencé en tant que développeur. Mon équipe a adopté Scrum il y a 5 ans. Je travaille en kanban depuis 6 mois avec l’équipe Backend.-Nicolas: Dev Shopping -- Développeur au sein de l'équipe frontend depuis Mars 2011, Nicolas s'est initié aux méthodes Scrum & Kanban dans un environnement Agile en constante évolution.
- Qui êtes vous (Faire monter la main a tout le monde)-Qui pratique / a déjà pratiqué Kanban?-Qui pratique / a déjà pratiqué Scrum?
- Scrum: 9 prescriptions: 3 roles (SM – PO - Team) 3 artifacts (PB – SB – Burndown chart) 3 ceremonies (Stand up, Demo–retro, Sprint planning)Impediments: imprevus a gerer pendant le sprint
- VeroKanban: 3 prescriptions visualisezvotre flux, limitezvotre WIP, mesurez et optimisezvotre temps de cycleLe but estque tout le monde se mobilise pour faire sortirunetache le plus rapidement possible du kanban – quetoutes les taches ne restent pas dans le kanbanFLUX: cesont les differentesetapes par lesquellesles tachesdoivent passer pour atteindre la definition du DONEWIP: work in progress: on ne peut pas avoir plus de n tachesdansuneetapes du fluxEn scrum les tachespeuventetrefaites à leurrythme du moment qu’ellessont la a temps pour la demoLes points communs: Les 2 sontempiriques les 2 sont un flux tireLimitation du le flux= S : par iteration, K par le WIPAuto-organisation des équipesUtilisation du management visuelAmélioration continueDécoupage du travail en petite tâche
- Elise Les méthodologies de développement ont changé avec le temps chez Kelkoo. Alexandre Boutin a été impliqué dans l’implémentation de chacune de ces méthodologies chez Kelkoo : cycle en V, Scrum et KanbanPour l’anecdote, c’est lui qui en 2006 a formalisé un process assez lourd sur le cycle en VCe process a néanmoins permis de faire collaborer les différentes de dev, test et prod ensemble.En effet entre chaque étape, un comité était réuni pour savoir si l’on pouvait passer à l’étape d’après comme du dev au test.Chacune des équipes avait ainsi son mot à dire aux différentes étapes.2007 Une méthodologie Agile : SCRUM Les dev, testeur et personnes de la prod se regroupent pour former des équipesScrum et ainsi les projetsmigrent petit à petit à scrum.2011 Une équipe décide de passer en Kanban. Quelques mois plus tard, 2 autres équipes passent en Kanban.Aujourd’hui, nous avons 4 équipes en Scrum, 3 enKanban.
- Backend-EliseAvant le passage à KanbanMulti-compétences, pas de spécialiste dans l’équipeMaintenance : Petites évolutions, maintient essentiellement une bonne stabilité et bonne performance de la plateforme.Peu d’exposition business, la plateforme n’est pas utilisée directement par l’utilisateur. Les impacts sur Kelkoo sont moins immédiats que le Frontend.Très bonne maitrise de scrum, bonne expérience de toute l’équipe.Nico1 dev / 1 archi / 1 QA / 1 SM non dedieSite web en mode Maintenance : site refondu il y a un an et demi – demande de bug fix – de petites evolutions – projet stabiliséAttentes métiers fortes: premiere ligne – partie emergée de l’iceberg – grande réactivité sur des demandes de pub
- Raisons travelEquipe distribuée – besoin de visibilité sur le travail de chacunTrops d’instabilites en prod qui generaient beaucoup d’impedimentsImpossible de mettre de la QA sur le projetRaisons backend :Sortir de la routineEssayer d’améliorer la productivitéRemotiver/ redynamiser (après perte du scrum master)Raisons shopping:Besoin de formalisation du flux – différence de définition du done ; non-conformité au DONETrop de temps passé en cérémonialsEquipe distribuée – besoin de visibilitée sur le travail de chacunContrat de sprint non tenu a cause des impediments et des changements de prioritéDelivrer plus
- ElisePrésentation, jeu et construction du flux, définition des différentes étapesLe lendemain c’est parti.A revoir sur la pres:Timing : Etape par étapeDéroulement : formalisation, …., jolie animation bien visuelle, montrant le déroulementMotivations : Volonté du manager, Equipe sceptique ?Timing: étape par étapeFomalisation du fluxDécorrélation des poker planningFin goal sprint + Allocation de % d’impedimentsPoker planning à la demandeAbandon de scrumC’est une transition non voulue – tres progressiveAu depart, on a eu besoin de formaliser notre flux car equipe distribuée => utilisation du kanbanpadEnsuite on a trouve les sprint planning trop longues et inproductive => séparation du poker planning - + tot que le sprint planning dans la semaineEnsuite on a eu de plus en plus de mal a trouve un goal de sprint a cause des yriades de petites taches => stop les goals de sprintEnsuite on avait beaucoup d’impediement on a alloué des % de sprint pour traiter les impediments => on a simplement pris en compte les gros sujetsEnsuite on a arrete les seances unique de poker planning – elles ont été mise au fil de la semaine au moment de l’arrivee des impedimentsOn a constaté qu’on s’était bien éloigné de scrum – on s’approchait de kanban – on a abandonne scrum et les sprints planning pour mettre en œuvre kanbanToute l’equipe était motivee pour changer le statut actuel et kanban satisfait la majorite
- VeroPres outilsMontrer que les colonnes reflètent les spécialités
- NicoColonne QA surchargee => mauvaise utilisation du WIPColonne tested & committed => formalisation du fluxCode reviewed=> notre flux evolue en fct de nos pratiques
- Ce qui ne change pas pour les 3 :-Daily standupTravel :- Demo/retro régulière- Pas de planification , ni revue storiesBackend :-les démos sont réalisés à la demande-les retros sont régulières, environ tous les 15j ; mais autant que possible après une démo-à la demande aussi les backlogreview + poker planning, quand le PO en ressent le besoin pour sa priorisation, et/ou quand l’équipe va bientôt etre au chomage Shopping :- Plus de démo- Rétro à peu près régulière- Scenarii / poker planning
- vero
- NicoWip sous utilise : on pourrait limite producing pour se mobiliser en pairOn pourrait contraindre la colonne QA pour aider JM a faire la QA quand elle est saturee
- eliseLes 3 équipes ont eu 3 expériences assez différentes du passage à Kanban. Néanmoins, Kanban a apporté un certains nombres d’avantages communs aux 3 équipes. Une tâche qui reste longtemps au même endroit, une colonne où s’accumulent des taches sont d’autant des indicateurs visuels d’un point bloquant.La visualisation des étapes de développement permet de ne pas oublier des taches : ex test fonctionnel, test de performance, documentation. Elle assure également un suivi de l’état de l’avancement de la story. Le travail des personnes spécialistes avec un rôle transversal comme QA ou production est intégré de manière plus fluide en kanban.En kanban, la priorisation des stories est plus souple. Il n’est pas la peine d’attendre la fin d’un sprint pour mettre une priorité haute à une nouvelle story.En kanban, fini la grosse journée de réunion enchainant demo, retro, backlogreview, poker planning et sprint planning. Ces réunions sont effectuées à la demande, plus souvent, et sont moins longues. On peut parler de dose homéopathique.
- VeroniqueOrganisation à la demandeLe PO alimente en permanence le kanban – dispo pour repondre aux question de l’équipesle SM organise les reunions en permanence – contrainte de salle et de dispo des bonnes personnesKanbanWIP / velociteLe WIP et la vélocité ne s’utilise pas de la memefaconmoins de notion de predicatbilite en kanbanLes taches doivent etre petites pour etre comparablePlus complexe de remonter des alertes qu’avec un burndown: c’est l’acumulation de tache qui doit provoquer une alerteUtilisation de graph en nuage de pts complexite / tps de cycleEngagementPas d’engagement de l’équipe sur un goal – pas d’utilisation de la motivation collective a part pour faire sortir une tache rapidement du kanbanPas d’adrenaline de fin de sprintGestion du WIPLes stories n’ont plus vraiement d’instance obligatoire de revueUne story peut etredemarree sans revue
- Nico-> pas vraiment optimisation sur la quantité délivrée