Débloquez les facteurs clés de succès pour vos initiatives DevOps !
Les 7 dimensions d’une initiative DevOps
Pourquoi proposer un nouveau modèle ? Est-ce réinventer la roue ?
Dès que l’on voit un article présentant un nouveau modèle, ces questions se posent légitimement. Avant de concevoir ce modèle en 7 dimensions, j’ai étudié ceux proposés par des frameworks ou des cabinets de conseil. Il en existe de nombreux élaborés selon différentes perspectives (Lean, Digital, Engineering, Leadership, Management…), chacun venant avec son vocabulaire.
Ne trouvant pas de modèle correspondant à mes propres expériences, je me suis résolu à concevoir un modèle holistique couvrant les différentes facettes d’une initiative de transformation DevOps.
Un modèle holistique des facettes d’une transformation DevOps
Le modèle couvre à la fois les leviers opérationnels (Personnes, Processus et Technologies) et les leviers managériaux (Organisation et Amélioration).
Il positionne clairement le rôle clé du Leadership au cœur de l’impulsion d’une telle initiative, les aspects Culturels comme fondations de l’ensemble des dimensions, et les Résultats comme guides sur lesquels aligner l’ensemble de la démarche.
Le modèle résulte également de choix de représentations visuelles:
- La forme circulaire pour symboliser une vue holistique à 360° des dimensions ;
- La métaphore photographique pour se focaliser sur les dimensions importantes en fonction de chaque contexte.
Les principes Lean pour créer la dynamique d’amélioration continue
Si les dimensions apportent une vision holistique d’une initiative, la clé du succès réside dans la dynamique d’amélioration continue !
Afin d’élaborer puis mettre en œuvre leur vision, les leaders d'initiatives DevOps peuvent s’appuyer sur le cycle des cinq principes de la pensée lean :
- Spécifier la valeur pour les clients et les résultats à atteindre;
- Identifier et cartographier les chaînes de valeur impliquant de multiples fonctions de l’organisation;
- Etablir un flux de travail fluide en améliorant les processus, s'appuyant sur les technologies et en développant les compétences des équipes;
- Tirer le flux à partir de besoins réels clients et de leur feedback;
- Progresser pas à pas vers la perfection afin que le nombre d’étapes et le temps pour servir les clients s’améliorent continuellement.
Un modèle pour se recentrer sur ce qui compte vraiment
Même si elles apportent de réels avantages, les initiatives de transformation (agilité, DevOps/DevSecOps, SRE, etc.) ne parviennent pas toujours à démontrer leurs effets sur la valeur réalisée par les clients et leur impact sur les résultats commerciaux de l'entreprise.
« Notre conviction est que les acteurs des chaînes de « Software Delivery » peuvent appliquer les principes lean pour se recentrer sur ce qui compte vraiment dans leur contexte spécifique. »
Deux caractéristiques et raisons principales d’adopter une approche lean :
- Se focaliser sur la satisfaction client afin d'aligner toutes les parties prenantes sur une vision commune et les objectifs de l'entreprise;
- Combiner les dimensions techniques et humaines dans une approche systémique, plutôt que de se focaliser sur la mise en œuvre technologique et les optimisations locales au sein de chaque groupe spécialisé.
En fonction de sa situation et de ses besoins spécifiques, une organisation peut avoir besoin de passer de pratiques traditionnelles à des pratiques modernes de "Software Delivery". Le tableau récapitulatif ci-dessous présente les principales tendances observées sur chacune des dimensions :
Adopter une approche scientifique pour progresser pas à pas
Il serait illusoire de penser qu’une seule dimension peut tout résoudre ou qu’il suffit d’identifier la première ou la plus importante.
« Toutes les dimensions sont interconnectées et forment un système socio-technique complexe. »
La méthode pour réduire cette complexité est d’avancer par petits pas, poser des hypothèses, traiter un problème à la fois, mesurer les résultats et les confronter à l’hypothèse de départ, c’est-à-dire adopter une approche scientifique de résolution de problème.
Conclusion
Ce modèle a été développé faute de trouver une description des dimensions vécues sur des initiatives DevOps.
Si jamais vous avez connaissance d’autres modèles équivalents, n’hésitez-pas à les indiquer en commentaires ou à me contacter (pcorbard@sdrefocus.com).
Cet exercice de modélisation a également le mérite d’aider à clarifier l’approche visant à aider les clients de SD ReFocus dans leurs initiatives. Le modèle a déjà évolué et continuera probablement de le faire avec l'utilisation, les feedbacks et nos disciplines.
Enfin, ce modèle semble suffisamment générique pour pouvoir être appliqué à d’autres initiatives de transformation.