SCRUM ET ICEBERGS

Le dernier billet de Bruno Orsier m'a beaucoup plu. Notamment, il m'a fait découvrir la passionnante vidéo d'une conférence donnée par Ken Schwaber à Google.

Parmi les sujets abordés par le co-créateur de Scrum, il y en a un qui me touche beaucoup en ce moment. Il y a peu, je l'ai abordé à l'occasion d'un billet sur les conflits qui apparaissent tôt lorsqu'on pratique une démarche agile.

Ken Schwaber affirme que la pratique de Scrum par une organisation est un test de sa capacité à accepter les problèmes qui seront soulevés souvent très tôt.

Ces problèmes sont dévoilés tôt par les démarches agiles car elles visent à livrer très tôt un produit partiel et potentiellement livrable. Livrer au plus tôt un produit oblige à exercer au plus tôt toutes les formes de collaboration, de communication et de travail d'équipe nécessaires à la création de valeur pour le client. Exercer au plus tôt toutes les activités révèle au plus tôt les obstacles à la création de valeur.

Ces problèmes ne sont pas dûs à la pratique de Scrum. Ils existaient bien avant, cachés et ignorés. Par contre, l'application de Scrum (ou d'une autre démarche agile) révèle vite la partie immergée de l'iceberg. La transparence, le retour d'information et le cycle itératif et incrémental contribuent à identifier au plus vite les obstacles.

Révéler les freins à la productivité est un test pour l'organisation. Aura t-elle la maturité et le recul pour accepter ces obstacles en son sein? N'est-il pas plus confortable à court terme de revenir à une ancienne démarche et de se rassurer en pensant que tout va bien pour le moment?

Au sein d'une même organisation, considérons deux projets. L'un travaille en cycle en V alors alors que l'autre avance en agile. Immanquablement, le deuxième projet révèlera plus tôt des difficultés. Quelle conclusion hâtive est si aisée?

Comme j'ai déjà eu l'occasion de le dire lors d'un précédant billet, nous avons déjà vécu cette situation. Sur un projet d'envergure, nous avancions en mode eXtreme-Programming au sein d'un programme plus large travaillant en cycle en V. A l'époque, on nous a reproché de révéler trop tôt et trop fréquemment des problèmes. Notre équipe dénotait car elle butait déjà sur des obstacles. Notre organisation n'avait probablement pas la capacité de reconnaitre que nous déterrions tôt certains problèmes en son sein.

De même, lorsque tôt dans le projet les mesures de vélocité montrent que le produit ne pourra être livré à la date anticipée, l'organisation sera tentée de penser que l'équipe est inefficace alors qu'elle ne fait que révéler tôt que le planning initial est intenable sans réorganisation. Alors, plusieurs choix sont possibles: refuser d'admettre les faits, trouver une organisation projet mieux adaptée, revenir à une ancienne démarche de travail ou exiger une plus grande vélocité, ce qui se fera immanquablement au détriment de la qualité et donc de la date de livraison.

Face à une telle situation, l'organisation doit décider si elle veut agir sur le problème ou sur ce qui a révélé le problème. Accepte t-elle de voir la partie immergée de l'iceberg? En effet, l'organisation passe un test de maturité.