Blog de Bruno Orsier

Un article de Bruno Orsier    2 Commentaires

Quand nous avons mis en place Scrum en 2005, notre but était de développer plus rapidement et plus facilement de nouveaux produits, entre autres objectifs. Au fil du temps nous avons découvert que même si Scrum fonctionne parfaitement bien, nous n’avons pas réellement développé plus rapidement. L’hyper-productivité mentionnée par certains ne nous a jamais rendu visite ! Néanmoins je reste convaincu qu’il y a encore beaucoup de possibilités de mieux développer les nouveaux produits, et surtout de gagner du temps. Je ne suis pas obsédé par une « productivité » bien difficile à mesurer, mais par contre je déteste les gaspillages de temps : débogages interminables, faire/défaire/refaire une histoire utilisateur mal comprise, séjours chez les clients pour résoudre des problèmes mystérieux. la liste est bien longue.

Une clé pour un développement plus facile de nouveaux produits est probablement d’accompagner la pratique de Scrum par le développement d’une nouvelle culture d’entreprise favorisant l’amélioration continue.

Pour moi l’amélioration continue c’est essayer de trouver quasiment chaque jour comment travailler un peu différemment et un peu mieux que la veille. Cette attitude peut se manifester à divers niveaux :

• individuel. Par exemple hier j’ai cliqué 100 fois pour répondre non à un message inutile dans une application, aujourd’hui j’ai investi une heure pour trouver un moyen d’automatiser cela – cf. Des clics en moins grâce à PowerShell. En faisant cela je perds un peu de temps mais j’augmente mes compétences en PowerShell ou en Autohotkey, ce qui me rend de plus en plus efficace et m’évite de la fatigue inutile.
• équipe. Par exemple les rétrospectives permettent d’analyser ce qu’on pourrait faire différemment dans le prochain sprint.
• projet. La rétrospective globale « post-mortem » permet de tirer des leçons pour travailler différemment dans les projets suivants.

Je constate qu’il ne suffit pas de disposer des outils (comme les rétrospectives) pour que l’amélioration continue fonctionne. Par exemple il est difficile de faire passer les informations des rétrospectives à travers les silos que représentent les équipes ou les projets ; ainsi il arrive que équipes ou projets refassent des erreurs déjà connues, ou encore réinventent la roue mise au point dans un bureau voisin, ou encore mettent des années à adopter la bonne pratique qui a fait ses preuves à proximité.

D’autre part l’amélioration continue ne peut pas être décrétée par le management. Ca paraît surement évident, mais hélas nous avons essayé pendant un bon moment, sans trop de résultats. Maintenant, nous cherchons surtout à dégager des moyens et du temps pour laisser un espace favorable à l’amélioration continue : il s’agit de la démarche de caddying, des journées labos, des dojos internes et externes. Je publie régulièrement à propos de ces actions, mais je crains que mes billets apparaissent un peu décousus. C’est pourquoi je souhaite montrer comment ces diverses actions se relient les unes aux autres, et contribuent à l’amélioration continue. Après quelques tentatives, je suis arrivé au diagramme ci-dessous (cliquez pour le voir en plus grand) :

Vous pouvez aussi le voir sous forme de fichier PDF.

Note : ce diagramme a été fait avec Flying Logic, un logiciel bien pratique pour apprendre certains outils de la théorie des contraintes, les « thinking tools ». J’ai suivi de manière très libre le format d’un « arbre de transition », et une flèche de A vers B signifie ‘ »A entraîne B », ou « A contribue à B ». J’aime bien le principe de Flying Logic qui consiste à prendre entièrement en charge la disposition des divers éléments, je trouve que ses ré-arrangements de disposition incessants sont plutôt stimulants pour ma créativité, mais cela ne conviendra pas à tous les utilisateurs. Je n’ai pas utilisé de mind map car ici je veux pouvoir facilement représenter facilement un graphe, et pas un simple arbre.

Ce diagramme transcrit ma compréhension actuelle (et partielle) de nos diverses initiatives, et il permet de faire ressortir :

• les activités « externes » : avec plusieurs collègues, nous investissons du temps dans la construction d’une communauté locale. C’est quelque chose de très nouveau pour nous : nous ne le faisons que depuis la création du CARA, le club agile Rhône-Alpes, qui nous donne une structure favorable. Les conséquences de ces activités externes sont la génération et le partage de connaissances.
• le partage de connaissances, qui apparaît comme un élément central, et serait donc une clé très importante pour l’amélioration continue.
• un rôle « racine » pour la démarche de caddying – mais cela est peut-être biaisé par mon rôle dans la démarche !

Dans les billets précédents, j’ai déjà pas mal commenté les diverses actions de ce diagramme, il restera à expliquer les formations récurrentes et obligatoires, ce sera fait prochainement.

Ce diagramme est plutôt un point de départ, il évoluera certainement en fonction de l’évolution de ma compréhension des impacts des diverses actions en cours. D’autre part il n’engage que moi : d’autres collègues préfèrent d’autres manières de présenter nos actions. Il faudra aussi un jour faire apparaître les éventuels effets négatifs des actions, mais j’ai encore du mal à les identifier.

Alors qu’en pensez-vous ? Est-ce qu’un tel diagramme est utile pour comprendre comment nous essayons de nous améliorer ?