La stabilité d’abord… La vitesse ensuite !

[((/dotclear/public/logos/.versionone_logo_t.jpg|Logo VersionOne|L|Logo VersionOne))|/dotclear/public/logos/versionone_logo.jpg]Récemment, j’ai eu une conversation sur la vélocité avec mon collègue Jean-François M. Cela m’a donné envie de traduire le billet de Mike Cottmeyer : ++[Stability first… then speed!|http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed|en]++ publié sur le blog de VersionOne.%%% %%% > Beaucoup de gens souhaitent appuyer sur un bouton et magiquement devenir agile. Ils désirent bénéficier de tous les avantages sans avoir à fournir le gigantesque effort qui accompagne la transformation réelle de l’organisation. Les gens pensent que parce qu’ils lisent juste un livre … ou ont pris quelques jours de formation … qu’ils peuvent s’attendre à une productivité instantanée. Ils ne réalisent pas que les méthodes agiles vous montrent uniquement vos problèmes… c’est encore à vous de les régler…%%% > %%% > Je vais souvent voir cet a priori se manifester sous forme de questions du style « au bout de combien d’itérations puis-je espérer que la vélocité de mon équipe commence à augmenter ? ». Il y a tellement de paramètres en jeu qu’il est difficile de répondre à une telle question. Y-a-t-il un Product Backlog priorisé ? Y-a-t-il un Product Owner affinant le backlog à disposition de l’équipe ? L’équipe est-elle multi-compétentes ? Sont-ils dédiés au projet ? Ont-ils tout ce dont ils ont besoin pour réussir ? Y-a-t-il des dépendances externes ?%%% > %%% > Toutes ces choses posent problème … et vous n’êtes pas sûr de l’impact que la réponse aura sur la capacité de l’équipe à livrer.%%% > %%% > Ma recommandation est généralement de considérer la performance de l’équipe en trois phases. Le premier objectif est de mesurer la performance actuelle … pour établir une référence. Puis, réfléchir à comment stabiliser ce niveau de performance… un niveau de performance stable est essentiel à l’exécution d’un projet agile dans des conditions prévisibles. Une fois que vous êtes stables … maintenant vous pouvez commencer à réfléchir à comment aller de plus en plus vite. Adopter l’Agile est un processus d’apprentissage et vous ne pouvez pas améliorer un système lorsque vous ne comprenez pas ce qui est en panne dans ce système.%%% > %%% > Et c’est vraiment la clé … Il ne s’agit pas d’obtenir une meilleure vélocité. Il s’agit de réparer les parties « en panne » dans votre organisation. Il s’agit d’examiner votre situation et de la confronter à la situation dans laquelle vous souhaiteriez vraiment être. Il s’agit de comprendre les obstacles qui sont sur votre chemin et les traiter de manière significative … d’une manière qui permet vraiment réellement d’aider l’équipe à s’améliorer. Il s’agit de devenir plus efficace dans la création de valeur et d’améliorer réellement les processus qui permettent de créer de la valeur.%%% > %%% > Ce genre de réponses ne se traduit pas dans un baratin marketing. Combien de temps faut-il pour devenir agile ? Je ne sais pas … combien d’itérations cela va-t-il prendre pour supprimer les obstacles organisationnels qui freinent l’équipe ? Combien d’itérations faudra-t-il jusqu’à ce que vous soyez prêt à réparer ce qui est vraiment en panne ? Combien d’itérations jusqu’à ce que nous soyons prêts à cesser de poser des étiquettes partout et à VRAIMENT commencer à transformer l’organisation ?%%%

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *