Une première expérimentation de STATIK

En lisant l’excellent Kanban from the Inside de Mike Burrows, j’ai découvert un méthode pour introduire Kanban appellée STATIK (Systems Thinking Approach To Introducing Kanban) qui se base principalement sur l’approche systémique. Je me suis donc attelé à l’expérimenter pour lancer une nouvelle équipe en suivant au mieux les différentes étapes du processus et en m’appuyant sur les exemples du livre. Voici ce qu’il s’est passé ! 😉

STATIK, en bref

STATIK signifie littéralement « Introduction à Kanban par une approche de pensée systémique » dont voici les étapes principales comme définies dans Kanban from the Inside :

1. Comprendre les sources d’insatisfaction
2. Analyser la demande et la capacité
3. Modéliser le flux – le « processus d’apprentissage »
4. Découvrir les classes de service
5. Concevoir les systèmes kanban
6. Déployer

Dans mon cas, je n’ai décidé d’aborder que les étapes 1, 2 et 3 lors de mon expérimentation. En effet, les systèmes kanban ont été conçus par la suite lors d’ateliers complémentaires.

Note : Le nombre d’étapes de STATIK dans le cadre des formations officielles de la Lean Kanban University sont au nombre de 8 mais ne diffèrent pas fondamentalement de celles présentées ci-dessus.

1. Comprendre les sources d’insatisfaction

Objectif

L’objectif de cette étape est de partager une même compréhension et de s’accorder sur les insatisfactions de manière à pouvoir entreprendre un changement faisant sens à tous.

L’auteur ajoute que tout changement délibéré nécessite 2 éléments fondamentaux de contexte :

• son scope : les frontières autour du « ce que l’on fait maintenant » au sein desquelles le changement sera focalisé. Le QUOI du changement.
• ses objectifs : une expression de ce que nous espérons atteindre par ce changement, relativement à comment les choses se passent actuellement. Le POURQUOI du changement.

NB : certains pourraient se rappeler d’un certain « Cercle doré » ! 😉

Informations complémentaires

Cette étape nécessite de garder en tête 2 perspectives :

• Des personnes travaillant dans le système : pour avoir leur impression de comment le système est perçu de l’extérieur et bien sûr comprendre le système lui-même.
• Des personnes travaillant à l’extérieur du système : pour avoir leur impression de comment leurs besoins immédiats sont pris en charge et comprendre en quoi le système aide à satisfaire des besoins plus larges.

Dans mon cas, il y avait principalement des personnes travaillant dans le système ce qui réduisait déjà de moitié les perspectives de compréhension du système.

Les 2 questions proposées sont les suivantes :

• De votre perspective personnelle, et de ce que vous percevez des autres à l’intérieur et à l’extérieur (du système), quelles sont les principales sources d’insatisfaction avec le système ? Quels besoins (de qui ?) ne sont pas satisfaits ?
• Quelles sources de variabilité et d’imprédictibilité souligneriez-vous ? Qu’est ce qui vous frustre vous et le système plus largement dans votre tentative de produire des éléments de valeur avec qualité et dans les temps impartis ?

Implémentation

Au vu du temps que j’avais et pour rester le plus simple possible, j’ai décidé d’effectuer un consensus Workshop répondant à la seule question :

Quelles sont vos principales sources d’insatisfaction et de frustration ?

En voici le résultat suite à Dot Voting :

J’ai dans le même temps challengé les participants à exprimer les besoins se cachant derrière ces sources d’insatisfaction, ce qui fut un exercice particulièrement difficile mais révélateur ! Il est important de rester dans le langage de l’insatisfaction et de la frustration (ou du besoin) mais de ne pas décrire de solutions !

L’auteur donnait quelques indications intéressantes suivant les résultats obtenus :

• Si l’insatisfaction concerne la ponctualité, alors il pourrait être pertinent d’adresser les problématiques de communication, de coordination et de qualité.
• Si l’insatisfaction concerne le niveau de staffing, alors il pourrait être pertinent d’adresser les problématiques de charge de travail, priorisation et efficience de système.

Dans mon cas, les 2 sujets semblaient être sources d’insatisfaction ce qui me permettait d’avoir d’ores et déjà une stratégie à mettre en place.

2. Analyser la demande et la capacité

Objectif

L’objectif de cette étape est de rassembler des faits qualitatifs et quantitatifs à propos du processus actuel, ce qui permettra de concevoir les systèmes kanban par la suite.

Instructions

Après avoir défini ensemble les sources d’insatisfaction, il était temps de mettre l’accent sur la compréhension du système actuel : après tout, n’oublions pas que Kanban est définie comme la méthode évolutionnaire du « commencer la où on en est » ! 🙂

