Kanban est avant tout un outil, qui par le biais du management visuel, permet de faire partager une vision commune du travail et d’identifier les points de blocages qui surviennent tout au long d’un processus de création d’un produit. Je vous propose de partager un retour d’expérience sur la mise en place de plusieurs Kanbans pour faire travailler des équipes situées sur différents sites géographiques.
Une plate forme et des équipes distribuées
Tout débute comme toujours par un contexte de travail à optimiser. En l’occurrence une plate forme d’e-commerce assez large pour représenter 40 % du CA de l’entreprise, avec des clients répartis sur tous les continents. À contexte international, organisation distribuée…. comme l’indique le schéma suivant :
On distingue plusieurs activités en parallèle :
- Du change requests, avec la nécessité de travailler sur les éléments les plus attendus tout en donnant de la visibilité aux donneurs d’ordre ;
- Du run et son lot quotidien de correction d’anomalies, sans compter la qualification de ces dernières par le business ;
- Une dernière activité de refonte applicative menée en parallèle, permettant de renouveler la structure de la plate forme.
Pourquoi Kanban ?
La première volonté du client était de faire l’agilité, plus particulièrement du scrum pour améliorer la capacité de l’équipe à :
- Mieux gérer ses plannings ;
- Favoriser le travail en équipe ;
- Être plus à l’écoute des besoins du métier ;
- Améliorer la réactivité pour la correction d’anomalies ;
- Réduire le TTM.
Le point positif a été de découvrir que les équipes étaient structurées par features, avec une orientation verticale et donc une équipe métier dédiée. Cependant, le contexte ne permettait pas de pouvoir mettre en place des équipes scrum efficaces. En effet, les équipes n’étaient pas dédiées aux projets, l’activité de RUN induisait beaucoup de variation dans les vélocités d’équipe (en fonction du nombre d’anomalies identifiées). Après quelques échanges, il a donc été décidé de mettre en place des Kanbans pour suivre l’activité de chaque feature team tout en s’accordant sur la capacité à produire des équipes de développement dédiées à chaque feature team et situées en Inde.
Par ce choix, nous privilégions une chaîne de travail claire entre les différents intervenants en simplifiant au maximum les flux, tout en assurant le moins de variabilité possible dans la capacité de travail. Nous ne parlerons pas dans cet article du projet de refonte qui a été réalisé en SCRUM.
Mise en place du Kanban
La première étape a été donc d’identifier les flux de travail des 2 activités (Correction d’incident, Change Request) pour bâtir les différents Kanbans.
La correction des incidents
Dans le cas de l’activité du RUN, un management visuel classique au mur a été suffisant pour couvrir le besoin. Ce besoin se résumait en la capacité du business à pouvoir qualifier la ou les anomalies tombées durant la nuit. Une matrice de qualification à 3 statuts a donc été mise en place pour permettre aux personnes du Business de qualifier une anomalie selon les 3 critères suivants :
- Hot Fix
- Dans 48 heures
- Moins urgent
Les stand-ups s’articulaient autour du management visuel suivant :
Tous les matins, les responsables fonctionnels de chaque pôle présentaient le résultat de leur qualification aux membres de l’équipe technique présents en France. En fonction du degré d’urgence, des aspects de sécurité, et des compétences, le choix était fait de corriger sur Paris ou de faire réaliser par les équipes thaïlandaise ou indienne.
La mise en place de ce Kanban et du cérémonial associé a eu le mérite de faire se rencontrer le business et les techniques quotidiennement. De plus, la présentation du ticket par le responsable fonctionnel au reste de l’équipe et sa priorisation associée a permis de clarifier les règles d’engagement du travail pour les équipes techniques. Enfin, les règles de distribution des tâches de travail entre Paris, la Thailande et l’Inde ont été également identifiées et plus facilement appliquées.
Les activités de change Request
Dans ce cadre, l’objectif n’était pas tant d’améliorer la réactivité de l’équipe que de limiter les gaspillages en harmonisant les pratiques de travail entre les différentes équipes fonctionnelles.
La première étape consistait donc à identifier le cycle de vie d’une demande de changement, et des anomalies qui leur sont associées. Ce travail a été réalisé en une semaine et a permis notamment d’uniformiser les pratiques de travail au niveau de :
- La qualification des changements de leurs conceptions ;
- Leur priorisation ;
- La stratégie de tests et notamment au niveau des rôles des différents intervenants et des types de tests à réaliser.
Le Kanban suivant a été réalisé suite à l’organisation de plusieurs ateliers entre les responsables fonctionnels et les équipes indiennes. Une stratégie de test a également été rédigée pour clarifier les types de tests à effectuer ainsi que les environnements sur lesquels ils devaient être effectués. La définition de "Done" et de "Ready to dev" a également été rédigée durant ces ateliers.
A la suite du Stand-up du suivi des incidents, le stand-up des équipes fonctionnelles était fait en utilisant le Kanban et également en s’appuyant sur les retours des équipes indiennes. La mise en place des bornes min et max a été dans un premier temps basée sur le nombre d’intervenants, puis ajustée en fonction des observations quotidiennes. Elles permettent de définir le nombre de tickets minimum et maximum dans les colonnes, et d’assurer par ce biais, une fluidité du travail.
La priorisation de chaque ticket permet également d’identifier le travail le plus important à réaliser et ainsi de mettre en place le flux tiré.
La nécessité de définir un nouveau rôle
Puisque pas de SCRUM, pas de scrum master, et vous noterez mon choix de ne pas utiliser le terme Product Owner pour les responsables d’équipe fonctionnelle. Pour assurer le bon déroulement de ces instances et l’appropriation des Kanbans par les équipes, un nouveau rôle était nécessaire : le coordinateur des développements.
Ce dernier est en charge également de la gestion des releases et surtout de l’amélioration des processus. Il s’agit donc d’un rôle fort, qui doit avoir les moyens de prendre des décisions, mais également doit être un facilitateur. Il a la charge de faire émerger des solutions pour le reste de l’équipe (le processus n’est pas une réponse en soi). On attend notamment de lui qu’il :
- Assure la tenue des stand-ups meeting de toutes les équipes ;
- Vérifie l’adéquation entre le management visuel et les données gérées sur un outil ;
- Facilite l’identification des blocages et organise les actions pour passer l’obstacle à la suite du Stand-up ;
- Planifie les releases et les plannings de livraison, et qu’il les communique à l’ensemble de l’équipe ;
- Réalise des points réguliers avec les équipes indiennes pour prendre leurs feedbacks et le diffuser ;
- Documente au « juste nécessaire » le processus de travail, et la stratégie de test ainsi que les règles de base en gestion de configuration ;
- Et enfin qu’il organise et anime les rituels « Agile » : Démos, rétrospectives.
Le choix d’un outil
Comment travailler en mode Kanban avec des équipes situées en Inde ? Au-delà du décalage horaire, c’est avant tout le problème de compatibilité concernant le management visuel.
Bien évidemment, l’utilisation d’un outil est nécessaire. Nous avons profité de la présence du Combo JIRA/GreenHopper pour mettre en place un suivi partagé des informations entre l’Inde, la France et la Thaïlande, dans des cadres simples (pas de scrumban).
L’utilisation d’un outil pour appliquer du kanban n’est pas simplement liée à la situation géographique des équipes. Un outil nous permet également de mesurer les indicateurs essentiels pour le suivi de l’activité. Par exemple, l’ajout d’un flag blocked nous a permis d’identifier rapidement les items pour lesquels des points de blocages apparaissaient. Ces informations associées au traditionnel Lead Time, cycle time ou reaction time nous ont permis de mieux tenir compte de la capacité des équipes à travailler sur des itérations de 15 jours, tant au niveau de la conception, qu’au niveau de l’implémentation.
Dans un premier temps, les Kanbans aux murs ont été maintenus en parallèle de l’activité sous GreenHopper. Avec le temps et la pratique, nous avons adapté le management visuel pour ne suivre au mur que la gestion des obstacles (et leurs plans d’action), ainsi que l’affichage et l’actualisation des indicateurs, le contenu de GreenHopper étant rétroprojeté durant les stand-ups.