Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

12 juillet 2010

L'équipe décide de la solution

Au dernier Agile Development Practices West 2010, j'ai observé un pattern de réponses à la question : comment régler tel ou tel problème dans un contexte agile. La réponse est venue, en autre, dans le contexte d'une présentation de Johanna Rothman, intitulée "Overcoming the pitfalls of agile transitions". Essentiellement la réponse est, "laissez l'équipe trouver la meilleure façon de faire."

 

J'en parle ici, car c'était la réponse qu'offraient, presque mot pour mot, la plupart des conférenciers lorsqu'un participant demandait "que faites-vous lorsque vous rencontrez telle situation…". Ce fut la réponse de Jean Tabaka et Bill Wakeman lors de "System think", de Jennifer Bonnie pendant "Managing change", et de Christine Del Prete lors d'un panel de discussion. Après quatre fois, quand Johanna Rotham a prononcé les mots magiques, j'ai finalement reconnu le pattern! Bien sûr, je le connaissais déjà, pour l'avoir expérimenté avec des équipes et déduis du concept d'équipe autogérée, mais de l'entendre si clairement exprimé et à répétition pendant quelques jours, ça donne encore plus de force au message.

 

J'ajouterais qu'en mode transition, il ne suffit pas de laisser l'équipe trouver la solution, de leur "dumper" le problème. Souvent, de mon expérience, les équipes ne sont pas prêtes à décider du chemin à prendre, en tout cas, pas initialement. Après des décennies à se fier au chargé de projet, au boss, pour prendre les décisions, pour savoir quoi faire, l'équipe ne sait pas par quel bout prendre ce nouveau pouvoir. C'est donc le rôle de la personne en charge de guider l'équipe vers ce nouveau mode de fonctionnement en déterminant les attentes, en supportant l'équipe et en facilitant le travail. En deux mots, devenir ce que l'on nomme un "servant leader".

 

Ce mode de fonctionnement est peut-être plus long au départ, mais il est plus payant à long terme. Il permet d'abord d'avoir plusieurs têtes pour trouver des pistes de solutions et on sait que plusieurs têtes valent mieux qu'une!

 

La réflexion impliquant toute l'équipe, donne à chacun une meilleure compréhension du contexte, de la démarche de solution et finalement du choix de solution qui sera mise en œuvre. Elle permettra ainsi à l'équipe de réagir et de s'adapter plus rapidement dans le futur, si la situation change. On élimine aussi un goulot d'étranglement au niveau des décisions, car on ne dépend plus d'une seule personne. On augmente aussi le sentiment de contribution des membres de l'équipe au travail réalisé.

 

Outre l'apprentissage, on va aller chercher un bien meilleur engagement de l'équipe par rapport au travail à faire. Cette approche permet aussi de bâtir un esprit d'équipe, de souder un groupe de personnes en une équipe concertée.

 

Cette approche va dans le sens du Nemawashi, un concept des entreprises japonaise, dont Toyota, qui vise à obtenir un consensus, celui des participants affectés, avant de passer à l'action.

 

Il faut faire confiance à l'équipe, car ce sont des professionnels et on est en droit de s'attendre à ce qu'ils jouent leur rôle (voir http://agile.blogspirit.com/archive/2010/07/07/etes-vous-un-developpeur-professionnel.html )

 

Pour en savoir plus :

Servant leadership : http://www.ianrpubs.unl.edu/epublic/live/g1481/build/g1481.pdf

Exemple : http://blog.agilebuddy.com/2010/01/sprint-start-and-stop-days-whats-best.html

Nemawashi : http://www.kirainet.com/english/nemawashi-%E6%A0%B9%E5%9B%9E%E3%81%97/