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
