dimanche 9 février 2014

Kanban en 4 étapes

La méthode Kanban est une méthode simple, visuelle et compréhensible par tous les acteurs d’un processus. Elle est également faiblement intrusive dans l’organisation, contrairement à Scrum qui définit de nouveaux rôles (Product Owner, ScrumMaster), de nouveaux artéfacts (Product et Sprint Backlogs), une cadence figée (Sprints) et des cérémonies dédiées (Planning meeting, Sprint Review, etc…).

Kanban est simple, mais sa mise en œuvre nécessite un peu de méthode et beaucoup d'accompagnement. Je vous propose dans cet article de décrire la démarche que j'ai implémentée sur l'un de mes projets. J'ai volontairement essayer d'en faire ici une démarche générique et non spécifique.

Kanban en 4 étapes


Pour démarrer avec Kanban, pas besoin de big bang. On part du processus existant, et on itère sur la mise en oeuvre, de manière progressive. On se focalise d’abord sur un flux simple ou un sous-flux, en limitant le nombre de nouveaux concepts à implémenter et appréhender. La montée en puissance de Kanban se fera alors par l’enrichissement progressif des concepts mis en oeuvre et par l’élargissement des acteurs impliqués.

Les pré requis

Afin d’impliquer l’ensemble des parties prenantes concernées par le processus global, la mise en œuvre de Kanban est conditionnée par l’identification
  • D’un facilitateur (pilote opérationnel du processus à "kanbaniser", qui peut être externe à l’organisation)
  • D’un sponsor (obligatoirement interne à l’organisation et avec le bon niveau de décision et d’entrainement de l’ensemble des parties prenantes)

Etape 1 : Modéliser le flux existant

La première étape part de la situation réelle. Elle consiste à modéliser le flux existant, en identifiant la typologie des éléments de fabrication (ou classes de services), les étapes du processus au travers desquelles voyage chaque instance d’élément de fabrication, et les acteurs associés à chaque étape.

