Accelerate

Le livre faisait déjà l’objet du Klub de lecture Agile Toulouse du lundi 28 mai 2018, de suite après sa sortie en mars.

Nous l’avions qualifié comme un ouvrage clé pour l’agilité des organisations, prouvant scientifiquement l’intérêt de pratiques techniques et de management prônées par les adeptes du devops ou de l’agilité.

Pourtant, il me semble qu’il soit passé un peu inaperçu dans la communauté, ou dans les entreprises occupées à implémenter des recettes organisationneles complètes au moins dans leur packaging pour répondre au sentiment d’urgence d’une transformation agile, ou à migrer leurs infrastructures et services dans le cloud au plus vite.

Voilà que plus de 2 ans plus tard, il réapparait sous forme de jeu, pour éclaircir nos idées, nous aider à prendre du recul sur ce à quoi prêter attention, peut-être pour mieux se réorganiser dans le bousculement lié à la pandémie ou simplement pour vulgariser l’approche et se former de façon ludique.

Nous reprenons dans cet article un récapitulatif des éléments essentiels du livre autour des intentions suivantes:

1. Comment observer et décrypter le fonctionnement d’une organisation technologique au regard de sa performance globale ?
2. Sur quels leviers appuyer pour en espérer quels bénéfices ?

C’est peut-être l’occasion d’écrire une série d’articles pour faciliter sur un domaine ou une compétence en particulier.

Mon intention est de me servir au mieux sur ces nouveaux savoirs pour aider les organisations que j’accompagne à définir et mettre en oeuvre leur stratégie de changement dans leur quête de performance. Il ne s’agira évidemment pas de définir un modèle idéal standard d’organisation avec un plan pour l’y conduire, mais plutôt de bien repartir des bases de l’observation factuelle d’une situation et de ses dynamiques complexes pour déterminer les rouages à ralentir, inverser ou accélérer et vivre l’expérience d’un meilleur chemin.

Ainsi, les questions essentielles que nous serions amenés à nous poser régulièrement dans le contexte particulier d’une organisation:

Quel est l’état de nos compétences au regard de ce schéma ?

Quelles sont celles que nous gagnerions à développer pour quels objectifs ?

et ensuite, sachant cela

Par quoi commencer dès demain et pour les prochaines semaines ?

Les 24 capacités en 5 catégories et 3 domaines

A. Le domaine des pratiques techniques

Product & Process

1. Customer feedback
2. Value stream
3. Working in small batches
4. Team experimentation

Continuous Delivery

1. Version Control
2. Deployment automation
3. Continuous Integration (CI)
4. Trunk-based development
5. Test automation
6. Test data management
7. Shift left on security (DevSecOps)
8. Continuous delivery (CD)

Architecture

1. Loosely coupled architecture
2. Empowered teams

B. Pratiques managériales

Lean Management & Monitoring

1. Lightweight change approval processes
2. Monitoring and alerting
3. Work in Progress (WIP) limits
4. Visualizing work
5. Database management

Culture

1. Supporting learning and development
2. Collaboration among teams
3. Job satisfaction and retention
4. Transformational leadership
5. Organizational diversity and inclusion

Les 4 métriques clés pour l’amélioration de la performance des organisations de développement logiciel

Le positionnement des métriques : Stabilité vs Changement

Accelerate positionne les 4 métriques clés selon deux dimensions fondamentales :

Cette matrice révèle une compréhension profonde : une organisation de haute performance doit exceller à la fois sur la stabilité (réduire les défauts et les temps de récupération) ET sur la capacité au changement (déployer rapidement et fréquemment).

Ces deux dimensions, souvent présentées comme contradictoires dans les approches traditionnelles, sont en réalité complémentaires et mutuellement renforçantes. Les pratiques de DevOps et de Continuous Delivery créent un cycle vertueux où :

• Les petits changements fréquents = moins de risque = moins d’erreurs
• Les outils d’automatisation = déploiements plus rapides ET récupération plus rapide en cas de problème
• La culture collaborative = meilleure anticipation des problèmes

Les 4 métriques expliquées

1. Lead Time (Temps de mise en production - Dimension Changement/Durée)

Il s’agit du temps complet entre une demande client et sa mise à disposition du point de vue du client. Cette métrique capture l’agilité globale de l’organisation.

• Mesure : Temps entre le début de travail et la mise en production
• Pourquoi : C’est l’indicateur que les clients ressentent vraiment
• Implication : Force à optimiser le flux global de production (goulots d’étranglement)

