L’effet Big Bang

Cela fait maintenant quelques années que j’aide les entreprises à « passer » à l’agile.

Dans cette démarche, il m’est souvent conseillé de ne pas le faire en mode Big Bang, mais en douceur. Bon, d’abord, c’est moi le consultant qui conseille, non mais, puis quoi encore.

Et là je dis niet, pas de douceur. On n’est pas là pour s’amuser, pour mettre une nouvelle méthode et faire joujou avec les développeurs, leur mettre la pression pour qu’ils développent plus vite et je ne sais quoi encore.

C’est bien pour changer les choses, arrêter de perdre du temps et de l’argent, arrêter d’avoir des chefs de chefs de chefs…  C’est former une vraie équipe autour d'une idée, d'un produit, pour attaquer le marché, pour en gagner des nouveaux ou pour innover qu’il faut de l’agilité.

J’ai été fortement désappointé (je n’ai pas voulu être grossier sur ce point) lorsque j’ai entendu dernièrement qu’une entreprise qui au bout de 4 ans de transformation trouvait encore le scrum meeting comme une augmentation du coût de gestion de projet de 15%.

Dans d’autres entreprises, je me bats pour remplacer les systèmes qualité obsolètes, qui de plus ont été mis en place à fort renfort budgétaire. Qui a déjà mis en oeuvre ISO ou CMMI ? Combien cela vous a coûté, combien êtes-vous prêt à mettre pour passer à l’agilité ? Que vous ont apporté ces méthodes, à part une multitude de  « sachants contrôleurs » non productifs. Tant qu’à mettre des process, allez jusqu’au bout et utilisez la DO178-B, au moins c’est compatible avec l’eXtreme Programing sur le 100% de code testé.
Des additions de process au lieu d’optimisation. Des réunions de 4 heures hebdomadaires de suivi de projet à 15 personnes, alors que l’équipe projet se retrouve seul le jour de la démo. A n’y rien comprendre.

C’est ce que le Lean appelle l’optimisation locale, et qu’il est fortement déconseillé de faire. (Voir Lean Primer)

Je me souviens aussi lorsque Craig Larman est venu agiliser Valtech : « Quoi! Vous n’avez pas d’intégration continue, bon, bein, mettez-la en place, et je reviendrai quand ce sera fait ». (Traduction très adapté du message original, et avec une petite touche du sud-ouest !)

Il faut faire RAZ de tout, remettre notre cerveau à blanc, recommencer à réfléchir, arrêter de subir.

J’ai fort heureusement travaillé avec une entreprise qui a su faire le pas de manière radicale parce que nécessaire à son maintient dans la course, voire à sa survie. « C’est Agile ou rien, pas de plan B ». Oh, bien sûr tout n’est pas rose, ça laisse des traces, mais les principes sont acquis, le changement est en marche et l’entreprise même remonte sur le devant de la scène, renouvelle avec les bénéfices. Et pourquoi, parce qu’ils ont pris exemple sur une de leur entité, une entité de 200 personnes avec 3 managers seulement, qui avait la meilleure rentabilité du groupe et qui pratiquait les méthodes Agiles.

Bien sûr, on ne peut changer une entreprise dans son ensemble en une seule fois. C’est là qu’une approche graduelle doit être mise en œuvre. Du projet à l’entreprise, la route est longue. Mais au moins, à chaque étape de transformation, pensez à remettre les compteurs à zéro et prônez un changement radical. Quelques projets pilotes pour appréhender la capacité de pénétration de la méthode, beaucoup d’évangélisation, souvent par capillarité des pilotes, puis une application graduelle par niveau dans l’entreprise (service, entité, entreprise). Et là rien ne vaut l’expérience, merci Valtech !
Il faut au moins du BigBang sur le périmètre de mise en oeuvre pour s'affranchir des freins et obtenir les gains réels de la méthode.

Attention la prochaine sera BigBang sinon rien. Etes-vous prêt à changer ?

Tour de Babel : Atelier en plusieurs langues

J’ai animé aujourd’hui un atelier où les participants parlaient plusieurs langues. Il y avait un américain, un canadien, une brésilienne, un allemand et plusieurs français.

D'habitude, dans ce cas, la langue utilisée est l’anglais, mais aujourd’hui, c’est le français qui a été utilisé, Oui!
Tous ont fait l’effort de parler en français. Le canadien avait un peu de mal, l’américain lui faisait la traduction lorsque nécessaire.




Il s’agissait d’un atelier de début de projet, nous avons identifié les personae.

Premièrement, j’étais étonné que pour une fois, nos amis d’outre atlantique fassent l’effort de parler notre langue, même avec difficulté, c’était un joli message de collaboration avec l’équipe.

Au-delà de la langue et de la sémantique, ce qui m’a interpellé c’est qu’au travers du « peu » de vocabulaire de nos collègues étrangers, c’est le besoin qui était challengé. A chaque mot utilisé, en cas de doute, tout le monde cherchait la traduction dans la langue originale de chacun. Une sorte de règle des 3C adaptée aux mots. Card : le mot, Conversation : la bonne traduction, donc compréhension, Confirmation : tout le monde est d’accord.

Ce qui est marrant aussi, c’est que par habitude les français lançaient leurs phrases en anglais, puis en milieu de phrase, s’en rendant compte, la refaisaient en français.

J’ai trouvé ça vraiment très instructif. Ça change finalement des réunions en franglais, où nous n’osons pas dire à nos interlocuteurs anglophones que nous avons compris le contexte, mais pas forcément les détails.

Autre point que j’ai noté, l’utilisation des personae renforce le côté spécification par l’exemple. A partir du moment où un acteur du système est personnifié, ces activités le sont aussi par des jeux d’exemple, de micro scénarios. Il a été beaucoup plus facile de leur faire écrire les histoires utilisateur ensuite.