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.

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
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