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
3 commentaires:
Sans remettre en cause ce que tu dis, je pense qu'il faut faire très attention au message que nous portons (nous les agilistes) sur la nécessité de transformation de l'organisation d'une entreprise.
Il a fallu parfois des 10aines d'années à une entreprise pour définir et mettre en place une organisation "optimum", et cela bien que l'organisation change tous les ans. Il est donc nécessaire de laisser du temps à l'entreprise pour "digérer" l'approche agile, constater ses bénéfices, puis, enfin, décider de changer son organisation pour être encore plus efficace.
En résumé, le changement d'organisation n'est pas un pré-requis à la mise en place de l'agilité ... juste une conséquence à plus ou moins long terme :)
Je suis en phase avec toi, on ne peut pas tout changer et plus une structure est "grosse", plus il faudra de temps pour la changer : néanmoins, il est vrai que je préfère naturellement prévenir que guérir, au risque peut-être d'effrayer?
Oui, évolution ou révolution ?
Je pense peut-être paradoxalement que l'évolution est plus difficile à mener.
Les acteurs gèrent leurs inquiétudes en cherchant à se rattacher à des repères (typiquement des modèles, des ratios etc) ce qui n'aide pas à clarifier les processus agiles.
En basculant sur un jeu de nouvelles références, on donne la capacité à bâtir le nouveau modèle plus proprement. Il n'y a pas d'autre choix que de regarder ce qui marche, ce qui ne marche pas, ce qui peut servir de mesure...et on apprend à travailler équipe et en confiance.
Il n'est bien sur pas question de changer totalement l'organisation de l'entreprise en amont mais il faut que la structure qui sert de pilote à l'agilité bascule totalement.
Cela nécessite un "Janus" capable de faire le lien entre les 2 mondes. C'est la principale difficulté.
Enregistrer un commentaire