Dans un premier temps, j’ai décidé de séparer les participants selon leurs spécialités; 4 groupes se sont alors formés :

• Business,
• AMO,
• IT (développement de nouvelles fonctionnalités)
• et IT (maintenance et support).

J’explique alors aux groupes le déroulement de cet étape :

L’objectif de cette étape est de comprendre comment chacun d’entre-vous fonctionnez pour ainsi assurer une compréhension partagée de votre système actuel. Pour ce faire, nous passerons par des phases distinctes permettant de mieux structurer la restitution. En effet, le résultat attendu est un résumé sur feuille A4 pour chaque phase. Je vais vous distribuer un document dans lequel vous retrouverez une série de questions et des exemples de résultats attendus pour vous aider.

Je vais décrire par la suite chacune des parties en vous partageant les questions et exemples de résultats donnés aux participants.

A) Etude du Quoi

Dans cette phase, on cherche à comprendre ce que chaque groupe produit, comment son travail est organisé, quel est le langage métier utilisé… Ainsi une manière simple est de demander à chacun d’afficher les tâches sur lesquelles il ou elle travaille en ce moment (une idée par Post-it comme à l’habitude). Cela permet ainsi de pouvoir plus facilement avoir une vision des différents types d’éléments transitant au sein de leur activité.

Questions – Analyse quantitative

• Quelle est la taille de nos éléments de travail ? (jours, semaines…)
• A quelle fréquence livrons-nous ?
• Combien d’éléments par livraison ?
• Combien de temps prennent nos livraisons, de bout-en-bout ?
• Avec quelle variabilité ? Avec quelle prédictibilité ?
• Combien d’éléments sont actuellement en cours,  et quel est leur profil d’âge ?
• Combien d’éléments sont prêts à être démarrés, et quel est leur profil d’âge ?
• Les voyez-vous comme votre backlog (en attente d’être pris en charge) ou comme quelque chose de plus flexible (idées, options… desquelles effectuer un choix) ?

Exemple donné

Nous maintenons un certain nombre d’applications récemment développées et travaillons actuellement sur deux de plus.

Au niveau équipe, nous travaillons principalement sur des fonctionnalités (parfois des corrections de bugs) d’environ deux jours de temps de développement, prenant quelques jours en tout.

Nous effectuons des releases en production aussi souvent que possible, typiquement plusieurs fois par semaine, parfois plus d’une par jour.

À un plus haut niveau, nous apprécions penser en termes d’initiatives business; nous pensons de moins en moins en termes de projets.

B) Etude du « A Qui »

Cette partie adresse le destinataire de ce que l’on produit. Cela peut être le processus aval recevant simplement ce qu’on lui envoit mais aussi le client final, car ne l’oublions pas, tout le travail que nous fournissons a pour finalité d’apporter de la valeur au client.

Questions

• A Qui livrez vous ce que vous faites ?
• Qu’en font-ils ?
• Quelle est l’activité en aval ?
• Qui est le client final ?
• Y-a t’il différents clients ?

Exemple donné

Nous effectuons nos propres releases en production et gérons notre propre support.

Nos clients immédiats dans le business utilisent nos systèmes pour effectuer des analyses de risque sur les marchés de l’énergie, pour générer des alertes de trading, et pour produire des rapport aux clients payants la société quotidiennement.

C) Etude du « Pourquoi »

L’étude du QUOI et du A QUI nous emmène naturellement à l’étude du POURQUOI pour donner du sens à ce qui est fait.

Questions

• POURQUOI / EN QUOI ce que vous faites est nécessaire pour l’activité en aval ?
• Pour les clients finaux ?

En regardant des échantillons représentatifs de livrables individuels :

• Quel est l’impact du fait qu’ils soient produits rapidement ou lentement ?
• Est-ce que votre stratégie vous permet de répondre aux besoins suffisamment efficacement ?

Exemple donné

Nos clients payants consomment de l’énergie (électricité, gaz, et pétrole) dans de telles grandes quantités que cela vaut la peine de prévenir leurs risques en en achetant un peu des mois à l’avance ou par des contrats dérivés.

Nos outils les aident à acheter les bonnes quantités au bon moment, donc l’information à temps est une information vitale. Nous travaillons dûr à la fois pour élargir notre couverture du marché (les marchés de l’énergie sont très fragmentés) et pour rester devant notre concurrence en termes de sophistication et de rapidité.

D) Etude des sources d’arrivée

