14h – 14h25 Salle 1 (Le Belvédère)
Petit board deviendra grand Matti Schneider
#AgileFrance @matti_sg
1 Présenté le 23 mai 2014 à Paris à AgileFrance.
CC-BY-NC-SA You can quote, reuse and remix this presentation as long as you cite me, but you may not make money out of it, including from training classes. If you include parts of this work in yours, you must make your own work available to the public for reuse too. Also, it would be nice from you to let me know about it :) If you want to use this material otherwise, please contact me.
Matti Schneider @matti_sg
2
Je m’appelle Matti Schneider, je suis ingénieur et étudiant en anthropologie, et je vais vous parler d’amélioration continue. L’amélioration continue, qu’est-ce que c’est exactement ? Comment est-elle habituellement présentée ?
e u n i t n o c n o i t a r o i l é m L’a
3
L’amélioration continue est une démarche qui permet à une structure de réfléchir à ses modalités de production, et de produire mieux de manière progressive. La définition de « mieux » reste à l’évaluation de la structure en question : peut-être produire plus vite, peut-être produire plus proche de l’utilisateur…
4
Démarche différente de la démarche d’innovation, qui vise une rupture brutale, la « disruption » (réf). À l’opposé, l’amélioration continue est incrémentale et se met en place par des cycles PDCA répétés. Historiquement mis en œuvre au Japon (culture orientale peut-être, mais aussi et surtout d’après les travaux de Deming…), d’où le terme « Kaizen ».
5
L’amélioration continue est parfois présentée comme un effet de bord de l’agilité, parfois comme un de ses objectifs, et surtout souvent fantasmée (accélération permanente, hypervélocité…).
! s u o v À
Merci ;-) 6
Généralement, les introductions à l’amélioration continue se terminent là : c’est la solution à tous nos maux, à vous de la mettre en place grâce à l’agilité !
7
Sauf que, merci, le lien avec l’agilité est évident : itératif vs. big-bang. Tellement que c’en est un des principes.
« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. » — Manifeste Agile Principes, 2001
8
Généralement, ce principe est respecté par le biais des rétrospectives. Mais leur impact est souvent limité dans le temps et dans l’étendue des actions possibles. On aboutit à des optimisations, certes, mais des optimisations locales et non globales. Et on reste donc avec la question.
9
Comment, en tant que praticien agile, intégrer l’amélioration continue dans tout le cycle de production ? Je vais vous faire une proposition.
10
Je vais vous présenter une approche « centrée artefacts ». Nous allons voir comment modéliser le système de production par des artefacts, et comment les mettre en résonance pour travailler aussi facilement sur l’équipe que sur son modèle.
11
Avant toute chose, un peu de contexte. Ce dont je vais vous parler relève de l’expérience d’une startup dans laquelle j’ai travaillé jusqu’au mois d’avril 2014.
12
Avec de grandes ambitions : application web dans le domaine mĂŠdical.
13
Comme toute startup avec de grandes ambitions, elle avait très peu de ressources. Une équipe technique de trois personnes à temps plein, et deux personnes à temps partiel pour les aspects financiers, administratif…
YMMV Your Mileage May Vary
Votre Kilométrage Peut Varier 14
Ce qui nous est arrivé n’est pas obligatoirement ce qui vous arrivera. Les éléments d'analyse théorique que nous verrons dans cette session me semblent parfaitement généralisables, mais certaines propositions que je vous ferai, comme tout élément pratique, devront être adaptées à votre contexte spécifique. Seul vous connaissez votre projet, votre équipe… et pouvez donc choisir les morceaux qui font sens.
Nous façonnons nos outils et
15
Généralement, on renâcle à entendre parler d’outils dans le contexte de l’agilité, on préfère se focaliser — à juste titre — sur les interactions. Mais il y a médiation de nos interactions par nos outils ! Je vais vous proposer une manière de tirer profit de cette médiation.
16
Voici l’un des murs de notre bureau. Il est couvert d’artefacts (des objets investis d’une signification particulière par ceux qui les utilisent). Je vais m’attacher au type d’artefact le plus commun et le plus malléable : le board. Mais d’abord, qu’est-ce qu’un « board » ? Combien y en a-t-il sur cette image ? 1 ? 4 ? 5 ? 6 ? Plus de 30 ?
Radiateur d’informations interactif (low-tech ?)
17
Personnellement, j’en compte 4. Mais il est normal que chacun en ait une définition différente. Je vous en propose une, que je conserverai pour la durée de cette présentation : un radiateur d’informations interactif, a priori low-tech. Traduit de l’anglais, cela signifie : machin sur lequel on colle des post-its… et sur lequel on peut faire des dessins.
18
Le board le plus utilisé est le « task board », ce qui, traduit de l’anglais, signifie « tableau des tâches ». Si vous êtes en Kanban, c’est le kanbanboard, si vous êtes en Scrum, c’est le scrumboard, si vous êtes en machin, c’est le machinboard… bref, c’est là que vos stories avancent et c’est là qu’on suit l’avancement de la production.
19
Le tableau des tâches minimal, c’est trois colonnes : À faire, En cours, Fait. Généralement, pour paraître plus cool, on dit “Todo”, “Current” et “Done”. Nous avons nous aussi commencé avec cette base.
To-do
Current
Done
20
Nous avons fixé une limite de WIP (Work In Progress, nombre de story sur lesquelles il est possible de travailler en parallèle) à 3 pour « current » puisque trois personnes dans l’équipe technique. Exemple de story : « En tant que médecin, Je peux imprimer une ordonnance, Pour prescrire du paracétamol à un patient » On passe donc de « à faire » vers « en cours », où un générateur de PDF est implémenté pour que l’ordonnance puisse être imprimée, rendu disponible à l’utilisateur et validé, puis enfin la story est « faite ». Faire passer cette story dans ces trois étapes fonctionne, mais ne rend pas l’état de la production très lisible.
To-do
Implém entation
Revue
Déploiement Validation
Done
21
Nous avons voulu rendre visible la manière dont le travail avait été effectué lors de l’itération précédente. Nous avons donc mis à jour le board pour qu’il reflète la réalité de l’organisation de l’équipe. Mais tout n’est pas toujours aussi fluide. Par exemple, imaginons que la bibliothèque de génération de PDF choisie soit mauvaise. Dans le processus présenté ici, ceci n’est détecté que lors de la revue de code. Étant souvent confrontés à ce type d’inefficacité, les membres de l'équipe finissent par se concerter informellement avant chaque étape d’implémentation.
To-do
Analyse
Implém entation
Revue
Déploie ment
Validation
Done
22 Cette pratique devenant habituelle, elle est rendue visible dans le tableau des tâches. WIP1 puisque toute l’équipe doit être présente, pour minimiser le temps passé à la revue. Mais après quelques itérations, il apparaît que cette nouvelle phase d’analyse est elle-même source de pertes : toute l’équipe est mobilisée pour un temps potentiellement long. Notamment, la recherche de documentation ou la validation expérimentale peuvent être chronophages. Les membres de l’équipe sont agacés de perdre du temps à discuter des possibilités d’implémentation sans avoir toutes les billes techniques nécessaires. D’où frustration, ennui, désengagement… et adaptation spontanée : on convient qu’une personne est suffisante pour accumuler de l’information sur les possibilités techniques avant de prendre une décision. Cette pratique se généralisant et son efficacité étant avérée après quelques itérations, l’artefact est mis à jour pour refléter la nouvelle organisation.
To-do
Exploto Concept Implém Revue typage ion entation
Déploie ment
Valid ation
Done
23
La phase d’analyse est donc éclatée en deux phases. La première, l’explototypage, combine deux approches pour récolter le maximum d’informations permettant d’alimenter la conception. Ce néologisme permet d’exprimer l’usage combiné de l’exploration (enrichissement en largeur de l’espace des solutions possibles) et du prototypage (enrichissement en longueur de l’espace des solutions possibles). La seconde, la conception, consiste en une prise de décision collégiale au sein de l’équipe, sur la base des informations accumulées lors de l’explototypage.
Nous façonnons nos outils et
24
Je vous ai donc présenté un outil que nous avons mis en place, mais surtout la manière dont nous l’avons fait.
Nous façonnons nos outils et
25
Le point fondamental à retenir est que nous pouvons façonner nos outils à travers nos interactions. Et il se trouve que cette conception émergente est particulièrement pertinente.
26 En effet, on retrouve le double diamant du design. Ce modèle de la résolution créative de problèmes explique que l’espace des solutions est exploré en quatre phases. Tout d’abord, sur la base du problème exprimé, l’espace des solutions possibles s’élargit pour en inclure autant que possible. Ensuite, les plus coûteuses et les moins pertinentes sont éliminées, jusqu’à converger sur un plan, un accord d’implémentation. Ce plan est ensuite confronté à la réalité, et l’espace des possibles s’élargit à nouveau pour faire face aux difficultés imprévues qui apparaissent. Enfin, l’implémentation converge vers la solution qui est réellement livrée. L’approche descriptive du système de production permet de faire coïncider son modèle avec ce modèle provenant d’une autre discipline.
Explototypage
Conception
Implémentation
Revue
27
Le lien entre les deux modèles étant établi, on peut à présent mobiliser celui hérité du design pour proposer une solution à une difficulté rencontrée dans le système de production. En effet, on observe que les phases explototypage et d’implémentation ne sont parfois pas « réellement finies ». Par exemple, il peut apparaître lors de la phase de conception qu’une story nécessite de l’explototypage supplémentaire. On ne peut pas accepter de faire reculer le ticket, sinon le suivi d’avancement de la production n’a plus aucun sens.
28
Le modèle en double diamant montre clairement qu’il n’existe que trois points dans le temps où il est possible de discuter d’une proposition précise et non d’un ensemble : lorsqu’une solution est pressentie, lorsqu’un plan d’implémentation est proposé, et lorsque l’implémentation est finalisée.
29
Les phases d’élargissement de l’espace des possibles sont absolument nécessaires à la résolution créative de problèmes.
30
Mais déterminer leur état de finition est impossible. Est-ce qu’avoir essayé 5 bibliothèques de génération de PDF est suffisant ? Pourquoi pas 10 ? Est-ce que 3 n’auraient pas suffi ?
Explototypage
Conception
Implémentation
Revue
31
On remarque donc qu’il est impossible de déterminer si une des étapes de divergence (d’élargissement) est allée assez loin sans évaluer la finition de la phase de convergence suivante.
Explototypage
Conception
Implémentation
Revue
32
La solution est donc de considérer la phase de convergence comme une condition de validation de la phase de divergence, même si le processus idéal ne fait qu’une seule passe.
To-do
Exploto Concept Implém Revue typage ion entation
DoD
Déploie ment
Valid ation
Done
DoD
33
Concrètement, cela signifie que les étapes de conception et de revue de code deviennent des conditions de validation des étapes d’explototypage et d’implémentation. Celles-ci ne sont considérées comme terminées que lorsque l’équipe s’est accordée sur un point fixe.
To-do
Exploto typage
Implém entation
Déploiement Validation
Done
34
L’idée était de limiter l’exploration au strict nécessaire pour aboutir à un plan d’implémentation. De la même manière, l’implémentation est limitée à ce qui est nécessaire pour passer la revue de code. Cette modification du tableau a effectivement eu l’impact voulu sur le système de production, puisqu’une nette fluidification a été remarquée, entraînant une accélération et une baisse de la frustration.
Nous façonnons nos outils et
35
Nous avons vu en premier lieu que nous pouvons façonner nos outils à travers nos interactions.
Descriptif Nous façonnons nos outils et ceux-ci à leur tour nous façonnent. — Marshall Mc Luhan Understanding Media: The Extensions of Man, 1964
Prescriptif 36
Nous venons à présent de voir que nous pouvons tirer profit du fait que nos outils influencent nos interactions.
Nous façonnons nos outils et
Descriptif
Prescriptif ceux-ci à leur tour nous façonnent. 37
C’est la combinaison de ces deux aspects qui peut libérer la puissance d’un artefact.
Descriptif
Prescriptif 38
Il est donc possible de représenter la relation entre les artefacts et le système de production éminemment complexe (individus, logiciels, connaissance accumulée…) qu’ils modélisent sous la forme d’une boucle de rétroaction.
ceux-ci à leur tour nous façonnent.
Descriptif
Prescriptif 39
Dans un premier temps, un artefact peut être descriptif : il rend visible certaines caractéristiques du système.
Descriptif
Prescriptif 40
Dans un second temps, un artefact peut être prescriptif : il commande, ou du moins influence, certaines caractéristiques du système. Lorsque les deux aspects sont réunis pour un même couple artefact / système de production, la boucle de rétroaction est complète. Le système entre alors en résonance avec son modèle.
Prescriptif Résonance Descriptif
41
Dans l’état de résonance, toute modification du système impacte au moins un artefact, et toute modification d’un artefact modifie l’état du système.
42
Et donc, on atteint l’hypervélocité !!! Je plaisante, mais il s’agit effectivement de la clé à la mise en place de l’amélioration continue. Je vais à présent vous montrer un second exemple.
43
Les artefacts de suivi de la production, comme le tableau des tâches, ne sont pas les seuls types de board qu’on peut construire. Je vais à présent vous présenter un autre artefact, dédié exclusivement à l’influence des interactions.
44
Il s’agit d’un artefact de type « Reflection workshop output », tel que défini par Alistair Cockburn dans Crystal Clear. C’est-à-dire qu’il est mis à jour lors des moments où l’équipe « réfléchit aux moyens de devenir plus efficace », pour lui permettre de « régler et modifier son comportement en conséquence » (cf. principe agile). En Scrum, ça signifie « à la fin des rétrospectives ».
45
À la fin de chaque rétrospective, l’équipe crée un ticket « guide » pour chaque règle qu’elle décide d’adopter, pour renforcer ses points forts et réduire ses points négatifs. Cela signifie donc que dans cet artefact est d’abord prescriptif. Il cherche à définir les règles du système avant que de les décrire, à l’inverse du tableau des tâches.
46
Les premiers guides ainsi créés sont triviaux. Ils répondent aux problématiques simples du début, quand l’équipe se définit. Mais on a bien vu que pour qu’il y ait résonance, pour que la boucle de rétroaction soit bouclée, un aspect descriptif est nécessaire.
47
Cet aspect descriptif est apporté plus tard. Les guides ne sont en effet pas absolus, et peuvent devenir obsolètes. À une telle occasion, le guide est « fermé ». Exemple : la durée des itérations est changée au sprint 34.
48 Il est également possible que l’équipe n’arrive pas à respecter une des règles qu’elle avait édictées lors d’une itération précédente. Cette difficulté est repérée lors d’une rétrospective, et l’artefact est mis à jour pour refléter l’état du système. Ici, par exemple, l’équipe a régulièrement eu du mal à délimiter le standup à 6 minutes pendant l’itération, alors qu’il s’agissait d’un de ses guides. Pour que l’artefact soit un modèle du système, le guide en question est mis en « observation », une ligne spécifique du board. Cet aspect descriptif est couplé à un effet prescriptif pour l’itération suivante : le guide est mis en évidence pour l’équipe. Si elle n’arrive à nouveau pas à le respecter, elle en discutera lors de la rétrospective et pourra par exemple décider de fermer ce guide, ou d’en créer de nouveaux pour s’aider à le respecter.
49
Bien entendu, il ne s’agit pas de modéliser pour le plaisir de modéliser. Nous avons pu mesurer la puissance de cet artefact à travers le nombre de débats et de faux pas évités. Vous avez déjà eu une discussion où l’un des locuteurs pense que le débat a déjà eu lieu ? Dans notre cas, pointer le guide correspondant a toujours suffi à stopper net la discussion, sans aucune frustration puisqu’il s’agit de rappeler un point sur lequel il y a déjà eu accord. De la même manière qu’un ticket représentant une story est un « reminder to have a discussion », un ticket représentant un guide est un « reminder that a discussion has been had ».
50
Dans le temps, les guides deviennent beaucoup plus spĂŠcifiques. Et on atteint bien entendu un niveau meta.
51
Certains guides peuvent en effet influencer le fonctionnement du guide board lui-même. Ce qui nous mène à constater qu’un artefact en résonance avec le système en fait nécessairement partie, puisqu’il l’influence… Ça, c’est un vrai système adaptatif complexe.
52
L’idée de cette approche « centrée artefacts » est donc celle d’une modélisation globale, où l’ensemble des artefacts créés par leurs utilisateurs représente le plus complètement possible le système de production.
53
Voici donc, finalement, le système de production lui-même. Ce que l’on voit est le modèle mais, celui-ci étant en résonance avec le système, les deux sont équivalents. Cette approche « centrée artefact » pourrait finalement être qualifiée de généralisation de l’approche kanban. Simplement, au lieu de rendre visible seulement la chaîne de production, on modélise l’intégralité du système de production, et notamment les interactions en son sein. Un modèle étant toujours une version simplifiée du système, il est plus simple de débattre de changements à appliquer sur le modèle que de discuter du système lui-même.
Descriptif
54
Nous avons donc vu un premier artefact qui est a priori descriptif. Nous avons remarqué qu’une fois suffisamment de temps passé, le modèle devient suffisamment bon pour objectiver le processus de production et permettre sa modification. À partir du moment où cet artefact devient en partie prescriptif, il entre en résonance avec le système et modifier l’un revient à modifier l’autre.
Descriptif
Prescriptif 55
Nous avons vu un autre artefact, lui a priori prescriptif. Nous avons remarqué qu’une fois suffisamment de temps passé, les guides sont internalisés par le système ou effacés par lui. Le modèle décrit donc une partie des règles d’interaction du système. À partir du moment où cet artefact devient en partie descriptif, il entre en résonance avec le système et modifier l’un revient à modifier l’autre.
Descriptif
Prescriptif 56
Dès lors, les propositions de changements d’un système adaptatif complexe deviennent de simples débats sur des modifications à appliquer aux artefacts. Qui est responsable de cette évolution des artefacts ?
Descriptif
Prescriptif 57
Ceux qui sont au sein du système modélisé. Dans le cas du développement, c’est l’équipe. Elle est responsable de ses artefacts et choisit de les faire évoluer. Ce point est crucial pour l’appropriation et donc le respect de l’aspect prescriptif, sans quoi la mise en résonance est impossible et le changement n’émergera pas.
Descriptif Approche « centrée artefacts »
Prescriptif 58
Cette approche « centrée artefacts » vise ainsi la résonance entre le système de production et les artefacts le modélisant pour que leur modification impacte directement le système. Et cela, nous l’avons validé expérimentalement, facilite l’amélioration continue et l’ancre à travers le temps et les modifications du projet.
Merci ! Des questions ? Merci à Nicolas Dupont et Thomas De Bona, sans qui rien n’aurait pu arriver ; Anouchka Labonne, Fabien Brossier, Frank Wagner, Régis Rallo et Émilie Franchomme, sans qui cette présentation n’aurait pas été ce qu’elle est.
Crédits images : Photos CC-BY-SA Matti Schneider Photos oiseau © Thomas De Bona Understanding Media©GingkoPress Cliparts © approvalsandaccreditation.com, referenceforbusiness.com, homza.com, aoma.edu 59
Références : - Manifeste Agile, 2001 - Grammaire des conduites à projet, Jean-Pierre Boutinet, 2010 - Crystal Clear, Alistair Cockburn, 2003 - The Double Diamond Design Process Model, Design Council of UK, 2005 - Toyota Production System, S. B. Gershwin, MIT OCW, 2010 - Objects, Bodies and Gods, Arnaud Halloy, 2013 - Ethnographie d’un daily standup, Matti Schneider, 2013 - Toyota production system and Kanban system, Y. Sugimori, K. Kusunoki, F. Cho & S. Uchikawa, Toyota Motor Co., 1977 - Proceedings of « Artifacts, practice and knowledge elaboration » seminary, LAPCOS - MSHS - University of Nice Sophia-Antipolis, 2014