Upgrade to Pro — share decks privately, control downloads, hide ads and more …

De Scrum à Kanban dans un projet transverse

De Scrum à Kanban dans un projet transverse

Johan Barbier

Dans le contexte d'un projet transverse dont les développements aliment plusieurs autres projets organisés en Scrum, nous allons expliquer pourquoi nous avons choisi de passer de Scrum à Kanban, comment nous avons effectué cette transition, et quelles en ont eté les impacts pour nous et pour les projets qui avaient des dépendances avec nos développements.

5dd8b91d96af5a1e33962df41c1a4d20?s=128

Esprit Agile

December 05, 2019
Tweet

Transcript

  1. De SCRUM à KANBAN dans un projet transverse Agile Tour

    2019
  2. Les outils et méthodes agiles

  3. 3 Qu’est-ce que SCRUM ?

  4. 4 Scrum est un cadre de travail agile Comme tout

    cadre de travail agile les maîtres mots sont Amélioration continue grâce aux rétrospective Participation active et dynamique de l’équipe via les daily scrum meetings
  5. 5 Scrum met l’accent sur les itérations Ces itérations sont

    des sprints A chaque fin de sprint correspondent • une livraison du produit • La planification du prochain sprint
  6. 6 Qu’est-ce que KANBAN ?

  7. 7 Kanban est une méthode de travail, un outil Il

    est basé sur l’approche lean : • la recherche de la performance • via l’amélioration continue
  8. 8 Kanban se passe d’itérations On peut prioriser et planifier

    au quotidien Kanban est simple
  9. 9 Un projet transverse

  10. 10 IT-CE I-BP BPCE IT-CE : Informatique de la Caisse

    d’Epargne I-BP : Informatique de la Banque Populaire BPCE : Fusion de la Caisse d’Epargne et de la Banque Populaire
  11. 11 89C3 89C3 signifie BPCE en leet http://www.1337.fr/ Il s’agit

    de l’usine digitale du groupe BPCE https://89c3.com/
  12. 12 Le projet Projet visant à développer les composants et

    bibliothèques RIA-RWD communs aux autres projets de la 89C3. Le projet est au départ géré en Scrum. RIA : Rich Internet Application RWD : Responsive Web Design
  13. 13

  14. 14 Un projet à part La transversalité du projet implique

    quelques spécificités inhabituelles, et des nécessités. Et autant de difficultés, et parfois de frustration de la part des projets dépendants.
  15. 15 Pas de PO mais une myriade d’interlocuteurs avec chacun

    leur roadmap Une attente de fin de sprint souvent frustrante Parfois même impossible
  16. 16 Des besoins variés et pas toujours homogènes Des groomings

    complexes avec des interlocuteurs variés et la nécessité de trouver des points communs
  17. 17 Des priorités différentes selon les projets Et des difficultés

    à gérer ces priorités en une fois en sprint planning
  18. 18 Des urgences et besoins de priorisation rapides Devoir parfois

    prioriser, déprioriser, reprioriser au sein d’un sprint au gré des urgences
  19. 19 Des livraisons régulières et rythmées satisfaisantes Arriver à livrer

    régulièrement à chaque fin de sprint de quoi satisfaire X PO/Projets, et pas NOTRE PO
  20. 20 Tous les projets ont des dépendances chez nous Et

    une pression accrue en fin de sprint car un échec de notre part met en difficulté beaucoup de projets
  21. 21 Des livraisons coûteuses car nous livrions chaque fois une

    stack complète Parfois plusieurs jours, sans compter les montées de version Angular de la stack
  22. 22 Les besoins devenus évidents Au fil des frustrations, petites

    réussites, échecs parfois… Bref, avec l’expérience nous avons isolés des besoins auxquels nous devions répondre.
  23. 23 Communication Il fallait se donner la possibilité de communiquer

    fréquemment avec les équipes projets et les divers acteurs, de les écouter et de les entendre
  24. 24 Réactivité Nous devions trouver le moyen d’être plus réactifs.

    Ne pas nous limiter aux livraisons en fin de sprint. Nous octroyer le droit de changer notre sprint backlog en cours de sprint.
  25. 25 Rythme Il fallait garder un rythme de livraison soutenu.

    Ce qui était parfois difficile si l’on sautait un sprint pour des difficultés rencontrées.
  26. 26 Cohérence Nous devions garder une cohérence dans les développements

    fournis. Chose difficile quand on n’sa pas 1 demandeur, mais X demandeurs. Il faut analyser les demandes, les croiser, et travailler avec tous les demandeurs ensemble si possible.
  27. 27 Anticipation Il fallait parvenir à prendre de la hauteur

    et à anticiper les besoins afin de ne pas toujours travailler en réaction. Ne pas se concentrer que sur notre équipe, mais sur tous les projets.
  28. 28 Le projet avait quelques caractéristiques de projet de TMA

    (Tierce Maintenance Applicative). Kanban était donc séduisant. Mais là où Scrum nous limitait parfois trop, Kanban semblait ne pas le faire assez.
  29. 29 Garder le meilleur des deux mondes ?

  30. 30 « SCRUMBAN »

  31. 31 Notre mélange à succès !

  32. 32 Des points fréquents avec les projets et beaucoup de

    communication Chaque développeur de l’équipe est référent auprès de projets dépendants et font des points réguliers avec eux : remontées des besoins, anomalies, souhaits Le scrum master fait des points similaires avec les scrum masters et PO des projets dépendants Nous nous servons du meetup RIA du groupe pour communiquer sur nos chantiers, nos nouveautés, nos propositions Nous tenons un blog
  33. 33 Un board KANBAN accompagné d’un backlog classique Un DOR

    et un DOD pour les US Des US à mûrir dans le backlog Un Board de fabrication Kanban
  34. 34 Des « Daily » Parce que la communication au

    sein d’une équipe est vitale
  35. 35 Des objectifs « fixés » à la semaine et

    leur revue Cela permet de garder un cap, de maintenir l’intérêt sur le long terme et évite de se noyer dans un développement sans but
  36. 36 Des planifications effectuées au quotidien Tous les jours nous

    revoyons notre board et repriorisons, replanifions selon les besoins des projets, leurs urgences et impératifs Nous gardons toute la souplesse de Kanban Nous livrons notre stack selon les besoins
  37. 37 Des rétrospectives régulières Parce qu’il faut toujours s’améliorer Parce

    que se dire le choses fait avancer Et parce que c’est fun, une rétro !
  38. 38 Des démos Cela fait du bien de voir ce

    qu’on a accompli A nous, ET aux invités
  39. 39 Des groomings (ou raffinements) au besoin {Entre nous} Mais

    aussi avec les développeurs Avec les PO et les Scrum Masters Des projets dépendants
  40. 40 40 MERCI !

  41. @espritagile #atam19 http://atmrs.esprit-agile.com Un grand merci à nos sponsors et

    partenaires
  42. 42 Johan Barbier Directeur technique Groupe HN Agence Sud jbarbier@hn-services.com

    07 85 23 77 56
  43. 43 43 On compte sur vous ! Suivez-nous sur les

    réseaux sociaux