Enfin, pour cette dernière étapes, l’étude se porte sur les sources d’input du processus ce qui permettra de caractériser plus facilement la typologie d’éléments alimentant le flux.

Questions – pour chaque type d’éléments

• Comment arrive t’il ? Est-ce que vous le sollicitez activement, attendez qu’il arrive, ou quelque chose entre les deux – conversation, exploration, ou négociation ?
• A quelle fréquence arrive t’il (autant par jour, par semaine, ou par mois)?
• Arrive t’il avec régularité (ex: par un meeting régulier) ou aléatoirement (ex: par des appels à un helpdesk)?
• Est-ce que le travail arrive en batches ou en pics ? Y a t’il des variations prédictibles saisonnières ?
• Quelles sont vos principales mesures de succès ? Sont-elles bien alignées avec les résultats clients ?

Exemple

Il n’y a pas de pattern régulier d’arrivée du travail.

Nos projets les plus grands ont débuté en accord avec le management; les plus petites choses arrives par le biais de conversations privées ou via notre boite aux lettres d’équipe. Nous avons pour objectif de résoudre les problèmes liés au support sous 24 h (et nous performons très bien par cette mesure); les attentes sur le travail de développement varie selon la taille et le besoin.

Restitution à l’ensemble

Le moment de restitution se devait d’être le temps fort de cette partie d’atelier. En effet, chaque groupe ayant travaillé de son côté, le partager à l’ensemble de l’équipe avait pour but d’éveiller la conscience collective du mode de fonctionnement actuel de leur système.

J’ai ainsi proposé à chaque groupe de venir présenter tour à tour leurs résultats. La limitation à une A4 par partie a permis de structurer leur discours et a grandement simplifié la restitution. 🙂

Après chaque présentation, le reste des participants avait 5 minutes pour « challenger » ce qu’ils avaient entendu : challenger dans le sens questionner pour mieux comprendre et non pas remettre en question ce qui a été énoncé.

Les échanges furent bien plus intéressants que je ne l’espérais : en effet, même si on peut avoir l’impression de savoir comment notre système ou les autres équipes avec lesquelles on interagit fonctionnent, on peut toujours apprendre et être surpris. La compréhension des participants sur leur système semblait alors commencer à s’aligner.

Voici le résultat final :

NB : Oui, comme toujours, le respect des règles n’est pas toujours top, mais on dira que certaines personnes écrivent plus gros que d’autres ! 😛

3. Modéliser le flux de travail

Cette dernière étape de mon expérimentation de STATIK avait pour objectif de modéliser leur flux de travail complet. Pour ce faire, j’ai une nouvelle fois demandé à chaque groupe de travailler séparément et de sketcher leur processus en prêtant une attention particulière aux interfaces afin d’expliciter leur vision des Definition of Ready avec le processus amont et Definition of Done avec le processus aval.

Lorsque cela fut fait, l’étape de restitution pouvait commencer.

J’ai alors proposé d’effectuer un cas fictif de base pour construire chronologiquement leur processus. Nous sommes donc partis de l’idée (à gauche) puis au fur et à mesure, je demandais ce qui venait ensuite. Très rapidement, les participants se sont regroupés devant le Sticky Wall et se sont organisés pour construire ensemble leur processus. Cela a à peine duré 5 mn.

Ce fut un exemple flagrant de l’efficacité de la visualisation et des Post-it ! 🙂

Mais aussi, de l’inutilité de ma présence ! 😛

Voici le résultat final obtenu :

Note : Le processus apparaît un peu désordonné, je pense que j’insisterais plus sur les règles de visualisation la prochaine fois pour obtenir un résultat plus net avec les étapes, les Definition of Ready et Definition of Done.

Conclusion

J’ai trouvé cette première expérimentation de STATIK plutôt enrichissante pour ma part. En effet, je trouve que cela a véritablement permis aux participants de se poser pour comprendre la manière dont ils travaillent aujourd’hui au lieu de tout de suite prendre des actions pour changer. Je garde néanmoins un regard un petit peu mitigé sur le ratio temps passé par rapport au résultat obtenu : est-ce que la conscience collective du système actuel a véritablement augmenté ? Est-ce qu’elle va permettre de plus facilement cibler des actions d’amélioration ?

Cependant, l’exercice n’en reste pas moins pertinent sur le fond et je n’hésiterais pas à réutiliser STATIK dans mes futurs accompagnements pour en avoir une idée plus avisée.

Note : La mise en oeuvre décrite dans cet article n’était que le fruit de mon interprétation du livre, je serais curieux de voir comment d’autres ont pu faire et les résultats qu’ils ont obtenus.