Il s’agit d’un découpage à la fois horizontal et vertical :
  • horizontal : la typologie des éléments de fabrication ou des services à fournir (évolution fonctionnelle, travaux techniques, correction d'anomalie, …) ainsi que leur complexité, qui doit être réduite à un nombre limité de taille (XS, S, M, L, XL)
  • vertical : les séquences d’activités (ou étapes) nécessaires à la fabrication des éléments ou à la fourniture du service (analyse, spécification, conception, développement, acceptation, production) et les acteurs associés à chaque étape.

Une fois le modèle existant identifié, il est retranscrit sur le tableau Kanban, visible de tous, et permettant de mettre en œuvre le management « visuel » du processus.

Etape 2 : Implémenter ou tuner les concepts

Les concepts associés à Kanban sont en nombre limité et assez simple à appréhender. Il s’agit de :
  • La visualisation du workflow (une étape est représentée par une colonne sur le tableau Kanban)
  • Le transit des éléments de fabrication (représenté sous forme de cartes Kanban avançant de colonne en colonne, et dont la couleur reflète la typologie)
  • Le travail en cours (WIP - Work In Progress), type de colonne regroupant les éléments réellement en cours de fabrication par une équipe dédiée (TEC : travail en cours)
  • Les files d’attente, représentant un stock de travail pour une équipe dédiée, qui vient « tirer » son activité de la finalisation de l’étape amont (TAF : travail à faire)
  • Pour chaque colonne, la détermination des limites (hautes et basses) à ne pas dépasser, c’est-à-dire un nombre maximum ou minimum d’éléments de fabrication transitant au même moment par une même colonne (travail en cours ou files d’attente)


Si le workflow et la typologie d’élément de fabrication varie généralement peu, les limites elles peuvent varier en fonction de l’apprentissage de chaque équipe, de l’amélioration continue ou d’un changement capacitaire.

Chaque limite doit être tunées en permanence :
  • Pour les files d'attente, afin d’éviter de travailler de manière trop anticipée, lisser la charge et limiter le stress d’une pile de tâche qui s’accumule. La limite doit être suffisamment grande pour garder l'équipe occupée, mais suffisamment petite pour éviter que des éléments stagnent trop longtemps avant d'être traités.
  • Pour le travail en cours, principalement pour empêcher le multitâche. En effet, le multitâche est générateur de perte en ligne car passer d’une tâche à une autre implique obligatoirement une certaine inertie et ralentie le débit global. De plus, il est plus bénéfique pour l’équipe de garder le focus et l’attention sur un nombre limité de travaux, et améliorer ainsi les échanges, le travail d'équipe et la diffusion de la connaissance.

Etape 3 : Faire couler le flux

Il est important de noter que les éléments qui transitent au travers des colonnes WIP et files d’attente sont toujours des notions liées au besoin du consommateur final du processus (flux tiré). La granularité des éléments n’est donc pas la tâche (work), mais la fonctionnalité (feature). La feature est bien la finalité et la valeur intrinsèque du processus lui-même.

Pour démarrer le flux, il faut donc instancier les éléments qui vont couler le long des étapes.
  • Pour le BUILD (réalisation d’une application ou d’une évolution majeure), on découpe le périmètre en petit bout (Feature Breakdown Structure OU Story Mapping -> Product Backlog) et on le priorise,
  • Pour le RUN (activité récurrente type correctif ou incident), le flux démarre de manière événementielle, ou avec un stock priorisé (P1, P2, P3).
Le flux coule naturellement grâce aux limites. Une équipe à droite tire son travail à faire de l’équipe à gauche dès que sa limite le lui permet. La priorisation peut être issue de règles de gestion associées à la typologie des éléments de fabrication, où décidées par qui de droit. En effet, bien que Kanban n’implique pas la définition de rôles précis, il est souvent nécessaire de déterminer un « propriétaire du produit » ou un « responsable opérationnel du flux  » qui est à même de décider de la priorisation de l’activité.

Etape 4 : Collaborer et s’améliorer

Cette dernière étape permet de mettre en place quelques pratiques supplémentaires pour faciliter la collaboration et l’amélioration continue, et de reboucler sur l’introduction ou l’adaptation des concepts Kanban au contexte.

Les pratiques complémentaires à Kanban ne sont pas limitées. En voici quelques exemples:
  • Le stand-up meeting
  • La rétrospective
  • Les DoD et DoR
  • L’Emergency Line

Stand-up meeting
Le pilotage est dans le rythme (et vise-versa). Chaque jour, un stand-up est organisé autour du tableau Kanban et réunit les intervenants concernés par les différentes activités du flux. Ce stand-up a pour objectif de piloter le Kabnan, et mettre à jour « l’instantané » de l'état du processus que constitue son tableau.

L’implication de chacun est un élément fondamental de la réussite d’un projet, et le facilitateur Kanban doit s’assurer du bon degré de collaboration et du bon niveau de connaissance de chacun. C’est lui qui s’assure du bon déroulement de la réunion, qui doit être time-boxée.
Durant ce stand-up, on passe en revue l’activité de chaque équipe (via son représentant présent). On débute en partant de la droite du tableau – le besoin final. Pour chaque activité, trois points sont abordés (équivalent des trois questions du Daily Scrum) :
  • L’activité en cours pour chaque équipe
  • L’activité à venir pour chaque équipe, et la priorisation de l’activité
  • Les obstacles à venir, et les actions de prévention
Dans ce processus collaboratif, la notion de limite spécifiée pour chaque colonne est primordiale. Et il est important de considérer que les limites sont des règles de gestion du processus pour lesquelles on ne transige pas.

En effet, les limites constituent le moyen d’identifier très rapidement les problèmes du système, qu’ils soient récurrents ou exceptionnels (blocage, engorgement, sous-activité). 
Lorsqu’une limite est atteinte, la première conséquence est qu’aucun nouvel élément de fabrication ne peut entrer dans la colonne en question. Il y a donc urgence à « désengorger » l'activité, au risque de bloquer l’ensemble du système.
L’atteinte d’une limite doit donc déclencher immédiatement deux choses :
  • La focalisation sur l’activité en risque de surcharge
  • L’affectation prioritaire des ressources sur le déblocage de l’activité

Dans ce cadre, et si cela est possible en fonction des connaissances de chacun ou du mode de contractualisation entre les équipes, les ressources des autres équipes doivent venir en renfort de l’équipe où la limite est atteinte.

Rétrospectives
Pour améliorer le processus et/ou le produit, il est plus bénéfique de « décrocher » de l’activité opérationnelle et prendre un peu de recul. C’est la raison pour laquelle il est préférable d’aborder l’optimisation et l’amélioration continue lors d’ateliers dédiés plutôt que de mixer des réflexions d’amélioration au suivi quotidien de l’activité.
L'outil ici, c'est la rétrospective. Tout comme le stand-up meeting, un maximum de parties prenantes doit participer aux sessions de rétrospective. Typiquement, deux questions y sont évoquées:
  • Qu’est-ce qui fonctionne bien et qu’il faut capitaliser ?
  • Qu’est-ce qui fonctionne moins bien et qu’il faut améliorer ?
Pour être efficace, des décisions concrètes et partagées doivent émerger de chaque rétrospective. Les plans d'actions doivent être réellement menés. 

DoR / DoD : Definition of Ready & Definition of Done
L’entrée d’un élément dans le processus de fabrication, comme le passage d’un élément de fabrication d’une colonne WIP à une colonne de file d’attente doit correspondre à un contrat passé entre l’équipe qui fournit (à gauche) et l’équipe qui consomme (à droite). L’équipe qui fournit doit se focaliser sur la satisfaction de son client (l’équipe que consomme) et livrer son travail conformément à ce qui est attendu.

Les DoR et DoD définissent ces contrats. Ils stipulent que si un élément est présent dans une colonne de type « file d’attente », c’est que cet élément est dans un état correspondant à l’accomplissement par l’équipe amont d’un certain nombre de tâche sur cet élément. 

Une bonne pratique est d’afficher les DoR et DoD en-dessous de chaque colonne « file d’attente ». Ces définitions ne sont pas figées, et peuvent évoluer avec le temps, en augmentant progressivement le niveau d’exigence.

Emergency Line
Le processus doit pouvoir gérer les urgences. Une équipe doit pouvoir travailler sur une urgence, même si sa limite est atteinte.

On peut dès lors insérer une ligne spéciale (emergency line) dans laquelle ne peut circuler qu’un élément en parallèle. Un élément présent dans cette colonne indique à l’équipe que c’est sa priorité du moment.

Attention toutefois bien définir collectivement ce qu’est une urgence, car beaucoup voudront alors considérer que « tout » est urgent afin de voir leur besoin propre avancer plus vite.


mardi 4 février 2014

Agile Mind Map - l'agilité dans un slide

J'ai été confronté récemment à une question existentielle dans l'animation d'une formation sur l'agilité. Comment résumer l'agilité dans un seul slide ?

(voici un bon sujet pour ce tout premier article de mon nouveau blog!).

Partant du principe que seule une image pourrait synthétiser tout ce qu'il y a à dire sur l'agilité, et ayant récemment participé à un Agile Dojo sur les cartes heuristiques (merci AgilBee et Clément Boye), je me suis donc mis à créer mon Mind Map de l'agilité.



J'ai d'abord restreint la figure à 4 branches principales. Ces 4 domaines sont selon moi indissociables pour parler d'agilité :
  • l'ingénierie et les techniques agiles
  • la culture agile
  • l'individu et l'équipe
  • l'organisation et son management
Chaque branche a fait éclore 4 feuilles. L'ensemble me permet d'aborder en un slide tous les points clés de ce passionnant domaine de connaissance. Voici en substance le discours :

1 - L'ingénierie et les techniques agiles
L'agilité, c'est d'abord des pratiques et des outils pour spécifier, valider, piloter, déployer.

User Stories
Le produit vu de l'utilisateur. Construire une application, ce n'est pas livrer du code en enchaînant des tâches, mais produire de la valeur pour un client.  

Test Driven xxx (Development, Requirement)
Par expérience, c'est un pré requis pour un projet agile. Le métier du développeur ne se résume pas à développer. Il doit aussi comprendre en amont et valider en aval. Associer le test à la démarche de spécification et de développement permet cela.

Backlogs, Burdowns & Cie
Pas de projet sans outils d'estimation, de planification et de suivi. L'agilité, c'est pas free style. Les outils associés à l'agilité permettent de piloter finement et...empiriquement les projets.

Continuous Delivery
L'avenir. Un pipeline continu et automatisé depuis le commit du code jusqu'au déploiement en prod.

2 - La culture agile
Sans culture, la technique n'est rien. Intégrer la culture agile est crucial pour que les pratiques soient réellement efficaces.
Collaboration
Elément essentiel du succès pour tout projet (agile ou non). La collaboration doit être optimale au sein de l'équipe, et avec le client. Le rôle du ScrumMaster ou du facilitateur est ici prépondérant.

Flexibilité
Le changement n'est pas une menace. C'est un bienfait, car il rapproche la flèche (le projet) de sa cible (la satisfaction client).

Transparence
Ne rien laisser sous le tapis. Faire émerger les bonnes idées. C'est aussi le domaine du management visuel, du radiateur d'information. L'information affichée en temps réel, pour tout le monde et tout le temps.

Co-création
Comprendre que la relation client/fournisseur de type donneur d'ordres/exécutant est contre productive. Un projet est une entreprise commune. Un logiciel est une co-création.

3 - L'individu et l'équipe
Un responsable qualité d'une grande banque m'a dit un jour : "l'intelligence est dans le processus, pas dans l'individu." Et bien l'agilité, c'est le contraire.

Bienveillance
Il est indispensable que tout le monde puisse se respecter et s'exprimer, notamment lors des rétrospectives. Là encore, la présence d'un facilitateur (ScrumMaster par exemple) est essentiel pour faire passer le message et créer les conditions de l'émergence des idées.

Autonomie
Le chef de projet qui affecte les tâches et relève les compteurs n'est plus (essayer avec une équipe génération Y !). L'objectif est ici le maintien sur le long terme d'une équipe soudée, qui progresse en maturité et prend des décisions pour elle-même.

Courage
Courage pour exprimer ses difficultés. Courage pour remanier le code. Courage pour admettre qu'on a pris une mauvaise direction.

Engagement
Un projet est une entreprise. Une équipe doit s'engager pour son succès, facilitée en cela par le ScrumMaster. Conscience professionnelle et amour du travail bien fait.


4 - L'organisation et son management
Principal levier. Principal frein aussi à l'agilité. Pour être réellement agile, les organisations doivent se transformer, avec de nouveaux processus, de nouveaux rôles, une nouvelle culture, un nouveau management tourné vers l'innovation et la participation.
Cycles courts et flux continus
Produire plus vite de la valeur en limitant gaspillage. Ne pas stocker (BRUF : Big Requirement Up Front), mais spécifier et faire au moment où le besoin émerge (JIT : Just In Time).  

Amélioration continue
Accepter que l'on ne peut pas tout prévoir, qu'il faudra s'adapter, essayer et apprendre pour s'améliorer. Pas de statu quo. 

Facilitation et coaching
Sans support et accompagnement, difficile de lâcher une équipe dans la nature en leur disant "soyez agile". L'agilité doit être accompagnée, sponsorisée. L'organisation, l'équipe et l'individu doivent être écoutés, aidés. L'agilité n'est pas un Big Bang, c'est une roue vertueuse et progressive.

Management 3.0
Créer les conditions de la réussite individuelle et collective. Etre présent. Impliquer et motiver. Donner.


Voilà ma vision à 360 de l'agilité, comme j'essaie de la pratiquer et de la partager au quotidien. Merci d'avance pour votre feedback, pour partager et s'améliorer...