Lecon apprise n°2 - Adapter la structure

Deuxième billet sur mes leçons apprises lors d'une expérience de 4 ans d'application de Scrum/XP chez un éditeur de logiciel à Grenoble. Avant, je veux clarifier le terme "structure". Ce que je veux dire par "structure" c'est la cartographie de l'organisation en terme d'organigramme : la pyramide hiérarchique ou chaîne de commandement... on oppose souvent l'approche projet à cette structure pyramidale. En approche projet, on va travailler en mode transverse à de nombreux départements ou services.

Constat

En agile, les choses deviennent pire : on veut créer des équipes dédiées pluri-disciplinaires. De nouveaux rôles transverses apparaissent et on a du mal à les placer sur l'organigramme de l'organisation. A l'inverse des rôles existants se voient "dépouiller" de leurs activités du fait du changement de méthode. Dans notre cas, à l'époque, les chef de projets, responsables d'équipe et leaders techniques (architectes) ont eu beaucoup de difficultés à faire "leur trou" dans cette nouvelle façon de travailler. Le fait d'avoir conserver un grand moment une structure de l'entreprise inadaptée, cela a nuit au bon déroulement de la transition. Je n'ai jamais compris pourquoi cela semblait si compliqué de modifier la structure en place.

Pistes d'amélioration

• Ne pas attendre pour introduire (valoriser) les nouveaux rôles dans la structure de l'organisation
• Adapter ou supprimer la définition des rôles existants si ils sont obsolètes
  
• S'appuyer sur une description processus/responsabilité plutôt que structure/autorité
• Dans une approche processus, le rôle de ScrumMaster prend tout son sens : c'est le gardien ou le pilote du processus, à l'échelle d'un projet, d'une équipe
• Maintenir un backlog de transition agile pour y consigner justement les adaptations de structure à conduire
• Impliquer la RH le plus tôt possible dans la transition car le système de mesure de la performance individuel doit être adapté à cette nouvelle façon de travailler
  

Leçon apprise n°1 - Transition en douceur

Un mois déjà depuis mon dernier billet : je me ressaisis en entamant une série de 5 ou 6 billets sur les leçons que j'ai apprises durant ces dernières années d'accompagnement agile à Grenoble.

Leçon apprise n°1 - Transition en douceur

La transition vers l'agilité à laquelle j'avais assisté et dont j'étais aussi acteur, fut menée en mode "big-bang" : du jour au lendemain, tous les projets de l'entreprise furent gérés en Scrum. Le travail de préparation avait essentiellement porté sur des études de livres et la recherche de prestataires en formation et conseil agile. Nous avions organisé une grande réunion (ou plutôt une grande messe) pour expliquer les changements imminents et les raisons de ce changement. Je ne remets pas en cause ce que nous avions fait, mais je pense que nous manquions de maturité sur la gestion du changement à l'échelle de l'entreprise, et surtout sur les individus. Nous n'aimons pas changer quand quelqu'un décide à notre place, mais nous aimons changer si cette décision vient de nous... à méditer ;-)

J'aime l'image du lièvre et de la tortue : ne pas confondre vitesse et précipitation. Vouloir tout changer c'est bien mais savoir aider les autres à changer c'est mieux. La majorité des personnes veulent mieux faire, veulent s'améliorer et si elles vous paraissent hermétiques au changement, c'est que le problème ne vient pas forcément d'elles mais peut-être de de votre façon de leur parler et de les écouter.

Les bonnes pratique que je vois pour une transition en douceur sont les suivantes:

• Impliquer un maximum de personne dans la décision de changer (et pas seulement le management et la direction)
  
• Présenter ce changement "possible" à tout le monde (formation, ateliers...) avant de démarrer
  
• Commencer avec UN projet pilote avec LES personnes qui souhaitent changer
• Etre attentif aux arguments des personnes qui ne veulent pas changer et les entendre
• Gérér formellement un "backlog" de transition en toute transparence en y agrégeant les idées de tous
• Identifier une équipe en charge de ce "backlog"

Au final, on constate que pour démarrer, on a pas besoin d'avoir tout le monde d'accord : c'est une bonne nouvelle : une équipe motivée et un projet, ça suffit ;-)