2. Deployment Frequency (Fréquence de déploiement - Dimension Changement/Fréquence)

Capacité à déployer régulièrement des éléments de valeur en production. Une volonté d’accroître cette fréquence conduit à optimiser le flux et à réduire la taille des changements.

• Mesure : Nombre de déploiements en production par jour/semaine/mois
• Pourquoi : Déployer plus souvent signifie que chaque déploiement est plus petit et moins risqué
• Bénéfice : Meilleure réactivité aux besoins du marché, apprentissage plus rapide

3. Mean Time To Restore (MTTR) (Temps moyen de récupération - Dimension Stabilité/Fréquence)

Plutôt que de compter la quantité de défauts, cette métrique mesure la rapidité de résolution quand un problème se produit.

• Mesure : Temps entre la détection d’un incident et sa résolution
• Pourquoi : L’important n’est pas d’éviter tous les problèmes (impossible), mais de réagir vite
• Implication : Nécessite une excellente observabilité (monitoring/alerting) et une culture d’équipe forte
• Impact culturel : Passe de “faire parfait du premier coup” à “détecter et corriger rapidement”

4. Change Fail Percentage (Taux d’erreur des changements - Dimension Stabilité/Durée)

Mesure le pourcentage de changements en erreur qui nécessitent un rollback ou une correction.

• Mesure : (Nombre de changements échoués / Nombre total de changements) × 100
• Pourquoi : Directement lié à la qualité et à la confiance dans les processus
• Levier de réduction : Réaliser de petits changements maîtrisés plutôt que de gros changements
• Paradoxe : Déployer plus souvent RÉDUIT le taux d’erreur (changements plus petits = plus testables)

Le cycle vertueux de la performance

Automatisation → Déploiements fréquents → Changements petits → Moins d'erreurs
                                                ↓
                    → Récupération rapide possible (MTTR bas)
                                                ↓
                    → Confiance pour déployer encore plus souvent

La vraie performance en DevOps ne vient pas de faire SOIT de la stabilité, SOIT du changement, mais de créer un système où les deux s’amplifient mutuellement.

Quiz Accelerate - 20 Questions Essentielles

Testez votre compréhension des principes clés d’Accelerate :

Références

• Le livre Accelerate avec quelques extra-materials intéressants: https://itrevolution.com/book/accelerate/

• Découvrez Accelerate DevOps par Coach agile

Quelques notes de réflexion à poursuivre

L’apparente simplicité du schéma global Accelerate ne masque pas la difficulté de mise en oeuvre des idées d’amélioration qui peuvent en émerger. Des plans d’actions peuvent venir en complément et parfois en concurrence des implémentations de schémas organisationels en vigueur.

Illustration de la difficulté de mesurer le lead time:

Il convient de commencer par isoler le flux principal de création de valeur en identifiant les éléments porteurs de changement significatifs de ce point de vue. Il fautdrait donc que ces éléments portent un changement “business” visible du point de vue du client et un changement “technique” du point de vue des équipes chargées de modifier les systèmes opérés. A défaut de systèmes ou produits, il s’agirait de rendre un service au travers d’un processus.

Ensuite, pour mesurer un délai, nous pouvons considérer comme date de début le moment où l’on décide qu’il y a un bien un changement à opérer sur le système et comme date de fin le moment où le changement est effectivement dans les mains de l’utilisateur final et qu’il peut l’apprécier. Cette définition sépare en 2 classes les activités d’analyse et diagnostic d’une demande, de celles de la modification proprement dite, pour ne pas mélanger les choux et les carottes. Si l’on poursuit la démarche analytique, on en vient généralement comme de nombreuses organisations l’ont fait en suivant des référentiels comme ITIL, à classifier les niveaux de support et maintenance avec pour chacun, des indicateurs de services appropriés pour la gestion des incidents, des anomalies, des modifications, des problèmes, des changements. Il ne s’agit pas de remettre en cause ces modèles, mais comme ils le prônent souvent eux-mêmes de remettre en perspective les réels besoins et les options stratégiques et tactiques au bon niveau d’échelle pour gagner en performance globale. C’est un peu toujours la même histoire des optimums globaux versus les optimums locaux.

En tant qu’agent du changement, la problématique se situe dans la difficulté de bien prendre en compte, comprendre et valoriser l’existant, afin de permettre au client de mieux s’en détacher lui-même au regard de ce qu’il souhaite plus encore que le status quo.