Le French Scrum User Group organisait vendredi 24 Juin une soirée “DevOps, Scrum et Kanban” dans les locaux du Centre de Conférences Microsoft à Issy-Les-Moulineaux. Je profite de ce billet pour partager avec vous mes retours sur les conférences présentées à cette occasion.
Cette session comprenait les sujets suivants :
- Introduction à Kanban, par Laurent Morisseau
- Keynote “Devops & Kanban : Getting to one button deploy using Kanban“, par Dominica DeGrandis, associée chez David J Anderson & Associates
- “Scrum & Kanban, tirer le meilleur des deux“, par Antoine Vernois et Fabrice Aimetti
Introduction à Kanban
Cette présentation, sous titrée “Une démarche Kanban pour des enjeux Lean” a été l’occasion de rappeler les fondamentaux de Kanban en y apportant un éclairage issus de l’expérience de Laurent Morisesau sur différents projets (notamment migration). Les thèmes abordés tournent autour :
- pourquoi utiliser Kanban ?
- enjeux de la démarche Lean (optimisation du flux de production)
- principes Kanban
- présentation de la démarche Lean : 1. identifier la valeur
- identifier la chaîne de valeur
- créer un flux continu pièce à pièce
- établir un flux tiré
- rechercher la perfection
J’ai surtout retenu de cette intervention les messages suivants :
- il faut toujours se baser sur le processus réel, même s’il n’est pas parfait, en respectant les rôles et responsabilités existants.
- importance de la notion de flux tiré, c’est à dire la capacité de production calée en fonction du débit du haut de la chaîne, illustré notamment par les maximes suivantes : - on ne construit pas de fonctionnalités dont personne n’a besoin maintenant
- on n’écrit pas de spécification que l’on ne peut pas développer
- on ne code pas ce que l’on ne sait pas tester
- on ne teste pas plus de code que ce que l’on peut déployer
- on ne déploie pas de code qui ne sera pas utilisé
- démarche d’amélioration continue par petit pas, qui s’appuie sur : - amélioration des flux : cf. théorie des contraintes
- rendre le système prédictible : cf. méthode 6 Sigma
- réduire les limites du tableau Kanban : cf. muda de Lean
- existence de 2 types de limites : - limites supérieures : les limites classiques Kanban, au sens capacité maximum de prise en charge pour un état donné
- limites inférieures, utilisées comme signaux déclencheur d’une action de planification “juste à temps”
- nécessité de mettre en place et de suivre des indicateurs, qui viendront alimenter la réflexion
- importance d’une démarche pragmatique et collaborative : il ne faut pas s’interdire de tester les propositions de l’équipe.
Devops & Kanban : Getting to one button deploy using Kanban
Dominica a présenté à cette occasion son propre retour d’expérience au sein de Corbis, où elle a occupé un poste de responsable des déploiements (intégré à l’équipe de développement). Elle a travaillé à cette occasion sur un certain nombre de problématiques tournant autour de la durée des builds applicatifs, de la disponibilité des environnements et des déploiements et nous a expliqué en quoi l’utilisation de Kanban avait permis aux équipes d’améliorer leurs processus de travail. Au final les équipes ont gagné en compétence, en tranquillité et ont pu se concentrer sur les aspects essentiels de leur métier au lieu de passer leur temps à parer au plus urgent.
La mise en place s’est faite par étapes successives, démarrant assez classiquement par une phase d’identification des objectifs par l’équipe et un état des lieux de l’existant :
Dominica a ensuite fait un rappel des principes Kanban :
Concrètement l’introduction de Kanban a donné lieu à :
- la prise en compte du déploiement dans le tableau de suivi de l’équipe de développement (ajout d’un état “build ready”)
- une analyse du temps de build (identification des différentes tâches, y compris recherche d’anomalies), et un suivi de son évolution
- l’organisation d’une réunion mensuelle d’une durée de 2h, permettant à l’équipe Déploiement de faire un point sur ses pratiques (“the good, the bad, the embarrassing”). Les équipes de développements, ainsi que les clients internes étaient présents. Cette réunion était alimentée notamment par des données financières et la liste des demandes à venir.
- la création d’une ligne de suivi dédiée aux travaux de maintenance sur le tableau Kanban
- la remise en question de la politique de merge initiale, latitude donnée aux équipes afin de mettre aux points et tester de nouvelles approches
- la mise en place d’une fenêtre de “freeze” après chaque mise en production, pendant laquelle production et recette sont parfaitement identiques (aide à la résolution des anomalies constatées en production suite à la MEP)
- l’organisation d’une session de “discussions” après chaque point quotidien, afin de limiter les interruptions en cours de journée et d’encourager les échanges
Les temps forts et phrases à retenir :
- au début était le CDD (“Chaos Driven Development”) …
- “on ne peut pas être bon si on passe tout son temps à éteindre des incendies”
- “transparency = Trust”, “Vulnerability = empathy”, “focus on the system, not the individual”
- “developers incentivized by making change / Ops incentivized by keeping production stable”
- “quality doesn’t happen on 5 hours of sleep”
- “M is for Merge : tolerance for process exploration” concernant la mise au point d’une politique de merge adaptée
- “Improvements were not part of a project plan : they were made as part of a continous improvement policy”.
- “Management must create a way for improvements to occur – they are not free”
- “A focus on cutting costs actually results in higher costs.”
Elle a abordé aussi rapidement l’exemple de Spotify, qui constitue un autre bel exemple de l’utilisation de Kanban :
- 15% du temps des équipes est provisionné sur les travaux d’amélioration continue
- démarche bénéficiant d’un soutien très fort de la part du management au plus haut niveau
- investissement rentable : pas de dette technique identifiée
- une personne de l’équipe est dédiée à la gestion des problèmes et incidents, afin de protéger le reste de l’équipe des perturbations quotidiennes
- pratique du “cross training” au sein de l’équipe : la montée en compétence de l’ensemble de l’équipe est un élément fort
En bonus
- A lire : Death by Meetingpar Patrick Lencioni.
- Pour en savoir plus sur Kanban et DevOps : group Yahoo! KanbanOps
- Suivre Dominica DeGrandis sur Twitter : @dominicad
Scrum & Kanban, tirer le meilleur des deux
Antoine et Fabrice ont présenté une approche mixant les apports de Scrum et Kanban : “ScrumBan”. Ils ont rappelé les points communs et les différences entre ces deux méthodes, avant d’expliquer comment les combiner afin d’en tirer le meilleur parti.
Les temps forts et phrases à retenir :
- Ne soyez pas dogmatiques ! Essayez par vous-même ! Soyez agiles !
- La chose la plus importante n’est pas votre processus,. La chose la plus importante est votre processus pour améliorer votre processus.
Je ne vais pas plagier leur très intéressante présentation, je vais me contenter de vous indiquer que les slides de la présentation sont disponibles sur slideshare . N’hésitez pas à lire Kanban and Scrum – making the most of both, dont il existe une traduction en français que nous devons justement à Claude Aubry, Frédéric Faure, Antoine Vernois & Fabrice Aimetti.
