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 ?
4 commentaires:
J'aime votre vérification de la réalité.
J'aimerais bien si on pouvait perdre la marque "agile" (ou n'importe quoi) et simplement décider á trouver des façons d'améliorer comme nous développons des logiciels.
(Vuillez pardonner mon français affreux!)
Oui, c'est une très bonne idée. Ne plus appeler ça Agile, simplement le bon sens.
bonjour Laurent,
je suis tout à fait d'accord avec ton billet, notamment sur les incohérences que tu exprimes, de certaines entreprises qui (veulent) adapter l'agilité et tout à fait d'accord aussi sur le fait que l'agilité ne peut pas se faire en changeant mollement les process.
Par contre le terme "big bang" me dérange. Car cela donne une image de (trop grande) globalité.
Je pense que la transition doit d'abord "se chercher" et "se trouver" , rien n'est acquis et rien n'est "out of the box" , du coup une phase exploratoire permet de trouver les priorités, et oui on effectue une multitude de ruptures (quelques fois brutales) sur l'orga et la structure, si on doit parler de big bang , ça serait plutôt de manière très localisée. (Déminage de la structure à côté de ça s'accompagne l'amaigrissement de certaines parties, à petits pas, en lean.
je crois que le modèle que tu exprimes, de bigbang, est légitime quand l'entreprise (la relation métier/SI) est complètement bloqué, en crise et que tout est en anomalie, dans ce cas c'est plus facile d'accepter la transition big bang global.
Peut-être que c'est la vision que tu exprimes aussi part ton billet. En tout cas, on est tous d'accord, la transition ne se fait pas mollement !
merci pour ton billet
laurent
Merci Laurent,
Le terme BigBang est plus là pour marquer le coup, lancer le buzz comme on dit ;-)
Je parle bien d'approche graduelle, de pilotes, faisant le lien avec la notion de phase exploratoire dont tu parles et l'application périmètre par périmètre. C'est de cette façon que nous nous efforçons de "transformer" nos clients.
Mais sur chaque périmètre, il faut avoir le courage de vraiment changer, de ré-apprendre. Lean et Scrum sont là pour nous aider dans le contexte inspection/adaptation. Scrum sur le produit, Lean sur son écosystème.
Derrière ce message, plus largement, je parle de volonté de survie des entreprises à moyen terme. Sans une vraie agilité, je ne vois pas comment une entreprise pourrait perdurer dans cette environnement excessivement rapide et dynamique du marché. D'autres le feront à sa place sinon.
Enregistrer un commentaire