Est ce important de différencier ces deux termes ? Ces deux concepts ?
- Pour moi, l’agilité à l’échelle (1), c’est d’avoir beaucoup de teams agiles.
- Et l’agilité d’entreprise (2), c’est avoir une (super)structure d’entreprise qui est agile .
Ce sont deux axes différents , et en même temps, interdépendants.
Quelles questions ?
Le premier répond à la question :
“Comment passe t-on d’une pratique artisanale avec quelques pionniers, à une pratique collaborative et généralisée de l’agile. »
Le deuxième point répond à la question :
“Comment je fais pour que ma pyramide de contrôle soit la plus aidante et soutenante possible, ou au mieux, la moins dérangeante possible. Qu’elle « collabore à » plutôt qu’elle ne freine l’agilité.
Quelles implications ?
Le premier point implique bien sur la quantité de teams agiles, mais aussi la qualité de collaboration coopérative 1 2
- Pour illustrer : si vous avez 50 teams, vous voulez éviter d’avoir 50 pratique différentes, incompatibles, avec 50 tool set , framework, usine logiciels, etc , tous différents ou presque.
- ( et la tentation de l’uniformisation 3 n’est pas une réponse valable non plus; vu l’évolution technologique en cours, c’est la sidération assurée)sinon, et si on considère le turnover moyen du dev sur paris de 2 ans, vous risquez de passer votre temps a faire le pompier d un projet à l autre rapidement.
Le deuxième point implique une réforme post industrielle de la structure de pilotage.
Dis comme ça, ça a l’air “violent”. En même temps, les pratiques existantes du contrôle de gestion, des fiches de poste du RH, et le budget annuel, sont juste des exemples de freins , de ce qui va empêcher votre agile de monter en maturité 4 .
Citons aussi la qualité de communication de votre codir ( plus souvent compétitif que collaboratif) , sa capacité de se changer lui même en plus de demander aux autres de changer ( cela peut se mesurer) , sa capacité à créer une vision et embarquer un maximum de son écosystème interne et externe dans sa création de vision
Quelle conclusion ?
La combinaison des deux va permettre de créer une entreprise réellement collaborative et agile.
N’achever que le premier va donner une pyramide de contrôle classique avec des features team qui tournent un peu plus vite, mais ça n’empêchera pas votre entreprise de louper un tournant (celui de la digitalisation ou du cloud par exemple) , et d’aller dans le mur – plus vite certes.
La montée en maturité agile s’arrêtera de toute façon si le management stratégique et opérationnel ne se transforme pas, et les niveaux de maturité “collaboratifs” sont nécessaires pour le passage à l’échelle.
Ça donnera , comme dans beaucoup d’entreprises malheureusement, des “incantations agiles”, fort à la mode en ce moment.
Merci à Fred et a Christophe pour la question à l’origine de cette clarification.
Aller plus loin :
Status : Text : final, Image: a insérer; Ref a compléter
- Voir qualité de collaboration : cooperative ↩
- Monter la quantité de team agile sans monter le niveau de collaboration, c’est augmenter le nombre de team qui vont vers l indépendance, donc l’ entropie, le chaos en entreprise. ↩
- En couleur de spirale, l’uniformisaiton est bleue, et la collaboration (des teams) est jaune-turquoise, on mesure le gap ! ↩
- Voir la présentation de hashicorp ↩
