Accelerate

Construire et faire grandir des organisations technologiques performantes

Agile, Livre
Accelerate
Sommaire

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égorie 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 (DevSevOps)
  8. Continuous delivery (CD)

Architecture

  1. Loosely coupled architecture
  2. Empowered teams

B. Pratiques managériales

Lean Management & Monitoring

  1. Lightweigth change approval processes
  2. Monitoring
  3. Work in Porgress (WIP) limits
  4. Visualizing work

Culture

  1. Supporting learning
  2. Collaboration among teams
  3. Job satisfaction
  4. Transformational leadership

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

La difficulté dans tout travail de mesure est de transposer en nombre le qualitatif plutôt que le quantitatif. Le livre démontre que la façon de dépasser cette difficulté, est de positionner directement la vitesse d’adaptation de l’organisation au marché, et donc la capacité à répondre rapidement au changement est déterminante. De là en découle directement certaines métriques clés:

  • lead time: Il s’agit d’un indicateur déjà bien connu des kanbanistes, mais avec quelques nuances et complexités contextuelles. Aussi je le définis de façon générique au début, par le temps complet entre une demande client et sa résolution du point de vue du client. Bien sûr selon le contexte, la nature des demandes, le service ou le produit ne seront pas les mêmes et il conviendra de définir les éléments de changement et relever les dates de début et fin pour mesurer l’évolution de ce délai agrégée ou par classe de service.

  • deployment frequency : Fréquence de déploiement des éléments de valeur en production. Une volonté d’accroître cette fréquence conduit non seulement à une capacité à livrer plus de valeur aux utilisateurs, mais demande surtout à optimiser le flux global de production.

  • mean time to restore (MTTR) ou repair : Il ne s’agit plus de compter la quantité de défauts mais de diminuer leur temps de résolution. Ce décalage engendre un changement culturel qui vise à coopérer et anticiper pour diminuer ses temps, et limiter les impacts de l’incertitude tant en l’acceptant.

  • change fail percentage : mesurer le pourcentage de changement en erreur. Cette métrique lève un des freins au changement cible du devops. Le plus sûr moyen de diminuer ce pourcentage d’erreur est de réaliser de petits changements maîtrisés, plutôt que de gros changements, nécessairement plus risqués.

Références

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.