Blog de Bruno Orsier

Un article de Bruno Orsier    1 Commentaire

Nouveau dojo agile, nouvelle difficulté pour expliquer ce que j’ai fait au boulot quand je rentre à la maison… Vendredi j’ai animé un atelier dans lequel mes collègues ont fabriqué des chapeaux et des bateaux en papier. Des paires de chapeaux et de bateaux en fait. Très important les paires – les collègues recevaient des primes (bonbons ou chocolats) uniquement pour les paires. Evidemment on vous prend pour un fou quand vous essayez d’expliquer tout ca.

Mais c’est tout de même assez sérieux. En 2005 j’ai eu la chance de participer à un atelier similaire, en compagnie de plusieurs collègues, dont le vice-président d’une des divisions de notre groupe. Malgré les sommes à neuf chiffres sous sa responsabilité, ce vice-président a plié des avions en papier comme tout le monde, et il était très motivé par le concept de kanban que nous découvrions à l’occasion. Et personne ne l’a pris pour un fou.

Bref, vendredi c’était notre troisième dojo interne. La particularité de ce dojo interne c’est qu’il n’est pas limité à l’acquisition de connaissances de programmation, c’est un dojo où nous essayons d’approfondir nos connaissances sur les méthodes agiles, comme rapporté dans les compte-rendus précédents (dojo de décembre 2008 et dojo de novembre 2008, premières activités et le challenge de programmation). Nous avons déjà employé des vidéos, des articles, des séances de brainstorming.

Cette fois-ci c’était plus ambitieux. Je me suis lancé dans l’animation de l’atelier I’m not a Bottleneck! I’m a Free Man! de Portia Tung et Pascal Van Cauwenberghe. Ambitieux car je n’ai encore jamais assisté à une de leurs sessions (souvent citées par les blogueurs, voir par exemple le billet Obeya de Claude Aubry), donc je partais dans l’inconnu. Heureusement j’ai bénéficié du soutien d’Alexandre Boutin, qui a déjà animé plusieurs fois cet atelier, et qui m’avait passé ses transparents. Alexandre nous avait de plus fait un retour d’expérience lors de la réunion mensuelle du CARA.

Pourquoi un tel atelier ? Son véritable sujet est la théorie des contraintes. Ce sujet m’intéresse depuis 2005 (à cause aussi de l’atelier des avions en papier), mais je n’ai pas encore réussi à l’utiliser concrètement dans mon travail. A ma décharge, fin 2005 nous sommes passés à Scrum qui permet déjà de bonnes optimisations de processus de développement. De plus j’ai ensuite étudié le Lean Software Development, qui a permis de faire certaines optimisations dans notre implémentation de Scrum, en faisant apparaître certains gaspillages, notamment grâce à la technique du Value Stream Mapping.

Par exemple des équipes ont découvert qu’elles commençaient à étudier certaines user stories du backlog jusqu’à trois mois avant qu’elles ne soient réellement implémentées. Du point de vue du Lean Software Development, c’est un gaspillage, qui rentre même dans plusieurs des sept catégories (travail partiellement fait, process inutiles, attentes et retards, transmission d’information par exemple). Avoir un backlog aussi gros qui permette cela est un autre gaspillage au sens Lean, car cela représente un stock important ! Les cartes de value stream mapping ont aussi fait apparaître de nombreux aller-retours entre développeurs et testeurs (qui se traduisent par des boucles sur la carte), ce qui a provoqué une prise de conscience et des réductions de ces boucles.

Enfin, cette réflexion sur le Lean a permis d’identifier des métriques pertinentes pour notre processus, comme le temps de cycle et l’âge moyen des user stories et des bugs.

Malgré ces points positifs, les améliorations basées sur Lean restent limitées, et il reste difficile de promouvoir une « attitude Lean quotidienne », car les idées Lean prêtent facilement le flan aux critiques du type « idées à la con, lues dans un bouquin, pas valables dans notre domaine » pour faire vite. Rien de très surprenant, ces idées sont parfois contre-intuitives et souvent mal reçues.

Toutefois il reste vital pour nous d’arriver à développer une attitude d’amélioration continue systématique : c’est peut-être la chose la plus difficile à atteindre dans notre implémentation de Scrum. Par exemple les rétrospectives Scrum n’ont pas réellement la faveur de nos équipes (comme un sondage interne l’avait montré courant 2008, après trois ans de pratique). Et pourtant ces rétrospectives pourraient être le moteur de l’amélioration continue.

Face à ces difficultés, il me semble que la théorie des contraintes peut fournir un outil simple et concret (parfois non-intuitif lui-aussi), qui peut-être va mieux parler nos ingénieurs. En effet on peut la présenter comme un algorithme en quelques étapes, étapes dont j’emprunte la description à Alexandre Boutin :

• L’identification du goulot du système (personne ou activité qui limite le flux de sortie). Il existe un goulot dans tous les systèmes et un seul goulot limite le flux de sortie. Le goulot est identifiable car il travaille tout le temps, il y a du stock en amont du goulot et le travail est irrégulier en aval.
• L’exploitation du goulot. Actions d’amélioration gratuites comme par exemple retirer du goulot toutes les tâches qui ne produisent pas directement de valeur ajoutée pour l’utilisateur final.
• La subordination au goulot. Actions d’amélioration gratuites comme par exemple s’assurer que ce qui entre dans le goulot est d’une qualité parfaite ou que rien ne viendra dégrader ce que le goulot a produit, donc éviter que le goulot ne travaille pour rien.
• L’élévation du goulot. Actions d’améliorations payantes comme par exemple rajouter une ressource, payer une formation ou acheter un outil.

Il faut ensuite recommencer le processus.

L’animation de l’atelier m’a notamment permis d’insister sur le fait que, selon la théorie des contraintes, dans l’amélioration d’un système il y a des étapes quasiment gratuites (au prix toutefois d’un effort intellectuel !) . En effet avant de chercher à ajouter des personnes, des ordinateurs ou autres ressources payantes (élévation du goulot), il faut travailler sur l’exploitation et la subordination. Je fais l’hypothèse que ces idées pourraient fournir des outils concrets dans les rétrospectives Scrum.

Toutefois, juste pour confirmer à nouveau qu’il y a des choses pas très intuitives (et donc des résistances probables), je cite ce billet tout frais de Christian Hohman, Aurions-nous été Lean plus tôt ! :

C’est aussi l’histoire de ce mythe encore tenace : dans les pays à fort coût de main d’œuvre, il faut AUTOMATISER !

Les ingénieurs écoutent ce message avec gourmandise et s’exécutent avec zèle.

Cette citation décrivant une situation vécue illustre bien le fait que intuitivement nous allons vers l’élévation, pas l’exploitation ni la subordination !

Il reste beaucoup à dire sur ce dojo (je me suis laissé trop entraîner sur la description du contexte !), il faudrait notamment décrire :

• le détail de l’animation de l’atelier (il me reste à mieux maîtriser certains points),
• le randori de l’après-midi, où nous avons continué sur le challenge de programmation du simulateur de fourmis.

Mais pour l’instant je peux déjà rapporter que l’atelier des chapeaux et bateaux en papier a remporté un vif succès parmi la douzaine de participants !