Agile Rocket

Guide

v1.1

Guide pour un voyage exploratoire agile & modulaire

Écrit par un collectif de cinq auteurs lors d’un booksprint de quatre jours à Carnac fin 2016

Table des matières

Avant-propos

Raconte-moi une fusée agile

Comment lire ce livre ?

North Star : embarquement immédiat

Partie 1 : les modules de la fusée

Management visuel

Amélioration continue

Flux

Partie 2 : les stabilisateurs de vol

Management agile

Maîtrise personnelle

Partie 3 : les boucliers thermiques

Culture produit

Excellence de l'ingénierie

La culture agile : propulseur vers la réussite

Les (étroits) boooksketaires

Bonus :

L’Agile Rocket à travers les âges

Avant-propos

Nos lecteurs ?

Description de nos lecteurs sous forme de personas

Kouigna Man : Gooodien

Je fais partie de la société Goood! et j’aimerais pouvoir m’appuyer sur une démarche simple et structurée pour pouvoir monter en compétence. De plus, si elle me permet de développer un savoir-faire et une culture partagés avec mes collègues, cela contribuera à renforcer notre état d’esprit d’entreprise !

Jean-Noël : Décideur

J’ai des besoins en transformation, mais je suis perdu dans toutes les offres du marché. J’ai envie de comprendre comment cette démarche se déploie et en quoi elle peut m’être utile. De plus, je n’ai pas envie de me lancer dans un engrenage que je ne maîtriserai pas. Je préfèrerais au contraire avoir la possibilité de pouvoir adapter la démarche selon mes besoins !

Ernestette : Membre d’équipe

Ce n’est pas la première fois que l’on me demande de changer. J’ai besoin de comprendre là où on m’emmène, comment je vais être impactée et surtout ce que j’ai à y gagner ! Si je pouvais savoir à l’avance ce que l’on va me demander de faire et comprendre pourquoi c’est important, cela me rassurerait !

Cathy : Manager

Malgré tout l’intérêt que je vois aux démarches de transformation, elles prennent du temps. J’ai besoin de connaître l’effort et le temps qui va être demandé à mes équipes ainsi qu’à moi-même. J’entends souvent parler d’agilité et d’auto-organisation, mais quel est mon rôle dans tout ça ?

Milouz : Coach / Consultant

Je suis Coach Agile et j’aimerais avoir une alternative d’accompagnement plus légère. J’en ai un peu marre de faire du Scrum ou du Kanban, ce qui m’importe est d’apporter une vraie démarche d’apprentissage aux équipes et aux organisations pour les aider à devenir actrices de leur transformation.

Autres profils

Aline est responsable d’une équipe transverse (Lean Analytics, QoS…), Jacques d’une équipe de maintenance (BaU), aucun des deux ne développe un produit. Tous deux souhaitent plus d’agilité dans leur activité. 

Leur premier besoin est de renforcer la collaboration dans leurs équipes mais conscients de l’évolution de leur métier, ils aimeraient aussi développer la réactivité et encourager la pluridisciplinarité. Ensuite, ils aimeraient que leurs équipes deviennent plus responsables, prennent en charge la gestion de leurs problèmes, soient force de proposition.

Un besoin d’agilité progressive et structurée

Comment manager l’auto-organisation ? Comment énergiser sans contraindre ? Comment respecter le rythme de l’équipe ? Comment structurer une démarche d’amélioration sans imposer une méthode ? Comment livrer plus vite sans travailler plus ? Comment satisfaire ses clients en anticipant leurs besoins ?

L’Agile Rocket Guide est pour nos “persona-lecteurs”, Jacques, Aline...et tous les autres, en quête d’une démarche alternative vers une agilité respectueuse, spécifique, modulaire et progressive.

Quels bénéfices retirer de la lecture de ce guide ?

La démarche proposée, découpée en modules, s’appuie sur une métaphore visuelle simple à appréhender.

Simple à communiquer en story-telling, elle est au service d'un projet agile de renforcement de la création de valeur.

Elle découpe l’accompagnement en modules courts, ce qui permet de mieux répartir l'effort en se focalisant sur des unités d'amélioration.

Elle abaisse aussi le ticket d'entrée (moins d'une semaine d'effort répartie sur une durée d’un mois pour la mise en place d’un management visuel).

Elle permet de différencier les efforts en fonction des contextes (évaluation de la maturité atteinte par module).

Elle insiste sur des dimensions habituellement négligées ou sous-évaluées, comme l'accompagnement des managers, l'optimisation du flux, la nécessité d’investir dans la maîtrise personnelle ou la culture produit.

Elle ne s'adresse pas qu'aux équipes de production, mais à l’ensemble de l’écosystème.

Elle est jaune avec des points noirs...ah non, ça c'est Agile Borat (@AgileBorat).

Christophe Keromen

Raconte-moi une fusée agile

La fin d’une époque

Lors des dernières décennies, les entreprises à la recherche de compétitivité ont mené une optimisation effrénée des ressources et des politiques drastiques de réduction de coûts. Cette démarche arrive aujourd’hui à son terme.

D’une part, parce qu’il n’y a plus rien à ronger sur l’os : les salariés sont surmenés, démotivés et stressés, les burn-out se multiplient.

D’autre part, parce que cela conduit les différentes entités à se replier sur l’optimisation locale. De la Business Unit qui ne vise que sa propre rentabilité, au développeur qui travaille en solo derrière son écran. Chaque rouage de l’organisation n’a plus la notion de l’appartenance, du bien commun. Chacun tente de se prémunir, d’éviter le blâme ou la surcharge de travail. Faute d’interdépendance, l’organisation n’apprend plus à s’adapter aux conditions toujours changeantes.

Conditionnés par leurs modèles mentaux, les dirigeants ne savent plus comment retrouver de la fluidité, de l’adaptabilité et de la capacité à innover. Désireux de fortifier leur résilience et en conjonction avec la miroitante digitalisation, Agile apparaît comme un mot magique qui résoudra tous les maux en adoptant de nouvelles pratiques, sans toutefois rien changer par ailleurs.  

Une métaphore pour raconter la transformation

La métaphore de l’Agile Rocket vise à guider progressivement le lecteur vers une meilleure compréhension de ce qu’est une démarche vers plus d’agilité, des problèmes auxquels nous tentons d’apporter des améliorations (faute de prétendre à LA solution) et des invitations à la transformation progressive que nous portons.

L’Agile Rocket

Toute transformation est un voyage vers l’inconnu (premier choc pour les modèles mentaux en quête de certitude et de prédictibilité). Faute de pouvoir définir avec certitude une destination, le sponsor de la transformation doit donner un cap. Pour notre fusée, ce sera The North Star (l’étoile du Nord^[1]).

La fusée comporte trois étages qui matérialisent une progression dans la maturité :

• le coach accompagne d’abord un groupe à devenir une équipe, en les aidant à construire et utiliser un management visuel représentatif de leur contexte ;

• si ce management visuel se révèle utile, utilisable et utilisé, l’équipe semble prête à monter en compétence sur les processus structurés d’amélioration continue ;

• si l’équipe mène correctement et régulièrement des expérimentations d’amélioration continue, le coach pourra les guider vers l’amélioration du flux de production de valeur.

Un risque majeur pour une fusée consiste à basculer au lancement ou à devenir incontrôlable en vol. Des stabilisateurs de vol^[2] sont nécessaires pour assurer la stabilité et la gouverne en tangage (profondeur) et en lacet (direction) :

• le premier stabilisateur de notre fusée est le management agile. Évolution de posture vers plus de leadership et moins de contrôle, capacité de faciliter le collectif, catalyseur d’intelligence relationnelle, les changements sont profonds. C’est le management qui assure l’équilibre collectif nécessaire entre auto-organisation et appartenance.

• le second stabilisateur est le développement de la maîtrise personnelle. Encourager le développement personnel vers plus de responsabilisation, savoir mieux travailler ensemble, faire place à l’intelligence émotionnelle et rechercher l’efficience, gage de pérennité, demandent un effort soutenu.

Deuxième risque important : la surchauffe ! Pour éviter cela, il convient de doter la fusée de solides boucliers thermiques.

• Le premier bouclier, la culture produit, protège du risque de perdre l’objectif qui est de produire de la valeur pour le client final. Alignant tous les efforts vers une préoccupation commune, elle maintient l’intégrité de l’engin.

• Le second bouclier, l'excellence de l’ingénierie, permet à la fusée de décoller et d’atterrir dans de bonnes conditions, en limitant les risques pour l’équipage. Obsession de la qualité intrinsèque, des tests et automatisation de toutes les étapes sont nécessaires.

Notre fusée aura besoin de carburant. Dans notre métaphore, la culture agile sera la source d’énergie de l’organisation.

Coacher une équipe ou un écosystème ?

“It’s not my problem.

The hole is in their side of the boat.”

Les commanditaires de coaching agile recherchent souvent un coach pour accompagner une équipe de développeurs.

Dans la mesure où beaucoup de ces équipes adoptent, du moins le prétendent, le cadre Scrum, le coach se retrouve souvent à effectuer une partie du travail du Scrum Master, rôle en charge du respect du processus. Cette situation bizarre a émergé au fil des années, sans doute en réponse au manque de Scrum Master expérimentés.

Ce coach qui se focalise sur l’équipe s’intercale entre celle-ci et la couche managériale, souvent sans accompagnement spécifique, suscitant incompréhension et rejet.

Enfin, d’un point de vue flux de valeur, l’optimisation seule de l’activité du sous-ensemble “développement’ est insuffisante pour optimiser l’ensemble. Il convient de s’intéresser au système dans son ensemble, “from concept to cash”, en tenant compte des différentes parties prenantes.

Dans notre approche, une équipe de coaches intervient pour améliorer le fonctionnement d’un système en accompagnant la transformation de l’activité d’un ensemble de personnes.

Pour toutes ces raisons, quand nous mentionnons coach, c’est une simplification pour éviter de répéter “équipe de coaches pluridisciplinaires”. Quand nous mentionnons équipe, c’est une simplification pour “parties prenantes du système”.

Comment lire ce livre ?

En décrivant la structure de la fusée agile, ce livre traite de transformation agile.

Vous pouvez le lire séquentiellement ce qui correspond à une mise en œuvre progressive ou étudier directement le module dont la problématique vous interpelle.

Le guide commence par une description du travail sur la vision du sponsor et l’embarquement de l’équipage :

North Star embarquement immédiat

Comment embarquer mon équipe vers un objectif partagé - inspirant - suscitant le rêve ?

Il propose ensuite trois parties :

• Partie 1 : les étages de la fusée

Management visuel

Comment s’appuyer sur le collectif pour prendre les bonnes décisions ?

“Allumer la lumière pour se focaliser sur les choses importantes et agir sur elles.” Yannick Quenech’du

Amélioration continue

Comment savoir que l’on se concentre sur les problèmes qui nous impactent le plus ? Quelle démarche utiliser pour résoudre et alléger les problèmes ?

Flux

Comment optimiser le flux de production de valeur, la prédictibilité de la livraison finale au client sans surcharger les équipes ?

• Partie 2 : les stabilisateurs de vol

Management agile

Comment le management peut-il soutenir le voyage de transformation agile ?

Maîtrise personnelle

Comment l’organisation peut-elle augmenter sa capacité d’adaptation et développer sa résilience ?

Comment passer de la réaction à la pro-action ?

Comment passer d’un focus sur l’individu à un focus sur le collectif ?

Comment passer de l’efficacité à l’efficience ?

• Partie 3 : Les boucliers thermiques

Culture produit

Comment faire le bon produit ?

“Il n’y a rien de plus inutile que de faire, avec une grande efficacité, quelque chose qui ne devrait pas être fait du tout”. Peter F.Drucker

Excellence de l'ingénierie

Comment garantir que l’on livre fréquemment en production du code de qualité qui répond au besoin de l’utilisateur ?

L’ouvrage se termine par le thème fédérateur qui énergise tout le reste :

La culture agile : propulseur vers la réussite

Que changer ? Par où commencer ?  Est-il suffisant d’adopter un jeu de bonnes pratiques ?

Restera à donner sens à tout cela
dans votre propre contexte…

Partie 1 : 

les étages de la fusée

North Star : embarquement immédiat !

On ne construit pas une fusée sans avoir une destination qui suscite le rêve.

Hergé a bercé la jeunesse de pas mal d’entre-nous avec “Objectif Lune”. Peut-être l’Agile Rocket trouve-t-elle là son origine ?

Tintin devant sa fusée (https://flic.kr/p/nfjyFS)

Kennedy motivait l’Amérique des années 60 et de la guerre froide avec sa vision :

L’intention de ce module est d’abord de poser la vision. Restera à la partager avec l’ensemble des acteurs pour susciter leur désir de voyage : embarquement immédiat !

Description de la démarche

Déroulement

La démarche s’initialise par un travail en parallèle avec le sponsor (vision) et les équipiers (mission et voix de l’équipe). Le résultat des sessions préliminaires est ensuite partagé et discuté lors d’une demi-journée de lancement de l’aventure (kick-off).

Charge et déroulement de la phase initiale

La vision

La construction de l’Agile Rocket démarre avec l’élaboration de la vision. Quelle est la destination du voyage dans lequel nous embarquons les équipes ?

Le coach aide le sponsor et les top-managers à affiner cette vision et à la rendre inspirante pour l’équipage de la fusée. En effet, trop souvent la transformation est présentée comme une fin en soi : aidez-nous à mettre en place l’agilité, listez-nous les bonnes pratiques à mettre en œuvre, donnez-nous des exemples de ce qui se passe ailleurs…

Dans la métaphore de l’Agile Rocket, l'agilité n’est que le véhicule ambitieux permettant à l’organisation de s’arracher à la pesanteur terrestre des anciennes manières de fonctionner pour aller explorer de nouveaux espaces.

Cette destination est propre à l’entreprise, à sa raison d’être, à son histoire, à son contexte. Une fois cette destination clairement définie et partagée, le coach peut aider l’organisation et ses membres à construire la fusée la plus adaptée. Il apporte pour cela son savoir-faire en intelligence collective, son expérience de mise en œuvre de l’agilité, mais en aucun cas des plans définitifs construits avec des solutions en prêt-à-porter.

Dans les démarches Lean^[3], la vision est appelée “True North”. Dans notre métaphore intersidérale, nous parlerons de “North Star”, l’étoile du Nord qui guide le voyage exploratoire.

Élaborer la vision

Quelques concepts structurent la notion de vision :

• la vision se travaille, se raffine, évolue ;
• exprimer la vision ne suffit pas, écouter n’est pas adhérer, il faut pouvoir toucher les auditeurs ;
• une vision n’est pas rationnelle, sa force repose sur son pouvoir évocateur, sa capacité à susciter de l’émotion.

Notre travail sur l’élaboration de la vision est inspiré par deux grands maîtres.

Peter Senge, auteur de la 5ème discipline, cite trois questions essentielles pour une bonne vision :

• Qu’est-ce que je veux amener à la réalité ?
• Quelles sont les réalisations qui comptent vraiment pour moi ?
• Que voulons-nous réaliser ?

Et il met en garde :

“En fin de journée, demandez-vous :

Comment notre vision et les valeurs ont influencé les décisions que j’ai prises aujourd’hui ?

Si ce n’est pas le cas, elles relèvent sans doute alors plus du bullshit.“

Autre mentor : Robert Dilts, auteur entre autres du concept des niveaux logiques^[4].

Robert mentionne trois qualités essentielles pour une vision inspirante :

• claire - connue - concise;
• ressentie - expression d’une passion (pas une simple information);
• doit toucher les autres de façon authentique, au-delà des mots.

Quelques définitions pour guider la réflexion :

Préparer l’équipage

Il s’agit d’aider les participants à élaborer leur propre réponse à la question : “What’s in it for me?”^[5]

Si dans un premier temps, le coach a accompagné le sponsor à affiner l’expression de sa vision, il travaille en parallèle à élaborer une représentation partagée de la mission de l’équipage avec l’ensemble des personnes concernées.

Ex d’incréments de définition collective de la mission de l’équipe

Une fois le consensus obtenu, le coach propose à l’équipage de s’exprimer sur les frustrations rencontrées dans l’accomplissement de sa mission. Plusieurs ateliers sont possibles.

Le team’s healthcheck permet de déclencher des discussions génératives de pistes d’améliorations potentielles pour les participants.

Ex. de résultat obtenu par un atelier team’s healthcheck

Un format comme le speed boat est également une valeur sûre pour identifier les forces et faiblesses du contexte.

Équipe en cours de présentation de son Speed Boat

S’il existe une tension forte entre la couche managériale et les équipes, l’atelier Delegation Board, issu du Management 3.0, se révélera propice à expliciter les responsabilités et les besoins de délégation.

Ces ateliers sont, dès le départ, l’occasion d’installer le climat de transparence, d’échange et de pragmatisme qui permettra le travail collaboratif. Ce sont également des outils d’évaluation que le coach met à disposition des équipes pour leur permettre de suivre l’évolution de leur contexte sur différents plans : qualité de l’environnement, délégation de responsabilité et de prise de décision, empêchements à faire…

Évaluation du contexte

Suivant le contexte propre à l’équipe, le voyage agile sera plus ou moins facile à initier. Voici quelques questions qui peuvent aider à mieux appréhender ce contexte :

Lancement de l’aventure : encourager le dialogue

Lors du kick-off, managers et équipes sont réunis pour mettre en commun les productions des ateliers préparatoires. C’est le moment de construire des dialogues porteurs de solutions d’améliorations. Le coach veille à l’écoute réciproque, au climat de bienveillance, à la liberté de prise de parole et à conserver des échanges positifs.

La session peut se terminer par la signature de chacun, matérialisation d’un engagement à participer au voyage et au bon fonctionnement de la fusée, ouvrage collectif.

Les impressions des participants peuvent être recueillis sur une Feedback Door : qu’avez-vous apprécié dans cette session ?

Ex. de feedback Door

Ex. de feedbacks recueillis après une session de partage de la vision

Exemples d’atelier

• L’atelier 3F de Robert Dilts : “Frame It - Feel It - Free It”
• Le travail avec les niveaux logiques de Robert Dilts : http://www.kolibricoaching.com/management-durable/niveaux-logiques-robert-dilts_gregory_bateson/ 
• L’utilisation du photolangage pour se connecter à son imaginaire et le traduire ensuite en phrases : http://www.visualsspeak.com/

• Feedback Door - recueil en direct des feedbacks des participants à un atelier : http://noop.nl/2011/04/the-feedback-door.html

• Delegation Board : https://management30.com/practice/delegation-board/
• Team’s healthcheck : https://labs.spotify.com/2014/09/16/squad-health-check-model/ 
• Speed Boat : http://www.innovationgames.com/speed-boat/

Bibliographie

• La 5ème discipline de Peter Senge : http://www.solfrance.org/la-cinquieme-discipline/
• Leadership visionnaire de Robert Dilts : http://www.institut-repere.com/LIVRES-ET-DVD/institut-repere-leadership-visionnaire.html
• Petit Guide de Lean Management à l'Usage des Équipes Agiles : http://leanagilecamp.fr/

Liens

• La vision de Kenney : http://www.clintburdett.com/process/11_documents/documents_01_3_jfk_vision.htm

Management visuel

Exemples d’insatisfactions rencontrées :

• Le manager en CODIR est incapable de dire où en est le projet
• Des équipiers sous l’eau ne savent pas si d’autres peuvent les aider
• A l’issue de la mise en production, l’équipe se rend compte qu’elle a principalement travaillé sur des fonctionnalités non prioritaires
• Un nouvel équipier ne sait pas comment contribuer de la meilleure façon au projet

Description de la démarche

Passer de l’individuel au collectif

L’objectif de ce module est d’amener l’équipe à partager une vision commune du système, afin d’agir collectivement en s’appuyant sur les bonnes informations.

Cette toute première étape de changement amène à passer de l’individuel au collectif. La posture individuelle évolue de “comment être occupé à 100% sur le projet” vers “comment contribuer au collectif pour l’aider à réussir son challenge”.

Le premier levier de cette métamorphose consiste à rendre visible les éléments et les événements du système. Cela permettra de les gérer à la lumière des informations partagées par tous.

Au travers de son accompagnement, le coach va aider l’équipe à mieux travailler ENSEMBLE :

Tiré du “Petit Guide de Lean Management à l'Usage des Équipes Agiles”

Avant toute chose, le coach propose un atelier de cadrage permettant de questionner l’équipe sur la connaissance de son propre système :

• Quelle est la vision du produit que vous créez ?
• Savez-vous qui travaille sur quel sujet ?
• Où en êtes-vous par rapport à la réussite de votre challenge ?
  ...

Cet atelier est une première étape vers un partage et une compréhension commune du système de l’équipe. Il permet en outre au coach de créer la relation avec l’équipe et de lui présenter l’accompagnement.

Comment bien visualiser ?

Avant toute chose, l’équipe apprend à rendre visible l’état actuel du système. Elle découvre ainsi que le management visuel est un moyen efficace pour améliorer sa performance :

• visualiser les processus, les règles et la performance pour la montée en compétences et l’autonomisation de l’équipe ;
• visualiser les écarts de performance pour que l’équipe identifie les opportunités d’amélioration ;
• disposer d’un support simple et évolutif à portée de main pour que l’équipe puisse l’utiliser et l’adapter facilement.

Pour que la prise d’information soit immédiate et collective, l’affichage est :

• structuré/organisé afin de distinguer rapidement ce qui est important/urgent et ce qui est normal ou quotidien ;
• intuitif pour que l’information puisse parvenir sans accompagnement au lecteur ;
• lisible de près et de loin afin de faciliter le partage d’information ;
• attirant pour donner envie à chacun de lire l’information ;
• modifiable pour que la représentation soit toujours la plus proche possible de ce qui se passe réellement dans le système.

Pour vivre la construction d’un management visuel, le coach invite l’équipe à pratiquer l’atelier Au Tableau d’Alexandre Boutin^[9].

Construire le management visuel

Après l’apprentissage, le coach accompagne l’équipe dans la création de son propre management visuel. Il l’aide à expliciter l’implicite : le challenge, le flux de valeur, les règles, la performance, les impédimenta^[10].

Visualiser le challenge

Souvent l’équipe ne connaît pas le challenge qu’elle essaie de relever. Elle n’est pas focalisée sur l’atteinte d’un objectif principal et se disperse.

Rendre visible le challenge permet un alignement de toute l’équipe.

Chaque équipier peut garder en tête à tout moment ce que l’équipe doit atteindre. Chacun devient responsable de s’assurer que le travail qui est en train d’être fait va bien dans le sens de la réussite collective.

Dans l’illustration ci-dessus, le challenge n’est pas rendu visible, contrairement à ce qu’on pourrait croire. Le visuel met l’accent sur le mode projet en insistant sur la date de fin, mais ne présente pas du tout ce qui constituera un succès à cette date !

Représenter le flux

Le propre des activités intellectuelles est que nous ne voyons pas de manière évidente les éléments de travail sur lesquels nous travaillons : le travail est invisible.

Pour visualiser son activité, l’équipe va créer un tableau d’états d’avancement. Les colonnes sont les étapes du flux de valeur, les éléments de travail sont représentés par des cartes qui se déplacent dans le tableau.

Le coach accompagne l’équipe dans la définition précise des étapes du flux : l’équipe sait, le coach aide à converger vers une représentation commune.

Exemple de tableau de progression classique d’une équipe de développement

Expliciter les règles

Le travail d’explicitation se poursuit avec les règles.

Qui n’a pas déjà été confronté à ce type d’échange un peu gênant :

• Michel : “J’ai terminé le développement de cette nouvelle fonctionnalité très attendue”
• Annick : “Super ! Je vais pouvoir l’utiliser dans mon travail de tous les jours, merci Michel !”
• Michel : “Ah non non, c’est terminé sur ma machine, maintenant il faut que René teste, puis qu’Albert déploie en production”
• Annick : “Mais c’est pas terminé alors !”
• Michel : “Mais si !”
• Annick : “Mais non !”

Michel et Annick sont de bonne foi tous les deux, ils n’ont juste pas la même définition de ce qui est “terminé” car la règle n’est pas explicitée ce qui laisse libre court à toutes les interprétations.

Notion de règles de passage

Le travail d’explicitation des règles vise à aligner tout le monde sur la liste des critères permettant de considérer un travail comme terminé. On applique la même démarche pour toutes les étapes du processus de travail.

Un symptôme de règles incomplètes se manifeste souvent par du rework : des éléments de travail qui reviennent en arrière dans le système faute d’une qualité suffisante.

L’équipe dispose maintenant de son tableau de suivi et s’assure qu’elle est bien en train de travailler sur les bonnes choses, alignée sur un challenge partagé par tous.

Structurer la vue

Un management visuel utilisable ne doit pas laisser de place au doute : l’équipe sait le travail qui doit être fait et quel est l’état exact d’avancement.

Lors de la modélisation du management visuel, le coach aide l’équipe à structurer la vue en faisant des regroupements logiques d’éléments visuels, par exemple :

• regrouper challenges et objectifs à droite pour indiquer là où l’équipe veut aller ;
• regrouper le tableau des tâches et sa légende au centre car c’est le coeur de l’activité de l’équipe ;
• rapprocher les métriques de performance du challenge à atteindre, pour visualiser en un coup d’oeil les écarts de performance ;
• …

La structure logique de la vue passe aussi par un regroupement des éléments par temporalité :

• regrouper ce que l’équipe va inspecter tous les jours pour qu’elle puisse voir les problèmes au plus vite ;
• regrouper les éléments persistants dans le temps : les règles, la vision ;

Regrouper les éléments pour une meilleure utilisation

Gérer le travail

Maintenant que l'équipe visualise son travail, comment peut-elle prendre les bonnes décisions en profitant du collectif ? C'est la composante Management de ce module qui sera pratiquée lors du daily meeting.

Réunion quotidienne ou Daily Meeting

Le coach invite l'équipe à se réunir tous les jours devant son management visuel pour inspecter le travail en cours, constater les problèmes et s'adapter en prenant les bonnes décisions.

Le coach explique le fonctionnement de ce rituel. Il aide l’équipe à définir l’heure de la réunion quotidienne et la timebox allouée. Il accompagne ensuite l’équipe pendant plusieurs daily meetings afin de lui apprendre à voir les problèmes (goulots d’étranglement, règles implicites, défauts de priorisation, etc…).

L’équipe ne règle pas les problèmes lors du daily meeting, mais se synchronise pour pouvoir les régler efficacement ultérieurement dans des réunions ad-hoc.

Détecter les impedimenta

Chaque jour, l’équipe se pose les questions suivantes :

• En utilisant le management visuel, est-ce que l’équipe réussit son challenge ? (quotidien, hebdomadaire, …)
• Est-ce que des impedimenta sont visibles ?
• Est-ce que les impedimenta sur lesquels l’équipe travaille sont gérés pro-activement ? Est-ce que des améliorations sont visibles ?

Pour les points de synchronisation quotidiens de l’équipe, le coach propose un protocole tel que celui ci-dessous :

Gérer les impedimenta

L’équipe apprend d’abord à voir les impedimenta qui la ralentissent dans la réussite de son challenge. Elle apprend ensuite à les gérer de manière active et suivie. Pour cela, des ajouts au management visuel peuvent être nécessaires.

Les participants doivent d’abord apprendre à identifier sur quoi il est important de travailler en premier.

Le coach propose l’utilisation de matrices (Eisenhower, Merrill-Covey) afin d’aider l’équipe à catégoriser les différents impedimenta et faciliter visuellement sa prise de décision.

La gestion proactive demande de discriminer ce qui relève de la responsabilité de l’équipe de ce qui nécessite une action du management. Matérialiser l’aide requise par une boîte d’escalade permet de focaliser l’attention du management sur les points importants où son action est indispensable.

Définir en équipe un modèle d’impedimenta permet de s’aligner sur  :

• la caractérisation d’un impedimenta ;
• la manière de suivre la levée dudit impedimenta (actions en cours, relances, etc…).

Exemple de modèle de carte d’impedimenta

Pour lutter contre la déresponsabilisation du “on”, une bonne pratique peut-être de préciser qui est “propriétaire” de la carte, au sens de “qui a détecté l’impedimenta et s’assure qu’il est traité jusqu’au bout”.

Qui construit le management visuel

Le management visuel aide l’équipe à prendre les bonnes décisions en profitant du collectif. C’est l’équipe qui connaît le mieux les étapes nécessaires à la réalisation d’un de ses éléments de travail, les règles implicites qui doivent être explicitées, les problèmes qu’elle rencontre.

C’est pour cette raison que le management visuel est construit par l’équipe, de la conception du modèle à la réalisation du “produit fini”^[12] qui sera utilisé au quotidien.

Le coach met en place le cadre permettant à l’équipe de rendre explicite tout ce qui est caché. Il anime les ateliers de mise en place du management visuel et questionne l’équipe régulièrement afin de rappeler le sens de la démarche. Ils vérifient ensemble si le management visuel est bien un support actif du travail collectif : quelle est la dernière chose que l’équipe a apprise grâce au management visuel ? 

Template de mise en œuvre

Ex. de charge pour ce module

Exemples d’atelier

• Au Tableau d’Alexandre Boutin : http://www.agilex.fr/jeu-au-tableau/
• Value Stream Mapping pour l’analyse du flux de valeur
• Cube “Faire un Daily Meeting utile et efficace” d’1CUBE&GO : http://1cube-and-go.com/faire-daily-meeting-utile-efficace/

Bibliographie

• Guide Stop to Start de Yannick Quenech’Du : http://fr.slideshare.net/yquenechdu/stop-to-start
• Petit Guide de Lean Management à l'Usage des Équipes Agiles : http://leanagilecamp.fr/

Amélioration Continue

Exemples d’insatisfactions rencontrées :

• l’équipe pousse une nouvelle version en production et les utilisateurs rencontrent des bugs qui n’avaient pas été identifiés en phase de test ;
• l’équipe démarre une tâche censée être prête et se retrouve bloquée car il n’y a pas suffisamment d’informations pour qu’elle puisse la développer correctement ;
• l’équipe est freinée par des problèmes de fonctionnement de l’entreprise qui reviennent régulièrement et semblent ne jamais être traités.

Description de la démarche

L’objectif de ce module est d’aider l’équipe à construire une démarche d’amélioration continue structurée, en élargissant la portée d’un management visuel existant.

En plus des éléments du management visuel de base^[13], le coach apprend à l’équipe à créer et maintenir :

• un tableau d’amélioration continue pour gérer les expérimentations ;
• une zone de métriques définies par l’équipe pour connaître les impacts sur le système.

Backlog d’amélioration continue

Pour recenser toutes les opportunités d’amélioration, le coach invite l’équipe à construire un backlog d’amélioration continue. Il s’alimente par les différents évènements pouvant amener à détecter les sources d’insatisfaction de l’équipe :

• lors du kick-off^[14], risques ou freins à l’atteinte de l’objectif final du projet ;
• lors des rétrospectives d’équipe, notamment sur son fonctionnement interne^[15];
• lors des daily meetings, où les problèmes courants sont détectés grâce au management visuel^[16].

Toutes les possibilités de capter le feedback client sont à exploiter : revue de sprint, étude des réclamations, des commentaires en ligne, des questionnaires de satisfaction…

Sont également à prendre en compte, les insatisfactions liées aux objectifs stratégiques relayés par la couche managériale.

Les informations ainsi recueillies viennent compléter le backlog d’améliorations potentielles.

Exemple de flux générant des idées d’amélioration continue

Alignement et priorisation des problèmes

Le coach va assister l’équipe dans la structuration de sa démarche d’apprentissage en l’aidant à se focaliser sur ce qui a le plus d’impact. Comme pour les impedimenta, l’équipe apprend à se concentrer sur ce qui a le plus de valeur pour elle ici et maintenant : doit-elle travailler sur ses problématiques de qualité ? de livraison ? de dépendances ?

Lorsque l’équipe est alignée sur les problèmes à traiter ensemble, elle les priorise selon ce qu’ils lui coûtent aujourd’hui et les bénéfices qu’elle retirerait à les résoudre.

Différentes techniques sont utilisables : retour sur investissement (ROI), coût du délai^[17], priorisation frugale…

Hypothèses et expérimentations

Une problématique amène généralement une idée de solution, mais est-ce la seule, la bonne ? Afin d’élargir le champ d’options, le coach challenge l’équipe à trouver au moins trois solutions possibles.

Ne sachant pas à l’avance si ces solutions vont effectivement répondre à la problématique sélectionnée, on parle alors d’hypothèses. Comment peut-on valider ces hypothèses ? C’est l’objectif des expérimentations.

Au travers d’un atelier guidé par le coach, l’équipe élabore et structure ses expérimentations à l’aide d’un template invitant principalement à se poser les questions suivantes :

• Quelle est notre hypothèse ?
• Quelle action concrète puis-je mettre en oeuvre pour la valider ?
• Que vais-je mesurer pendant ce temps ?
• Pendant combien de temps ?
• Comment saurais-je si mon hypothèse est bien validée ?

Exemple 1 : Template adapté du modèle de Strategizer

Exemple 2 : Carte Kaizen

Exemple 3 : Kata

Exemple 4 : A3 - Agendashift

L’équipe apprend ainsi à se poser les bonnes questions et à sélectionner de manière informée les expérimentations les plus pertinentes. Si elle n’arrive pas à répondre à une des parties, c’est un indicateur fort que ce n’est pas la bonne pour le moment.

Suivi et clôture

Maintenant que l’équipe a structuré ses expérimentations, elle doit être en mesure de les rendre visibles pour pouvoir les suivre de manière régulière. Le coach propose de les afficher directement sur le management visuel pour qu’elles fassent partie intégrante de l’éco-système partagé de l’équipe.

tableau Popcorn Flow^[19]

Lorsque l’expérimentation atteint son délai d’expiration, l’équipe analyse l’écart entre les résultats obtenus et ses attentes :

• Si le résultat est OK, l’expérimentation peut être clôturée et l’hypothèse est validée.
• Si le résultat est KO, l’expérimentation peut être clôturée et peut s’en suivre :

• une nouvelle expérimentation pour explorer la même hypothèse,
• la sélection d’une nouvelle hypothèse,
• une ré-évaluation du problème initial.

• Si le résultat n’est pas satisfaisant mais mériterait d’être prolongé, l’expérimentation peut alors continuer. Il reste néanmoins important de donner une date limite pour avoir la possibilité de capitaliser l’apprentissage acquis jusque-là.

Exemple d’ébauche de complément de management visuel pour l’amélioration continue

Template de mise en oeuvre

Pré-requis :

• Un Management Visuel existant

Trop occupé pour vous améliorer ?

Un frein souvent rencontré réside dans le manque de disponibilité de l’équipe pour traiter les problèmes qu’elle rencontre. Le coach sensibilise l’équipe et le management à l’importance de cet investissement.

Il recourt au besoin à des images humoristiques comme celle-ci :

Pas de temps de s'améliorer ?^[20]

Synthèse de l’accompagnement

Exemple de répartition des activités

Exemples d’ateliers

Rétrospectives court-terme : améliorer l’existant

• Plan d’action : http://retrospectivewiki.org/index.php?title=Plan_of_Action
• 4L : https://www.retrium.com/resources/techniques/4ls
• La roue (Start, Stop, Continue, More of, Less of) : http://retrospectivewiki.org/index.php?title=Start,_Stop,_Continue,_More_of,_Less_of_Wheel
• Consensus Workshop pour la rétrospective : https://blog.goood.pro/2012/09/18/consensus-workshop-pour-la-retrospective
• Retrouvez la banane en rétrospective - Agile Tour Marseille 2013 : http://www.slideshare.net/coactiv/retrouvez-la-banane-en-rtrospective

Rétrospectives exploratoires : changer nos processus

• Jeopardy : http://talondagile.fr/2013/02/un-oeil-dans-la-retro-33-jeopardy/
• Turn the tables : https://www.scrumalliance.org/community/articles/2013/february/iteration-retrospective-activity-turn-the-tables
• Dixit : http://www.agilex.fr/2013/04/retrospective-dixit/
• Les 6 chapeaux de De Bono : http://www.debonogroup.com/six_thinking_hats.php

Ateliers de résolution de problèmes

• Diagramme d’Ishikawa - identifier les facteurs impactants d’un problème : https://fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets
• 5 pourquoi - identifier les causes racines d’un problème : http://www.qualiblog.fr/outils-et-methodes/la-methode-des-5-pourquoi-pour-eradiquer-vos-problemes/
• A3 : http://agilitrix.com/2010/07/use-a3-technique-to-solve-serious-problems/
• Kata : https://hakanforss.wordpress.com/2014/02/13/what-is-a-kata/what-is-a-kata/ 
• Agendashift : https://www.agendashift.com/

Bibliographie

• Petit Guide de Lean Management à l'Usage des Équipes Agiles : http://leanagilecamp.fr/

• Kanban from the Inside de Mike Burrows (Understand the Kanban Method, connect it to what you already know, introduce it with impact) : https://goo.gl/YuAu0H 
• Managing to Learn de John Shook (Using the A3 Management Process to solve problems, gain agreement, mentor and lead) :  http://www.amazon.com/gp/product/1934109207

Flux

Exemples d’insatisfactions rencontrées :

• Dans cette organisation, le délai moyen entre l’expression d’un besoin identifié par le métier et sa mise sur le marché est supérieur à un an.
• L’équipe a le sentiment d’être toujours ballottée par les changements de demandes des représentants du métier.
• Les livraisons sont fréquemment décalées en raison des urgences quotidiennes.

Description de la démarche

L’objectif de ce module est d’optimiser le flux de création de valeur dans une perspective globale : du besoin d’un type d’utilisateur jusqu’à la livraison d’une solution qui résout ce problème. Ce que les anglo-saxons désignent par “from concept to cash”.^[21]

Les concepts présentés par Don Reinertsen dans son livre référence “Product Development Flow“ sont au cœur de ces considérations. Il préconise en particulier :

• de limiter le travail en cours pour fluidifier la production,
• d’accélérer le débit en diminuant la taille des lots,
• de construire un modèle économique qui permette de prendre des décisions transparentes, par exemple en utilisant le coût du délai.

Les travaux de Don ont beaucoup inspiré la méthode Kanban élaborée par David J. Anderson. La réflexion sur le flux de production est au cœur de cette méthode d’amélioration évolutionnaire.

L’optimisation du flux s’appuie sur la compétence développée par l’équipe à mener des expérimentations structurées.^[22]

Comprendre les sources d’insatisfaction

L’accompagnement démarre par un atelier initial d’identification des insatisfactions et de la motivation à changer l’existant :

• Quelle est la raison d’être du système ?
• Quelle est la capacité actuelle du système à satisfaire les besoins des clients ?
• Comment le système est-il perçu par ses acteurs ? Est-il source de frustration ?
• Quelles sont les sources de variabilité et de non-prédictibilité ?

Participent à cet atelier les membres des équipes impactant le flux, leur manager et le sponsor de l’initiative.

Limiter le travail en cours pour garantir le flux

Une métaphore fréquemment utilisée pour illustrer les fonctionnements de flux est celle des autoroutes.

https://www.flickr.com/photos/lingaraj/2415084235

Au-delà d’un certain seuil d’utilisation (70% de la capacité par exemple), un imprévu (entrée d’un véhicule lent, accident réduisant le nombre de voies) perturbe la circulation (le flux) en créant des embouteillages. Le bouchon se crée d’autant plus rapidement que le flux est saturé. Le malheur c‘est que ce phénomène est asymétrique : le bouchon met beaucoup plus de temps à se résorber qu’à se créer.

"The Principles of Product Development Flow", Reinertsen, Donald G: queueing theory

Pour optimiser le flux et garantir un temps de traversée constant et prédictible, une solution s’impose : limiter le nombre de véhicules en circulation sur l’autoroute. Cette solution est mise en œuvre en installant des feux à l’entrée des bretelles. Moins de véhicules circulent, mais leur vitesse est plus stable.

Cette approche portée dans le domaine du travail intellectuel se nomme la limitation du travail en cours^[23]. Le véhicule de l’autoroute devient un élément de travail du système.

On va donc chercher à maintenir sous contrôle le nombre total d’éléments dans le système. Pour cela, le coach présente plusieurs stratégies à l’équipe : poser des limites sur le nombre d’éléments, sur une ligne, sur une colonne, sur un acteur du système…

Exemple classique de limites sur les états de travail en cours

“Je termine le travail en cours” plutôt que “je démarre une nouvelle tâche pour être à 100% de ma capacité”

Dans une optique d’optimisation des coûts, le raisonnement hérité de l’époque de Taylor consiste à tenter de charger les “ressources“ individuelles au maximum de leur capacité. La théorie des flux nous montre que cela aboutit en fait à engorger le système. Pour conserver la faculté du système à absorber la variabilité, les imprévus, il faut que la ressource préserve une part de “slack” ou temps libre non planifié !

Dans cette optique, on cherchera désormais à privilégier l’attitude “je termine d’abord ce que j’ai commencé” par rapport à l’ancien modèle “j’ouvre autant de sujets que possible car j’essaye d’être en permanence occupé.”

Nous utilisons souvent la métaphore suivante pour illustrer les impacts néfastes du multi-tâches amenant à essayer de mener de multiples activités de front :

“c’est comme bourrer de papier une imprimante en espérant qu’elle va imprimer plus vite !”^[24]

Mesurer les temps de traversée

L’équipe va commencer à mesurer combien de temps les tickets mettent pour passer d’un état à un autre (changement de colonne sur le tableau de progression).

Puis elle va regarder le temps nécessaire à un élément de travail pour traverser tout le système.

Elle va ensuite analyser les données recueillies pour comprendre ce qui contribue aux temps mesurés et à leur variabilité.

Elle appliquera ses compétences en résolution de problème^[25] pour formuler des hypothèses d’amélioration, les prioriser et élaborer des expérimentations d’amélioration.

Exemples de métriques que le coach va suggérer de suivre :

métriques d’optimisation du flux

Le management visuel existant va ainsi être complété par de nouveaux éléments : métriques sur le flux, limites sur le travail en cours.

Support du management

Du fait des limites posées, certaines personnes vont se retrouver en sous-capacités. Le coach va les aider à résister à la tentation de démarrer une nouvelle tâche, ce qui aurait pour conséquence de saturer le système. Le temps rendu disponible va être utilisé pour :

• aider les autres membres de l’équipe et apprendre ou fortifier des compétences,
• de l’amélioration personnelle^[26],
• la maintenance évolutive du système (investir pour le plus long-terme),
• l’innovation, l’expérimentation.

Ces changements ne relèvent pas forcément du bon sens. Ils viennent souvent heurter les modes habituels de travail. Il est essentiel que les managers soient impliqués dans les identifications de problèmes, dans les ateliers d’apprentissage et dans les suivis d'expérimentations. C’est tout le sens de la métaphore du stabilisateur “Management agile”^[27].

Accélérer le débit en diminuant la taille des lots

Grâce à l’atelier “Penny Game”^[28] , les membres de l’équipe et leurs managers prennent conscience de l’impact de la taille des éléments sur le temps de traversée du système.

Guidés par le coach, une série d’ateliers de découpage permet de reprendre les éléments de travail et de diminuer la taille de chaque item. La taille est représentée par l’estimation collective de l’effort relatif requis pour réaliser l’élément, voir les techniques du type Planning Poker pour cela.

Modèle économique et coût du délai

Maîtriser le travail en cours impose de prendre des décisions sur le travail à faire ou ne pas faire. Pour cela, il est essentiel de disposer d’un ensemble cohérent de règles, en particulier de priorisation. Les stratégies de priorisation habituellement utilisées dans les démarches agiles consistent à établir le ratio entre la valeur relative apportée par un élément et l’effort relatif nécessaire à la réalisation de cet élément.

Don Reinertsen complète cette approche en argumentant que la valeur n’est pas un paramètre immuable mais qui évolue avec le temps.

Deux éléments peuvent présenter une valeur relative identique mais l’un apportera plus de valeur à être réalisé rapidement tandis que l’autre pourra attendre sans que la valeur attendue en pâtisse. Il importe donc de considérer ce paramètre pour effectuer le bon choix !

Le coach peut présenter différentes techniques pour prendre en compte cette notion, par exemple pour commencer l’approche Weighted Shortest Job First (WSJF). Voici la formule de calcul utilisée par le framework SAFe (http://www.scaledagileframework.com/wsjf/)^[29] :

Equilibrer demande et capacité

Au travers de facilitation d’ateliers, le coach va aider l’équipe et ses managers à mieux connaître les demandes arrivant dans le système et sa capacité à les traiter.

Équilibrer les demandes et la capacité

Le coach va  étudier un certain nombre de thèmes avec l’équipe. En voici quelques exemples issus de Kanban et de Mike Burrows^[30] :

Template de mise en œuvre

Pré-requis :

• Disposer d’une représentation de la chaîne de production de valeurs et des éléments traversant cette chaîne : le flux. Cette représentation s’élabore dans le module “Management Visuel”.
• Savoir mener des expérimentations basées sur des hypothèses. Savoir sécuriser le contexte de manière à garantir un minimum de perturbations sur la production. Cette compétence s’acquiert dans le module “Amélioration continue”.
• Accepter une évolution progressive : il faut du temps pour que les résultats des expérimentations puissent être analysés. Cette étape peut prendre plusieurs mois.
• Accepter les impacts des expériences.

Synthèse de l’accompagnement

Exemples d’atelier

• Penny Game - l’impact de la taille des lots sur le temps de production : http://tastycupcakes.org/2013/05/the-penny-game/ 
• Ecrire son prénom - l’impact du multi-tâche sur le temps de production :

• “The Multitasking Name Game – or How Long Does it Take to Write a Name?” par Henrik Kniberg : http://blog.crisp.se/2011/12/07/henrikkniberg/multitasking-name-game 
• révision par Alfred Almendra : https://t.co/YRC7klwqRj 

• En retenue - l’importance de terminer une tâche avant d’en entamer une nouvelle : http://www.duncsmith.com/blog/agile-detention-i-must-limit-work-in-progress/
• WSJF - apprendre à prioriser en utilisant le coût du délai :

• Simulation par Mark Richards https://goo.gl/kavGtC 
• SAFe City Workshop: Portfolio & Program Prioritisation In Practice : https://goo.gl/Q0iAVT

• Dice Game - montrer l’impact de l’utilisation d’un système à 100 % de sa capacité : http://oyomy.fr/2016/11/2-ateliers-utiles-pour-parler-doptimisation-globale/
• Featureban - limiter le travail en cours et mesurer les effets : https://blog.agendashift.com/2016/06/02/featureban-2-0/ 
• Agendashift : https://www.agendashift.com/                

Bibliographie

• Guide Stop to start de Yannick Quenec’hdu : http://fr.slideshare.net/yquenechdu/stop-to-start 
• Product Management Flow de Don Reinertsen : http://www.leanproductflow.com/
• Kanban de David J Anderson :

• https://www.amazon.fr/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402
• version française : https://goo.gl/9MMucs 

• Kanban from the Inside de Mike Burrows (Understand the Kanban Method, connect it to what you already know, introduce it with impact) : https://goo.gl/YuAu0H 
• Kanban in Action de Marcus Hammarberg and Joakim Sundén : https://www.manning.com/books/kanban-in-action 

partie 2 : 

les stabilisateurs

de vol

les stabilisateurs s’assurent de l’équilibre de la démarche
entre lien avec l’organisation (management agile) et contribution individuelle (maîtrise personnelle)

Management agile

Contenu

L’objectif de ce module est d’accompagner l'indispensable transformation du manager pour qu’il puisse soutenir ses collaborateurs dans la transformation agile.

De l’empathie pour le manager

Dans ce voyage de transformation agile, le manager voit son équipe évoluer, s’améliorer, gagner en autonomie. Mais le reste de l’organisation lui demande des comptes et il ne sait pas comment faire pour accompagner ce changement.

C’est en effet une illusion de croire qu’il ne fait qu’accompagner le changement de l’équipe. La transformation agile passe par sa propre transformation^[31].

Le manager se sent souvent comme pris entre le marteau et l’enclume.

Versionone state of Agile 2015^[32] :
le manque de support du management cause de 38% des échecs de projets agiles

Le coach doit comprendre ses difficultés et se mettre à son service tout en conservant ses objectifs de transformation.

Au lieu de lutter contre, il va plutôt tenter de nouer une relation avec le manager pour l’aider à stabiliser la transformation agile.

De l’autonomie à l’interdépendance

Pour renforcer la résilience, la transformation agile amène à privilégier les “individus et les interactions”. Le manager est directement impacté par cette transformation.

Auto-organisation

Le manager est habitué à gérer des individus. Dans ce voyage de transformation agile, il doit maintenant apprendre à manager une équipe et son intelligence collective, les interactions plutôt que les individus. C’est un vrai changement de modèle mental pour le manager.

Catalyser l’intelligence collective

Une équipe est un système complexe. Le manager ne peut pas gérer l’équipe comme il gérait les individus.

Plutôt que d’ordonner, diriger ou piloter dans un monde qu’il croyait prédictible, il doit maintenant prendre en compte la complexité et l’incertitude et catalyser l’intelligence collective pour renforcer les capacités d’adaptation.

Le coach accompagne le manager dans ce changement de modèle mental. Il l’amène à voir les systèmes et penser en terme d’interactions, incertitude et expérimentations. Dans cet environnement complexe, il lui apporte tout d’abord du feedback et l'assistance dans sa propre transformation.

L’équipe a besoin de nouvelles compétences collectives : le manager apprend à animer des sessions de facilitation et à changer de posture. Le coach propose également des outils de facilitation pour aider le manager, comme le 6F (décrit ci-dessous) ou ORID^[33].

Il prépare avec le manager des sessions d’intelligence collective qui permettront à l’équipe de construire ses propres solutions tout en développant son auto-organisation.

Ex. de fiche préparatoire pour une facilitation

Nécessité d’un cadre explicite

Dans le voyage de transformation agile, le manager voit son équipe gagner en autonomie cependant il est toujours responsable de cette équipe vis-à-vis de l’organisation. La liberté totale de l’équipe est illusoire, l’auto-organisation n’existe pas sans un cadre fixé par le manager au nom de l’entreprise.

Il doit trouver le juste milieu entre laisser la liberté nécessaire à l’épanouissement et l’apprentissage de son équipe, tout en maintenant le cadre nécessaire pour assurer la réussite de la mission de l’équipe.

Comme le dit Simon Sinek lorsqu’il parle du “Cercle de Sécurité”^[34], le cadre de l’autonomie est ce qui permet à l’équipe de pouvoir s’auto-organiser et expérimenter en toute sécurité. L'autonomie n'existe donc qu’à l’intérieur d’un cadre.

Co-construire le cadre de l’autonomie

Le manager va expliciter le cadre de l’autonomie avec l’équipe pour lui permettre de grandir et gagner en responsabilité. Un moyen pour cela consiste à explorer avec l’équipe le modèle ci-dessous.

Cadre d’appartenance de l’équipe auto-organisée

Le manager et l’équipe co-construisent ce modèle avec les réponses aux questions suivantes :

• pourquoi l’équipe existe-t-elle ? Quelle est sa raison d’être ? Quels sont ses objectifs ? Le manager doit donner du sens.
• quelles sont les règles qui définissent ce cadre : permission à faire et protection contre le risque de mal faire ? Le manager doit expliciter les règles (permissions et protections)^[35]

Le coach peut également proposer au manager un outil comme le Delegation Poker de Jurgen Appelo^[36], pour expliciter les différents niveaux de délégation entre le manager et l’équipe.

L’acceptation par l’équipe des contraintes inhérentes à sa présence dans l’organisation lui permet de définir librement son identité, ses valeurs, sa mission. C’est le cadre et la liberté à l’intérieur du cadre qui permettent l’autonomie responsable de l’équipe.

Cette ambivalence entre discipline et liberté est génératrice d’excellence et d’innovation.

Du management au leadership

La transformation agile amène à privilégier les “individus et les interactions”. Le manager agile continue donc à accompagner le développement des individus. Mais il ne peut plus se contenter d’imposer, il doit influencer, donner envie. Il passe du management au leadership^[37].

Le leadership permet au manager de favoriser l’engagement des individus. Il doit donner du sens et ensuite faciliter, soutenir et valoriser les réalisations.

Changement de posture

Motivation

De nombreuses études sur la motivation démontrent qu’il existe des facteurs de motivation intrinsèques et extrinsèques. La motivation intrinsèque se définit par la poursuite d’une activité pour la satisfaction interne que l’on en tire, plutôt qu’une conséquence séparée^[38].

Dans son best-seller Drive, Dan Pink définit trois piliers pour la motivation intrinsèque : Autonomie, Maîtrise, Finalité (Autonomy, Mastery, Purpose).

Autrement dit, on ne peut pas motiver une personne. Il est seulement possible de créer le contexte pour que la motivation intrinsèque de la personne soit sollicitée de manière optimale.

Pour alimenter la motivation intrinsèque de ses collaborateurs, un manager agile va travailler sur le contexte permettant la motivation. Le coach aide le manager à adopter cette nouvelle posture. Il peut lui fournir des outils permettant de travailler sur ce thème : “Motivation Canvas” ci-dessous ou “Moving Motivators” de Jurgen Appelo.

La motivation, combinaison de Management 3.0 et de Dan Pink

Chaque personne étant différente, le manager agile doit avant tout faire preuve d’écoute pour bien connaître ses collaborateurs^[39]. Il doit adapter son interaction à chaque personne^[40].

Montrer l’exemple

La transformation agile concerne tout le monde et l’Agile Rocket n’atteindra pas la North Star si le manager ne change pas lui-même : il soutient la transformation agile en montrant l’exemple. Le manager ne reste plus dans son bureau, il va sur le terrain pour voir l’équipe et se rendre compte lui-même des problèmes : pratique “Gemba Walk” du Lean.

Le manager est le stabilisateur de la transformation car lui-même change et développe sa maîtrise personnelle avant d’accompagner celle de ses collaborateurs. Pour que l’équipe puisse le suivre et grandir, le manager ne va plus dire à l’équipe quoi faire mais montrer, puis enseigner comment faire. Pour que l’équipe agile auto-organisée fasse preuve d’écoute, apprenne à donner du feedback constructif, le manager doit commencer par pratiquer lui-même l’écoute et le feedback.

Le coach peut l’aider dans cette démarche avec des outils comme “l’Exemplarity Canvas”.

L’Exemplarity Canvas : aider le manager à travailler l’exemplarité

Héros et Servant Leadership

Le manager a souvent l’image du héros. Il est fort, il sait tout et à lui seul il peut sauver toute l’équipe : il est prêt à mourir pour elle. C’est l’image de Jeanne d’Arc qui devant son armée libère la France des Anglais. En se comportant ainsi le manager risque de mettre en péril l’Agile Rocket.

Pour la stabiliser, il doit plutôt faire preuve de leadership. On évoque souvent la posture de Servant Leadership, proposée par Robert K Greenleaf en 1970 : un leader au service de l’équipe, un serviteur prêt à tout pour l’aider à atteindre son objectif et régler ses problèmes. C’est le serviteur.

Lien entre servant-leadership, motivation intrinsèque et modèle 3R de Deutschman^[41]

On demande alors au manager de passer sans transition du rôle de héros à celui de serviteur, d’un extrême à l’autre. On reste sur le même spectre de pouvoir.

Et si les deux postures étaient complémentaires ? Et si ces deux extrêmes étaient générateurs d’un management agile stabilisateur ?

Le ”leader as a Host”

Host Leadership : https://www.infoq.com/articles/host-leadership-agile

En tant que stabilisateur de la transformation, le manager ne peut plus imposer, diriger comme avant, mais ne devrait pas non plus être à l’extrême inverse. Il va se comporter en fait comme un hôte recevant ses invités, passer souplement d’une posture à l’autre suivant les circonstances. Tantôt leader, tantôt serviteur, tantôt facilitateur, tantôt médiateur…

En présentant le modèle du “leader as a host”, le coach amène le manager à ne plus voir la transformation agile comme un passage d’un extrême à l’autre. Il lui permet de changer de modèle mental pour envisager la complémentarité là où il ne voyait qu’opposition : notion de complémentarité générative, indispensable pour la réussite du voyage.

Exemples d’atelier

Autonomie

• Delegation Poker : https://management30.com/product/delegation-poker/ 
• RACI : https://fr.wikipedia.org/wiki/RACI
• Give & Take Matrix : http://gamestorming.com/games-for-design/give-and-take-matrix/

Construire le contexte pour la motivation intrinsèque

• Moving Motivators : https://management30.com/practice/moving-motivators/ 
• 1:1 : http://www.qualitystreet.fr/2012/05/02/one-on-one-l%E2%80%99outil-n%C2%B01-du-manager-agile-pour-plus-de-feedback-et-de-reconnaissance/
• MBTI : https://fr.wikipedia.org/wiki/Myers_Briggs_Type_Indicator

Catalyser l’intelligence collective

• ORID^[42]
• Technology Of Participation : http://www.ica-international.org/top-facilitation/

Leadership

• Exemplarity Canvas
• Gemba Walk : http://christian.hohmann.free.fr/index.php/lean-entreprise/lean-management/216-gemba-walk

Bibliographie

• La 5ème discipline de Peter Senge : https://www.amazon.fr/Cinqui%C3%A8me-Discipline-mani%C3%A8re-organisations-apprennent/dp/287691168X
• La vérité sur ce qui nous motive - “Autonomy, Mastery, Purpose” de Dan Pink :

• https://www.amazon.fr/v%C3%A9rit%C3%A9-sur-qui-nous-motive/dp/208137952X 
• https://www.youtube.com/watch?v=wdzHgN7_Hs8

• Management 3.0 de Jurgen Appelo : https://www.amazon.fr/Management-3-0-Leading-Developers-Developing/dp/0321712471
• Host de Mark McKergow : https://www.amazon.fr/Host-Mark-McKergow/dp/0954974980
• Change or Die de Alan Deutschman (The Three Keys to Change at Work and in Life) : https://www.amazon.fr/Change-Die-Three-Keys-Work/dp/0061373672 

Liens

• La théorie des 2 facteurs de motivation de Herzberg : https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_deux_facteurs
• Pourquoi les bons leaders vous donnent un sentiment de sécurité de Simon Sinek : https://www.ted.com/talks/simon_sinek_why_good_leaders_make_you_feel_safe?language=fr
• Management 3.0 : https://management30.com/
• Host Leadership : http://hostleadership.com/

Maîtrise personnelle

Exemples d’insatisfactions rencontrées :

• Les membres de l’équipe ne font que se plaindre et rien ne bouge
• Il y a de nombreux conflits au sein de l’équipe et ses membres n’arrivent plus à travailler ensemble
• Les individus sont sur-sollicités et perdent en productivité par manque d’organisation

Contenu

La maîtrise personnelle est un des deux stabilisateurs de vol de l’Agile Rocket. Sans elle, la transformation risque de perdre rapidement en énergie, de s'essouffler et même de dériver. L’objectif de ce module est de décrire les changements de modèles mentaux et de comportements nécessaires pour maintenir la transformation en vol.

Passer de la réaction à la pro-action

“Ce n’est pas de ma faute !”, “On ne peut rien y faire !”, “C’est comme ca !” 

Il est souvent plus facile de se plaindre plutôt que de mettre en oeuvre une action pour résoudre son problème. D’un point de vue systémique, peut-être même y trouve-t-on un avantage !

Le coach va aider les personnes - manager, membre d’équipe - à voir les choses sous une perspective différente en les accompagnant vers une prise de responsabilité proactive des événements auxquels elles font face. Pour cela, il utilisera des modèles comme le “Processus de Responsabilité” de Christopher Avery.

Ce modèle décrit le processus mental par lequel chacun d’entre-nous passe, autant au niveau individuel que collectif, lorsque les choses ne se passent pas souhaité.

Partons d’un exemple : “Une météorite a heurté la fusée, lui causant des dégâts.”

Le capitaine va à la rencontre de son équipe et leur demande ce qu’il se passe.

Voici les réponses qu’il pourrait obtenir :

Les 6 premières réponses correspondent aux états de dépendance dans lesquels on garde un sentiment d’amertume et une motivation diminuée, créant ainsi un cercle vicieux dans la non-action.

Dans le cas de l’état mental de Responsabilité, je fais cette action car j’ai envie de la mettre en oeuvre. J’y trouverais même de la fierté et une motivation renforcée créant de ce fait un cercle vertueux d’énergie.^[43]

Le coach peut se servir du modèle comme support de discussion dans le cadre de rétrospectives^[45] ou d’entretiens individuels. Il est nécessaire pour l’équipe d’identifier l’état où elle se trouve aujourd’hui, pour trouver ensemble un moyen de sortir de ses problématiques et d’avancer. Le coach aide l’équipe à atteindre le niveau “Responsabilité”, essentiel pour nourrir la dynamique d’apprentissage de l’organisation à s’adapter aux imprévus et à produire plus de valeur.

Passer de l’individuel au collectif

Une équipe correspond à la somme de ses individus plus ses interactions. Le coach va aider les membres de l’équipe à développer leur intelligence relationnelle en leur proposant des outils pour mieux interagir ensemble. L’équipe apprendra ainsi à mieux collaborer et à gérer ses conflits de manière plus efficace.

Se comprendre pour mieux collaborer

Pour mieux travailler ensemble, les membres d’équipe doivent apprendre à communiquer plus efficacement, avec moins d’agressivité. Le coach peut proposer d’utiliser des modèles, comme celui de la communication non violente, pour structurer les échanges lors d’ateliers de rétrospectives ou de gestion de conflit.

La communication non violente

Modèle de la communication non violente (CNV)

Reprenons notre exemple précédent : “Une météorite a heurté la fusée et a fait des dégâts.”

Le capitaine vient voir son équipe en structurant son discours selon le processus de communication non violente :

1. Observation : “J’ai senti un impact et les indicateurs de pression sont passés au rouge.”

2. Sentiment : “J’avoue que cela m’inquiète.”

3. Besoin : “J’ai besoin de me rassurer : cela peut-il mettre en péril notre expédition et nous mettre en danger ?”

4. Demande : “Pourriez-vous enquêter pour que l’on puisse prendre la meilleure décision ensemble ?”

D’autres approches, comme la méthode de conversation structurée des Technology of Participation^[47] pourraient être employées.

le questionnaire ORID de la conversation structurée

L’écoute active

S’exprimer est une chose, écouter en est une autre. Le coach peut aider l’équipe à pratiquer l’écoute active pour tisser entre eux un lien de confiance rapide. Cette posture offre un espace neutre où chacun peut exister et s’exprimer. Cela favorise la participation de l’individu à la vie du collectif.

Voici quelques règles pour passer en écoute active :

• accueillir les propos de l’autre sans interprétation,
• laisser l’autre s’exprimer sans interruption,
• rester bienveillant,
• le questionner, lui témoigner des signes visuels et verbaux d’intérêt,
• reformuler ses propos en essayant de reprendre les termes utilisés,
• témoigner de l’empathie à l’autre et confirmer sa bonne compréhension des propos.

Se challenger pour grandir

Pour alimenter le sentiment de maîtrise, un des facteurs de motivation intrinsèque, le coach va aider chacun à développer une habitude à capitaliser sur ce qu’il accomplit et à se donner des perspectives d’amélioration. C’est une des compétences clé du manager pour accompagner son équipe Agile vers l’auto-organisation^[48] mais cela s’applique également à chaque membre de l’équipe.

Le coach peut ainsi leur proposer des outils comme le feedback et le feedforward.

Le feedback : pour consolider l’existant

Le feedback est un retour sur une période de temps passée sur laquelle on souhaite capitaliser. Plutôt que d’ancrer sur les parties négatives de l’expérience, le coach peut apprendre aux personnes à favoriser les formulations positives afin d’aider à leur développement.

Le coach met en avant ce processus de communication entre les membres de l’équipe pour générer une habitude permanente d’amélioration continue des compétences.

Le feedforward : pour ouvrir vers l’avenir

Le feedforward est une suggestion constructive qui vise à inspirer de nouvelles idées à l’interlocuteur. L’objectif n’est pas de recommander ou de conseiller, mais d’ouvrir l’espace des possibles sur ce qui “pourrait” être différent. Il ne déresponsabilise pas le bénéficiaire car il est le seul à s’engager à le prendre en compte ou non.

Exemple de feedforward avec suggestion d’alternative :

“Et si tu posais tes outils près du réacteur à propulsion,

à côté de tes vêtements de protection, est-ce que cela t’aiderait ?”

Exemple de feedforward avec bousculement de cadre de référence :

“Et si l’impact de cette météorite était une opportunité, quelle serait-elle ?”

Passer de l’efficacité à l’efficience personnelle

L’efficacité correspond à l’atteinte des objectifs quel qu’en soient les impacts. L’efficience correspond à l’atteinte des objectifs avec le juste effort pour être soutenable : c’est l’efficacité avec élégance.

Dans le monde aujourd’hui très connecté, les sollicitations se font de plus en plus nombreuses : par téléphone, email, chat, notifications diverses… Une étude a même montré qu’une personne est dérangée en moyenne toutes les 12 minutes !

Le coach va aider les membres d’équipe à travailler de manière plus organisée pour pouvoir rester productifs tout en diminuant leur sensation de stress. C’est d’ailleurs l’application directe d’un des principes du Manifeste Agile favorisant un rythme de travail soutenable.

Afin de diminuer le stress généré par l’afflux de demandes dans les équipes, le coach va proposer des méthodes de visualisation permettant à chacun de pouvoir matérialiser le véritable stock à traiter et optimiser la prise de décision. Pour cela, il peut utiliser des outils comme le Personal Kanban.

Le Personal Kanban

Ex. de Personal Kanban minimaliste

Comme son nom l’indique, le Personal Kanban est inspiré de la Méthode Kanban et adaptée à l’organisation personnelle. Toute personne souhaitant gérer son flux de travail individuel peut en mettre un en place.

Le coach accompagne les individus en s’appuyant sur 2 règles :

• Visualiser le travail : voir l’ensemble des demandes à traiter sur un tableau Kanban simple aide à mieux gérer le stress
• Limiter le travail en cours^[49] : ne pas travailler sur toutes les demandes en même temps permet de maintenir un niveau de qualité et d’efficacité personnelle

Ces deux règles visent à appliquer le principe fondamental de réduction du travail en multitâches : “Stop Starting, Start Finishing”.

D’autres approches existent pour aider à la visualisation et à l’organisation personnelles comme Getting Things Done ou le Mind Mapping.

En parallèle, pour traiter la sur-sollicitation, le coach peut proposer des techniques comme Pomodoro, permettant à chacun de s’assurer des périodes de focalisation pour travailler sans être dérangé.

La Technique Pomodoro

Le Pomodoro (“tomate” en italien) est une technique de planification qui se base sur un minuteur permettant de définir des périodes de focalisation où tout type de perturbation extérieure est interdite.

Le processus mis en oeuvre est le suivant :

1. Sélectionner la tâche à effectuer
2. Régler le pomodoro (minuteur) sur le temps de focalisation planifié
3. Effectuer la tâche jusqu’à ce que le minuteur sonne
4. Prendre une pause de 5 minutes
5. Prendre une pause d’une vingtaine de minutes après 4 pomodori.

Exemples d’ateliers

• Rétrospective avec le Processus de Responsabilité : http://sch3lp.github.io/2015/01/22/how-to-run-a-responsibility-process-retrospective/ 
• Travail sur la motivation intrinsèque avec les Moving Motivators : https://management30.com/practice/moving-motivators/ 

Bibliographie

• Les responsables porteurs de sens de Vincent Lenhardt : https://www.amazon.fr/responsables-porteurs-sens-pratique-team-building/dp/2212563442 
• The Responsibility Process de Christopher Avery : https://www.amazon.fr/Responsibility-Process-Unlocking-Natural-Ability/dp/099774720X/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1482156917&sr=1-1-catcorr&keywords=responsibility+process 
• 65 outils pour accompagner le changement individuel et collectif de Arnaud Tonnelé : https://www.amazon.fr/outils-accompagner-changement-individuel-collectif/dp/2212548435 
• Getting Things Done de David Allen : https://www.amazon.fr/Sorganiser-pour-r%C3%A9ussir-Getting-Things/dp/2848992093 
• La vérité sur ce qui nous motive de Dan Pink : https://www.amazon.fr/v%C3%A9rit%C3%A9-sur-qui-nous-motive/dp/208137952X 

Liens

• Responsibility Process (vidéo explicative courte) : https://www.youtube.com/watch?v=-T3IZ2ISxag 
• Manifeste Agile : http://agilemanifesto.org/ 
• Technique pomodoro : https://fr.wikipedia.org/wiki/Technique_Pomodoro 
• Mindmapping : http://www.mindmapping.com/fr/ 
• Personal Kanban : http://www.personalkanban.com/pk/ 
• Technology of Participation : http://www.ica-international.org/top-facilitation/ 
• Écoute active : https://fr.wikipedia.org/wiki/%C3%89coute_active#Comment_.C3.AAtre_en_.C3.A9coute_active_.3F 

partie 3 : 

les boucliers thermiques

Les boucliers thermiques aident à s'assurer que l’on fait la bonne chose (Product Culture)
tout en le faisant correctement (Excellence de l’ingénierie)

Culture produit

Exemples d’insatisfactions rencontrées :

• Des utilisateurs se plaignent d’être perdus dans l’application et préfèrent passer sur une prise de note papier pour effectuer leur activité.
• Les équipes de réalisation souffrent de ne pas savoir si leur produit a été utile
• Le contrôleur de gestion se plaint que l’argent dépensé n’apporte pas les recettes escomptées
• La startup se plaint d’avoir investi de fortes sommes pour faire un magnifique produit qui n’intéresse personne
• Les équipes de réalisations se plaignent de réaliser des fonctionnalités lourdes et complexes qui leur semblent inappropriées

Contenu

La métaphore de la culture produit comme bouclier de la fusée, correspond au risque de surcharger le système avec une masse de demandes mal traitées ou encore d’utiliser cette efficacité pour délivrer de la non-valeur.

Comme le dit Peter Drucker dans la citation qui ouvre ce chapitre, depuis la fin du XXème siècle, les entreprises se sont concentrées sur l’amélioration de leur démarche projet. La première étape consiste dans la prise de conscience des risques que cela entraîne si le projet n’est plus au service du produit et donc de la création de satisfaction pour l‘utilisateur.

Nourrir une culture d’entreprise et une stratégie produit

L’objectif de ce module est de savoir comment encourager et nourrir une culture d’entreprise qui satisfait le client en traitant positivement l’évolution continuelle des besoins utilisateurs.

La démarche consiste à se mettre en capacité de toujours proposer le meilleur produit afin de permettre à l’entreprise d’en tirer des bénéfices.

Des boucles vertueuses

Dans un premier temps, le coach questionne la stratégie produit.

L’entreprise :

• A-t-elle bien défini ses clients ? Ses utilisateurs ?
• A-t-elle réussi à les comprendre ?
• A-t-elle défini une stratégie pour valider au plus tôt que le produit rendait bien le service attendu par le client ?
• A-t-elle étudié quelles pouvaient être ses propres attentes ?
• A-t-elle les moyens de construire un produit viable économiquement ?

En fonction des réponses à ces différentes questions, le coach propose différentes étapes afin d’aller vers la construction d’un produit répondant autant aux besoins fondamentaux de potentiels consommateurs que de l’entreprise.

Les limites de la culture projet

Triangle de fer

Tout projet est régi par le triangle que l’on nomme couramment le “Triangle de fer”. Sa mécanique fait que lorsqu’un angle grandit ou se réduit, les autres angles sont impactés aussi (exemple type : si le périmètre augmente il sera nécessaire d’augmenter le budget et donc le coût du projet ou de reculer la date de livraison)

Dans une culture projet, même si tous les angles doivent être maîtrisés, la Qualité (définie par le périmètre et la qualité technique du livrable) est généralement fixée, imposant une adaptation du coût ou de la date.

Malheureusement, la réalité des projets (obstacles non identifiés, erreurs d’estimation, mauvaises compréhensions, évolution des besoins…) oblige à faire des choix :

• Jouer sur le délai avec de potentielles conséquences négatives : risquer l’insatisfaction client, rallonger le temps de feedback, augmenter le périmètre à chaque nouvelle version
• Jouer sur le Coût (avec un impact sur le délai, cf Loi de Brooks^[50])
• Jouer sur la qualité intrinsèque et donc s’endetter sur le long-terme^[51]
• Demander toujours plus aux équipes avec un risque d’impact sur la qualité intrinsèque et fonctionnelle

Sortir du “toujours plus” en inversant le triangle

Le seul levier acceptable pour l'agilité est celui du périmètre. Non pas livrer moins de fonctionnalité, mais livrer le plus rapidement possible les fonctionnalités à forte valeur ajoutée.

Triangle de fer des projets agiles

Objectif : raccourcir les boucles de feedback afin d’apprendre rapidement et empiriquement pour obtenir le produit le plus adapté au marché

Le sujet n’est donc plus : “avons-nous assez de budget pour délivrer ce périmètre ?” avec une orientation coût, mais “comment livrer le plus de valeur aux utilisateurs grâce à notre budget ?” dans une orientation valeur.

Comment s’assurer qu’on génère de la valeur ?

Le coach accompagne les parties prenantes à changer leur attentes vis à vis du produit à livrer. La question n’est plus de regarder la capacité de livraison de l'output mais de se focaliser sur l'outcome, l'intérêt du livrable pour les utilisateurs.

Plus largement, l’output focus est la prémisse à une focalisation plus grande : la focalisation “customer centric”, centrée globalement sur l’utilisateur.

L’utilisateur au centre

La viabilité d’une entreprise passe par la capitalisation de ses utilisateurs. Une entreprise qui néglige ses utilisateurs a intérêt à avoir des investisseurs fortunés et compréhensifs. Il est essentiel d’identifier quelle valeur apporter aux usagers qui vont consommer le service ou le produit. Il importe aussi étudier les retombées attendues pour l’entreprise.

Tout d’abord, faire la différence entre client et utilisateur : le client est celui qui paie le service, le produit. L’utilisateur est celui qui consomme le service, le produit. Un client peut ne pas être utilisateur s’il achète le produit pour quelqu’un d’autre.

Ex : Des parents achètent des céréales pour leur enfant qui sera donc l’utilisateur du produit

Il est primordial de les différencier et de savoir les traiter en tant que tel. Traiter le client sans traiter l’utilisateur revient à supposer que quelqu’un va payer pour un service inexistant. Cependant, négliger le client peut probablement générer un danger financier pour l’entreprise : pas de client, pas d’argent.

De la valeur pour l’utilisateur

Pour réussir à basculer vers un mode centré utilisateur, le coach accompagne tous les acteurs de la chaîne de valeur vers une meilleure compréhension des usagers et de la meilleure façon de les satisfaire. Pour cela il procède en plusieurs étapes :

• Découvrir, comprendre et devenir l’utilisateur
• Apporter le bon produit

Découvrir, comprendre et devenir l’utilisateur

Le coach invite les parties prenantes proches des utilisateurs (comme le marketing, les commerciaux…) à étudier les consommateurs.

Aller à la rencontre de l’utilisateur

Dans une entreprise à forte culture projet, le travail initial consiste principalement à étudier ce que veut l’utilisateur.

L’utilisateur qui exprime ce qu’il veut, limite sa vision du possible à qu’il connaît ou fait déjà. Se cantonner à ce périmètre mènera l’étude à de mauvaise pistes et ne permettra pas de régler le besoin fondamental de ce même utilisateur.

En s’appuyant sur les démarches d’analyse utilisateur et de test rapide, le coach apprend aux représentants utilisateurs à aller chercher les besoins fondamentaux des utilisateurs, mais aussi leurs motivations. Il invite les acteurs à aller sur le terrain de leur cible et à observer, sans jugement en pratiquant le Gemba Walk.

Exploiter les informations recueillies

A l’issue de cette analyse terrain, le coach et l’équipe formalisent les informations en leur possession.

Une des grandes difficultés de cette démarche est de sélectionner les informations recueillies durant les nombreuses études terrain et interviews. Parmis toutes les données récoltées, quelles sont celles qui sortent du lot, celles qui confirme une tendance, celle que l’on peut réellement travailler ?

Le coach accompagne l’équipe à structurer les informations ayant trait aux caractères des consommateurs potentiels afin de définir des typologies d’utilisateurs sans tomber dans l’archétype et la caricature.

Humaniser un type d’utilisateur doit permettre à l’ensemble des acteurs projet - depuis le représentant utilisateur jusqu’à la chaîne de production - de s’identifier à l’utilisateur. Ainsi chaque décision sera prise en ayant adopté son point du vue^[53].

Une fois les utilisateurs et clients identifiés, étudiés, compris et quasiment présents dans l’équipe, quel service pouvons-nous leur apporter ?

Définir la stratégie Produit

L’entreprise a désormais une idée de son marché et peut dès lors travailler à identifier son produit.

Qu’est-ce que le bon produit pour l’utilisateur ?

C’est la question que tout responsable produit se pose et doit se poser tout au long du cycle de vie du produit. Pourtant la réponse à cette question est aussi variable que le marché est complexe et la réponse à un instant t peut être obsolète rapidement. Cependant, il faut bien commencer quelque part et concevoir le premier produit qui apportera de la valeur aux utilisateurs identifiés.

A partir des informations glanées lors des enquêtes terrain, le coach aide l’équipe à étudier les éléments qui pourraient créer de la valeur aux utilisateurs

Tout d’abord, définir un sujet d’étude : un utilisateur, un but (ce que l’utilisateur essaie d’atteindre réellement lorsqu’il effectue une activité particulière)

On distingue ensuite deux moyens de créer de la valeur :

• supprimer un problème pour l’utilisateur (ce qui l’empêche d’atteindre son but)
• renforcer la satisfaction de l’activité (ce qui rend l’activité plus agréable à vivre)

L’outil Value Proposition Canvas d’Alexander Osterwalder, Yves Pigneur, Gregory Bernarda et Alan Smith est un excellent outil pour faire émerger rapidement des pistes d’études fonctionnelles en se basant sur ces deux points d’étude.

Il est primordial aussi d’étudier les moyens dont dispose actuellement l’utilisateur pour remplir son objectif et qui pourraient se substituer à notre produit car plus performant, moins cher, plus agréable à utiliser^[54]...

Vision du produit

La vision est un discours simple, court et clair permettant d’expliquer le produit et la proposition de valeur qui l’accompagne.

Pour qui le produit est-il prévu ? Pour répondre à quel besoin ? Quel est le nom et la forme du produit (produit physique ou virtuel, service…) ? Apport majeur ? Éléments différenciants et par rapport à quoi ?

Une fois formalisée, la vision doit être partagée avec les acteurs externes (pour vérifier l’appétence pour le produit) et interne (pour engager les équipes).

Une nouvelle étape a été franchie, les parties prenantes du produit commencent à valider la pertinence de leur idée, le prochain challenge est d’aligner les moyens de l’entreprise sur les besoins du produit.

Apporter le bon produit

Poser des hypothèses business

Avant de budgéter une chaîne de valeur, comment s’assurer que l’investissement effectué sera bénéfique à l’entreprise ? Construire un produit, c’est bien mais quel sera le revenu pour l’entreprise ?

Le coach aide l’entreprise à poser différentes hypothèses de business model pour valider que l’entreprise dispose des moyens nécessaires à la réalisation du nouveau produit. Il importe de vérifier que ce dernier créera une nouvelle opportunité pour l’entreprise ou renforcera les bénéfices existants.

Considérons deux contextes de formalisation du business model :

• le produit apporte une innovation pour une entreprise existante, mais l’entreprise peut s’appuyer sur une grande partie de son infrastructure pour monter le produit. L’entreprise doit analyser, à partir de son business actuel où se situent les points d’innovation et leurs impacts (cf. Business Model Canvas^[55]);
• l’entreprise est nouvelle, aucun business model n’a été imaginé ou le produit génère une toute nouvelle activité en rupture avec ce que fait l’entreprise. Le business model est dans ce cas totalement incertain : il est nécessaire de poser plusieurs hypothèses. (cf. Lean Canvas^[56])

Impacter l’utilisateur dans l’intérêt de l’entreprise

Les pistes d’innovation sont posées, l’entreprise connaît l’objectif de son produit. Elle a analysé les attentes de l’entreprise vis à vis du produit. Reste à savoir comment s’assurer que tout ce que contiendra le produit sera cohérent avec ces attentes ? Comment ne pas investir dans le vide ? Ne pas perdre de temps ?

Pour obtenir un résultat, le coach procède en trois étapes :

• Définir l’attente racine
• Identifier les fonctionnalités et actions impactantes
• Définir un plan évolutif

Définir l’attente racine

A ce niveau on ne souhaite pas définir les attentes pour les utilisateurs, mais bien les attentes en terme de retour sur investissement.

L’attente identifiée est souvent un objectif financier, comme l’explique Gojko Adzic dans son livre Impact Mapping, il est important de remonter d’un cran :

Ex : plus d’utilisateurs payants, plus de visibilité, de notoriété, de légitimité.

Identifier les fonctionnalités impactantes

Étape primordiale de la définition du produit, quelles fonctionnalités construire ?

Il existe plusieurs manière d’identifier des fonctionnalités :

• par la quantité : ouvrir totalement et générer du volume à trier (ex : brainstorming)
• par la qualité : questionner chaque fonctionnalité sous l’angle de l’impact attendu sur l’outcome (ex: Impact Mapping)

Il est parfaitement possible de traiter le sujet par un bout ou l’autre. L’important est surtout de s’assurer que chaque fonctionnalité ait un impact sur les usages d’un utilisateur et que ces usages permettent à l’entreprise d’avancer vers son attente racine.

Il est aussi important de réfléchir au processus d’utilisation du produit. Ce processus peut émerger des fonctionnalités impactantes identifiées ou peut, à l’inverse, structurer la phase d’idéation.

En fonction du contexte et de l’état d’équipe, le coach propose une combinaison d’atelier orientés ouverture, émergence et filtrage (libérer la créativité d’un groupe) ou au contraire structuration et questionnement (fournir un cadre à une équipe très créative et prolifique).

Des hypothèses c’est bien, une validation rapide c’est mieux

Voilà l’entreprise avec une série de tâches à réaliser et une planification de ses réalisations. Le gros du travail est encore devant. Pour que de bonnes idées deviennent de belles réalités, il faut bien les exécuter.

En s’appuyant sur les démarches Design Thinking, Lean Startup, Lean UX et Lean Analytics, mais aussi sur tous les modules de la rocket, l’entreprise va, en fonction de son avancement :

• Prioriser et planifier les travaux en se laissant des issues de secours en fonction des résultats terrain (cf Impact Mapping^[57] et Story Mapping^[58])

• Identifier un moyen de vérifier très tôt, voire avant même d’avoir conçu une première version, si le produit peut intéresser des utilisateurs
• Construire des prototypes de produits, d’écrans en numérique ou en papier et faire valider des parcours avec des utilisateurs réels
• Apporter de la valeur au travers d’une qualité intrinsèque irréprochable et d’un processus de livraison fiable et rapide
• Aller sur le terrain avec le produit, écouter et regarder à la manière du Gemba Walk pour apprendre
• Tester les hypothèses, confirmer, réajuster ou pivoter comme expliqué dans la démarche Lean Startup. Pivoter résulte de la prise de conscience de l’impossibilité pour le produit de confirmer le business model.
  Pour valider la viabilité de l’entreprise, aller chercher :

• de nouveaux segments
• de nouvelles idées
• de nouveaux moyens

A partir de ces processus, la démarche consistera à imaginer, construire et tester le plus rapidement et le plus souvent possible.

Culture produit

La culture produit c’est :

• comprendre les utilisateurs
• imaginer un produit qui leur permette de mieux vivre leur quotidien, de vivre de meilleures expériences d’usage
• mener les chantiers en avançant petits pas par petits pas, en validant systématiquement que les hypothèses prises sont les bonnes

Exemples d’ateliers

Comprendre l’utilisateur

• Empathy Map : https://dschool.stanford.edu/wp-content/themes/dschool/method-cards/empathy-map.pdf 

• Persona : https://fr.wikipedia.org/wiki/Persona_(marketing) 
• Vis ma vie : Accompagner un utilisateur pour se mettre dans sa peau

Définir la vision

• Elevator Pitch : http://readwrite.com/2010/04/16/the-art-of-the-elevator-pitch-10-great-tips/ 
• Product Box : http://www.innovationgames.com/product-box/ 
• Cover Story : http://www.innovationgames.com/on-the-cover/ 
• Remember the future : http://www.innovationgames.com/remember-the-future/ 
• 5 pourquoi : https://fr.wikipedia.org/wiki/Cinq_pourquoi 

Business Model

• Lean Canvas : https://leanstack.com/lean-canvas/ 
• Business Model Canvas : https://strategyzer.com/canvas/business-model-canvas 

Brainstorming

• Impact Mapping : https://www.impactmapping.org/fr/ (eng)
• Story Mapping : http://jpattonassociates.com/user-story-mapping/ 
• Cube “Exprimer et formaliser le besoin” : http://1cube-and-go.com/exprimer-formaliser-le-besoin/ 
• Customer journey map : http://www.servicedesigntools.org/tools/8 (eng)
• Event Storming : http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html 
• Formulaire de Kano : https://fr.wikipedia.org/wiki/Mod%C3%A8le_de_Kano 

Processus

• Design Thinking visual crash course : http://dschool.stanford.edu/dgift/ 
• Playing Lean : http://www.playinglean.com/ 

Bibliographie

• Business Model Generation d’Alexander Osterwalder et Yves Pigneur : https://strategyzer.com/books/business-model-generation
• Customer Centricity par Peter Fader : https://www.amazon.com/Customer-Centricity-Customers-Strategic-Essentials/dp/1613630166
• Impact Mapping par Gojko Adzic : https://www.impactmapping.org/fr/
• Running Lean par Ash Maurya : https://leanstack.com/running-lean-book/
• User Story Mapping par Jeff Patton : http://jpattonassociates.com/jeff-pattons-book-released-user-story-mapping/ 
• Value Proposition Design par Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith : https://strategyzer.com/books/value-proposition-design

Liens

• Why Lean Canvas par Ash Maurya : https://leanstack.com/businessmodelcanvas/, https://leanstack.com/why-lean-canvas/, https://hbr.org/2012/11/its-not-just-semantics-managing-outcomes

• Bootcamp bootleg - La boîte à outils du Design Thinking par la d.School of Design : https://dschool.stanford.edu/sandbox/groups/designresources/wiki/31fbd/attachments/acf2a/METHODCARDS_FRENCH_March_2014_m.pdf

Excellence de l'ingénierie

Exemples d’insatisfactions rencontrées en cas d’absence d’excellence de l’ingénierie :

• agacer/perdre un client parce qu’il rencontre des bugs en production,
• pas de vision objective de l’avancement car la phase d’intégration est systématiquement plus longue que prévue,
• difficulté à tenir les dates de livraisons,
• pas de boucle de feedback courte sur les fonctionnalités développées.

L’excellence de l’ingénierie est un des boucliers de la fusée agile.

Si le premier bouclier qu’est la culture produit a pour rôle de fournir des outils de navigation à la fusée^[59], le second protège la fusée et son équipage de perturbations indésirables.

Comment l’excellence de l’ingénierie peut-elle mettre en place le contexte permettant à l’équipage de mettre en toute sécurité les pleins gaz sur sa destination ?

Contenu

Éviter les météorites

Un utilisateur qui rencontre un bug en production, c’est un peu comme une météorite qui percute la fusée : le choc sera éventuellement encaissé. Mais la fusée n’est pas incassable, si ce genre de choc est répété trop souvent, cela peut mener à perdre des utilisateurs, voire même à remettre en question l’aventure stellaire.

Le souci de l’excellence doit être porté par chaque individu de l’équipe.

S’il est essentiel de rendre les individus responsables et pro-actifs^[60], il convient également de les accompagner à la mise en place de pratiques d’ingénierie visant la qualité du code produit et sa pertinence par rapport aux besoins de l’utilisateur.

Sécuriser le code avant intégration

Le premier souci du développeur est d’être en mesure de détecter ses propres erreurs et de les corriger, pour pouvoir sécuriser son code en s’assurant qu’il ne posera pas de problème au moment de l’intégration.

Test driven development

A la base, la mise en place de tests vise à éliminer les bugs, conduisant à la création d’un nouveau rôle, celui du testeur.

Mais plus il y a de tests, plus le temps passé à les écrire, à les maintenir, à les exécuter augmente, au point que le coût des tests en devient rédhibitoire.

Le développement dirigé par les tests (TDD) est une pratique d’ingénierie qui fait partie de la méthode Extreme Programming.

TDD propose une approche totalement différente, en proposant de commencer par écrire les tests unitaires avant même d’écrire le code.

Ecrire les tests d’abord, c’est prendre un moment de recul sur ce que doit faire le code, et améliorer sa compréhension de l’objectif poursuivi par la fonctionnalité.

Une fois les comportements attendus encadrés par les tests unitaires adéquats, on peut commencer à développer la fonctionnalité en codant délibérément une erreur (Test fail first), afin de s’assurer que le test fonctionne correctement. Et enfin, on recode la fonctionnalité, cette fois sans erreur et en essayant d’améliorer le code (refactoring).

Programmation en binôme

Une autre pratique de développement issue d’Extreme Programming est le binômage.

Cette pratique tire ses origines de la revue de code en poussant la pratique…à l’extrême ! Elle vise à détecter les bugs avant même que le code ne soit exécuté, en faisant la relecture en permanence, grâce à la collaboration bienveillante d’un de ses pairs.

Cette pratique est souvent associée à celle du TDD.

Un développeur joue le rôle de co-pilote en codant le test (il montre la direction à suivre), puis le deuxième développeur (le pilote) code la fonctionnalité associée à ce test.

Kata et coding Dojo

Un coding dojo consiste à se regrouper à plusieurs personnes pour développer une fonctionnalité. S’entraîner à développer dans un environnement sécurisé est un bon investissement pour limiter à l’avenir le nombre d’erreurs dans son code. C’est un comportement professionnel d’amélioration de ses compétences.

Sécuriser la portée du code

S’assurer que son code est exempt de bug est un premier pas vers l’excellence technique, mais tout cela est vain si la fonctionnalité développée n’est pas celle attendue par l’utilisateur.

Cela revient à éviter une météorite à babord pour percuter de plein fouet à tribord la planète que l’on n’avait pas vue.

Acceptance Test Driven Development

La pratique de l’ATDD est à la fois très proche et très éloignée du TDD.

Elle est proche dans la forme parce qu’elle prône de commencer par développer les tests avant de commencer à coder la fonctionnalité.

Elle est en revanche très éloignée dans le principe, parce que le TDD est une pratique de développeur qui vise à valider que son code est exempt d’erreur, alors que l’ATDD est une pratique d’équipe qui vise à s’assurer que la fonctionnalité développée correspond bien à ce qu’attend l’utilisateur.

Les tests d’acceptance sont écrits par le métier et permettent aux développeurs de mieux comprendre quel est l’objectif poursuivi par la fonctionnalité. En procédant de la sorte, on spécifie par l’exemple et on facilite l’appropriation.

L’ATDD est une pratique qui nécessite et renforce la collaboration de toute l’équipe et qui pilote le développement par l’expérience utilisateur.

Behaviour driven development

Le Behaviour Driven Development s’inscrit un peu en continuité de l’ATDD, à savoir s’assurer que la fonctionnalité développée correspond bien au besoin de son utilisateur.
Sa proposition de valeur est de raccourcir encore les boucles de feedback entre le développeur et le métier.

BDD propose une convention de langage facile à comprendre et à interpréter qui permet au métier d’écrire lui même ses tests.

Le développeur n’a plus besoin de recoder les tests fournis par le métier, préservant des erreurs d’interprétation.

Un autre intérêt est qu’en insérant du langage métier dans le code, on le documente au plus près.

Automatiser la détection des météorites

L’étape suivante pour mener une équipe vers l’excellence technique, c’est de rationaliser le temps qu’elle passe à ne pas produire de valeur.

Si les tests unitaires et les tests d’acceptance permettent de protéger la fusée, ils prennent du temps à être joués manuellement.

L’automatisation des tests vise à décharger l’équipe de cette tâche.

Attention au big bang

Dans ce que nous avons vu précédemment, nous avons décrit des pratiques qui permettent au développeur et à son équipe de sécuriser la qualité de leur code et son adéquation avec les besoins de l’utilisateur.

Seulement, beaucoup de projets mobilisent plusieurs équipes de développement dans le but de développer un même produit et le moment où le code des différentes équipes doit être fusionné peut souvent être synonyme de Big Bang.

Intégrer souvent

Lorsque du nouveau code est intégré au reste de l’application, certains conflits (effets de bord) peuvent apparaître.

Une bonne pratique consiste à intégrer une tâche dès qu’elle est développée, plutôt que d’attendre d’avoir développé toute une fonctionnalité (ou pire, un produit !) et de se retrouver avec une masse de conflits à régler.

Automatiser l’intégration

Intégrer son code ne génère aucune valeur pour le client et prend du temps au développeur.
Une bonne pratique est donc l’automatisation de cette tâche afin de se concentrer sur ce qui a de la valeur. Cette pratique, tirée elle aussi de l’Extreme Programming, est appelée l’intégration continue.

Definition of Done

Travailler en équipe suppose aussi de se synchroniser sur la notion de “Fini”.

En effet, ce qui peut être fini pour une personne ne l’est pas forcément pour une autre.

Par exemple, si en tant que développeur je considère que mon développement est terminé lorsque les tests passent sur ma machine, il se peut que sur l’environnement d’intégration, cela ne fonctionne pas : ce qui est fini pour moi ne l’est pas dans les faits pour le reste de l’équipe.

Cela génère inévitablement des temps d’attente qui n’apportent pas de valeur au client.

Il est donc important de clarifier la notion de “Fini” pour l’équipe et de la rendre explicite via le Management Visuel^[61].

Activer l’hyperdrive pour passer à la vitesse de la lumière

Une fois levés les risques de mauvaise qualité du code et de mauvaise intégration, la fusée agile doit trouver sa vitesse de croisière pour éviter une consommation excessive de carburant.

Déploiement continu

Les équipes de développement ont pour objectif de livrer souvent de la valeur aux utilisateurs, alors que les équipes en charge de l’infrastructure de production cherchent à garantir la stabilité du système : l’écart d’objectif entre ces deux équipes est manifeste.

Le problème, c’est que moins souvent on déploie, plus le TTR (Time to Repair) augmente :

Il y a donc un enjeu énorme à déployer régulièrement en production pour :

• diminuer le time-to-market
• diminuer le time-to-repair

Il s’agit en premier lieu tout d’un enjeu humain, le déploiement continu est affaire de collaboration.

Automatisation du déploiement et de l’approvisionnement

Une des préoccupations des équipes en charge de l’infrastructure de production porte sur l’approvisionnement. Pour le résumer un peu grossièrement, cela consiste à s’assurer que les machines de production sont suffisamment puissantes (CPU, mémoire vive, espace disque) pour tenir la charge.

A l’inverse des environnements d’intégration, le trafic sur l’environnement de production peut fluctuer et demander des adaptations pour “absorber la charge”.

L’automatisation suggère donc de relier les métriques métier avec les métriques de production pour pouvoir ajuster la capacité de planification en temps réel.

La virtualisation et la conteneurisation sont des pistes pour rester souple dans la gestion de la capacité de planification.

Procédure de rollback

Bien que toutes les précautions soient prises pour ne pas pousser de bug en production, cela peut malheureusement arriver.

Il faut donc pouvoir restaurer l’état précédent de la production aussi vite que possible.

La procédure de rollback doit donc faire partie de la Definition of Done du packaging d’une version.

Une architecture par intentions

L’approche traditionnelle du génie logiciel, inspirée du génie civil, a valorisé l’importance de l’architecte. Cet expert en conception établit à l’avance des plans que des équipes techniques se chargent ensuite de réaliser sans interactions fréquentes.

Une démarche de bon sens qui aboutit à une perte d’apprenance

Cette démarche, apparemment de bon sens, a en fait conduit à construire un gouffre entre des experts qui deviennent spécialistes en construction d’architecture idéale et des développeurs qui subissent ces architectures comme une contrainte non négociable, sans possibilité d’enrichir la conception de leur besoin proche du terrain.

Risques : démotivation, incompréhension, incommunication, perte d’apprenance (les architectes n’apprennent pas des problèmes des équipes, les équipes n’apprennent pas de l'expertise des architectes) et au final augmentation des délais de réalisation et donc perte d’agilité.

Le manque de feedback entre architectes et équipes de réalisation

Les architectes deviennent progressivement des spécialistes de caractéristiques sophistiquées relevant du YAGNI (You AIn’t Gonna Need It), enfermés dans leur tour d’ivoire. Pendant ce temps, les équipes de production sont susceptibles de dériver dans l’optimisation locale ou la tentation éternelle de réinventer leur modèle de roue, incompatible avec celui de l’équipe d‘à côté.

Plusieurs équipes = nécessité d’unifier l’architecture émergente

Un manque de stabilité architecturale au niveau d’une seule équipe peut encore se gérer à grands coups de refactoring permanent. Pas de blocage, pas d’effet de bord apparent, sinon une capacité à livrer de la valeur qui diminue insidieusement : le refactoring prend de plus en plus de temps.

Aujourd’hui, il devient de plus en plus fréquent de conjuguer le travail de plusieurs équipes pour construire un produit. Se reposer sur la seule conception émergente de chaque équipe isolée génère de l’incohérence, des gâchis, des conflits inacceptables.

Comment aligner les conceptions locales ?

En réponse à ce problème, émerge aujourd’hui la notion d’architecture par intention qu’essaye d’appliquer un framework comme SAFe. Cette architecture, qui se veut agile, vise à réconcilier réflexion en amont et communication entre les architectes et les développeurs, afin de mettre en place des boucles de feedback courtes.

Objectif : permettre à l’architecture à la fois d’anticiper les besoins, de proposer des réponses unifiés, d’investir dans des plateformes techniques et de continuer à pouvoir s’adapter en se nourrissant des besoins fonctionnels.

Réf : http://www.scaledagileframework.com/agile-architecture/

Bibliographie

• Extreme Programming Explained (Embrace Change) de Kent Beck : https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658
• Test Driven Development (By Example) de Kent Beck : https://www.amazon.fr/Test-Driven-Development-Kent-Beck/dp/0321146530

Liens

• Introducing BDD, Dan North : https://dannorth.net/introducing-bdd/

La culture agile :
propulseur vers la réussite

Nécessité d’une transformation

Quelques raisons de frissonner :

• La durée de vie des grandes entreprises s’est considérablement réduite, elle est en moyenne aujourd’hui de 15 ans. ^[62](Note actualisée : elle tend maintenant vers 5 ans !)
• Le ROA (Bénéfice économique/actif économique) a baissé de 75% depuis 1965.
• Plus il y a de salariés dans une entreprise, moins elle est productive.
• Sur les 500 plus grandes entreprises répertoriées dans le classement annuel du magazine “fortune”, moins d’une quarantaine ont plus de 100 ans.
• Des enquêtes récurrentes alertent sur le principal frein vers une transformation agile : l’incapacité à changer la culture de l’organisation.

www.versionone.com/state-of-agile-survey-results/ 

Existe-t-il une corrélation avec cette autre statistique ?

Since 1983, the number of managers, supervisors, and support staff employed in the U.S. economy has nearly doubled, while employment in other occupations has grown by less than 40%, according to our analysis of data from the Bureau of Labor Statistics. 

Depuis le rapport “21st Century Manufacturing Enterprise Strategy” datant de 1991, plutôt que de renforcer bureaucratie, procédures et hiérarchie, l’agilité propose d’investir sur de petites unités auxquelles on confère une délégation de pouvoir, tout en s’assurant d’un engagement à contribuer à une cause commune, une finalité partagée, ciment de l’organisation.

Que changer ? Par où commencer ?

Comme le montre l’infographie ci-dessous, la culture d’une organisation se matérialise dans de multiples aspects et se manifeste dans les comportements de chacun de ses membres.

www.torbenrick.eu^[63]

Commencer par les pratiques ?

Une première erreur consiste à penser qu’encourager de nouvelles pratiques sera suffisant pour changer la culture. Hélas, rapidement, les changements de pratiques se confronteront aux modèles mentaux existants. Et comme l’avertit Peter Drucker : “la culture mangera le changement au petit déjeuner”.

la culture, terreau des manifestations externes

D’où l’importance d’investir dans la “maîtrise personnelle”^[64], génératrice de changements profonds, comme nous y invite le stabilisateur de vol de la Rocket.

Et les comportements ?

Réciproquement, les neurosciences nous confirment que les changements de pensée qui ne s’incarnent pas dans les comportements ne s’ancrent pas et donc n’auront pas d’impacts à moyen terme. La meilleure connaissance des mécanismes de notre cerveau nous apprend aussi qu’il faut mobiliser l’émotion pour changer durablement.

Il est donc nécessaire de concevoir la transformation agile d’un point de vue systémique et interactionnel : il faut agir à plusieurs endroits et susciter des boucles vertueuses entre comportements, émotions et processus cognitifs.

les trois points d’entrée du changement en PNL^[65]

Les niveaux logiques

Ces trois citations nous invitent à envisager la tension générative à maintenir entre le changement et l’identité. Comment discriminer entre ce qui doit changer et ce qui fait partie de notre identité ? A quel moment la transformation provoque un risque de perte d’identité et donc de disparition de l’organisation ?

Un remarquable outil d’exploration de ces considérations nous est fourni par Robert Dilts avec les niveaux logiques. Il permet de représenter visuellement les différents niveaux de questionnement et de distinguer entre niveaux fonctionnels (environnement - comportements - capacités ) et essentiels (valeurs - croyances - identité - appartenance).

Application des niveaux logiques à l’entreprise

Le coach d’organisation pourra par exemple utiliser cet outil avec les membres d’un CODIR pour les aider à s’aligner sur les différents niveaux.

Le courage du choix - le choix du courage

Le leader inspirant

Deux ouvrages récents sur une nouvelle génération d’entreprises ont retenu l’attention du monde de l’entreprise et suscité débats, conférences, articles de blogs et autres échanges animés, voire controverses. Il s’agit de :

• “Liberté & Cie” d’Isaac Getz, paru en 2009 (http://liberteetcie.com/entreprise-liberee/)
• “Reinventing Organizations” de Frédéric Laloux, paru en 2014^[66]

La question a été posée aux deux auteurs : quelle est la condition nécessaire au succès d’une transformation vers une organisation du type de celles que vous décrivez dans vos ouvrages ?

Leur réponse a été identique:

• un leader qui décrète une transformation en se l’appliquant d’abord à lui-même ;
• une contextualisation spécifique à l’entreprise, chaque cas étant différent.

Le rôle du leader est déterminant. Nous l’avons constaté à chaque fois dans les transformations agiles : si le sponsor n’est pas impliqué avec clarté et détermination et s’il ne commence pas par s’appliquer à lui-même la transformation demandée, la désillusion est quasi garantie !

La Confiance

L’exemplarité et l’engagement du leader sont également clés sur cet élément déterminant du succès : créer un climat de confiance. La fameuse résistance au changement se nourrit en réalité d’une interprétation de l’écart entre les belles paroles, les discours de motivation et le constat des comportements, structures et processus qui demeurent inchangés.

McKinsey fournit un bon outil pour travailler cet aspect avec la matrice “Change Influence Model” :

La matrice se décompose en quatre quadrants visant à recenser les différents leviers incitant à un changement personnel. C’est un excellent outil d’identification des mécanismes d’adhésion au changement. Volontairement le coach d’organisation emploiera l’expression positive  « adhésion au changement » plutôt que son alternative négative « mécanisme alimentant les résistances personnelles au changement ».

La facilitation commence par une question :

“Je changerai mon état d’esprit et mon comportement si… ?”

Se référer à l’article de blog “Des canevas à broder/3- On se lève tous pour l’intelligence collective !” pour une description d'utilisation.^[67]

Comment commencer ?

Le proverbe dit “Un éléphant, ça se mange une bouchée à la fois”.

En dehors de l’idée saugrenue de vouloir manger un éléphant, retenons l’idée des petites bouchées. La culture ne se modifie pas du jour au lendemain, par décret. Elle émerge à partir d’une multiplication d’actions sur des niveaux différents.

Nous souhaitons terminer ce chapitre en vous proposant une première petite bouchée : un exemple d’atelier pour déclencher le mouvement.

Nous avons abordé dans le chapitre sur le “management agile”, l’idée que le manager devient aussi un facilitateur d’intelligence collective. Comme le souligne Peter Senge, celle-ci demande de faire ensemble. La Culture Map alimente les premiers échanges pour initier ce “faire ensemble”.

En reprenant une idée de Dave Gray^[69], Alexander Osterwalder a proposé un outil d’organisation du changement culturel souhaité. Le principe est très simple : trois rangées permettent de dégager en trois temps le changement culturel nécessaire pour obtenir les résultats spécifiés.

La démarche reprend deux questions très classiques en coaching :

• de quoi voulez-vous vous éloigner ?
• vers quoi voulez-vous aller ?

La Culture Map de Alexander Osterwalder et Dave Gray^[70]

Et reprenant la formule de Kurt Lewin qui spécifie que le comportement individuel est fonction de l’environnement^[71], la question à traiter devient :

 “Comment l’organisation crée-t-elle un environnement
qui puisse encourager les personnes à adopter les comportements attendus ?”

Pour les détails de facilitation, se référer à l'article “Des canevas à broder/1- Culture Map”^[72].

Comment poursuivre ?

La suite vous appartient…

Bon voyage !

Les (étroits) boooksketaires

Gregory Alexandre (@gregalexandre)

Faire le déplacement de Lyon à Carnac pour écrire un ouvrage qui décrit et partager nos démarches, j’ai signé !

L’exercice fut enrichissant sur plusieurs aspects : écrire un ouvrage, le faire à plusieurs, le faire selon les démarches itératives et incrémentales que nous prônons, vivre les mêmes écueils que les équipes que nous accompagnons, trouver nos solutions.

Je remercie l’instigateur Christophe d’avoir adapté le cadre pour me permettre de venir deux jours sur quatre et nous permettre de tester la vie d’une équipe distribuée.

Merci à mes camarades pour les bons moments passés, les mouettes conspuées, les jeux de mots pourris et le jus de cerveau partagé. Merci à Christophe d’avoir rendu possible cette expérience et de nous avoir présenté aux menhirs locaux.

Arnaud Gervais (@arnaud_gervais)

Ecrire un livre à 100 doigts en 4 jours, c'est possible !

Une riche expérience de travail collectif agile avec beaucoup de sprints, de standups, de boucles de feedback et d'amélioration continue.

Merci à mes collègues co-auteurs pour les moments de partage, de rire, de doute.

Et un merci particulier à Christophe pour avoir lancé l'idée et l'invitation et s'être plié en 4 (jusque dans le van) pour nous accueillir dans sa maison :)

Christophe Keromen (@ckeromen)

Ma gratitude à mes collègues co-auteurs qui ont accepté de braver la pluie bretonne^[73] fin décembre pour une aventure collective.

Pensées et dédicaces à mes ex-collègues coaches agiles du plateau agile d’AXA GS au milieu de qui l’idée de l’Agile Rocket a émergé en 2015. Mention spéciale à Yannick Quenech’du qui lui a rapidement donné une représentation visuelle avec talent^[74].

Enfin, merci les mouettes pour votre soutien vocal et affectif.

Et une citation à emporter : “L'amour rend agile à tout l'âme la plus pesante.” Molière

Olivier My (@OyoMy)

Que d’énergie et d’émotions avec mes partenaires d’écriture ! Revivre une expérience Agile avec ses difficultés et ses succès était rafraîchissant, cela va sans aucun doute moduler mon discours aux équipes maintenant ! :-P

Merci aux boooksquetaires d’avoir su apporter leur individualité dans le collectif, chacun à leur façon, dans la joie et la bonne humeur ! Mention spéciale à Christophe pour nous avoir permis de vivre cette aventure et pour avoir dormi dans un van pour nous héberger ! Un souvenir mémorable de 2016 ! ;-)

Julien Porot (@cranedemorse )

Quelle expérience motivante que ces quatre jours passés en Bretagne !

Quatre jours qui riment avec émulation collective, où chacun a apporté ses expériences, ses connaissances, ses anecdotes, ses questions.

Quatre jours qui riment aussi avec vivre ensemble, où nous avons tout partagé, du beurre salé au moment du petit déjeuner, à la rasade de rhum du soir, avec pour seules constantes la bonne humeur et la joie d’être ensemble.

Un grand merci à Christophe d’avoir porté cette initiative et d’avoir tenu la barre sans faillir pour garder le cap sur notre étoile du nord et un grand merci également à Arnaud, Grégory et Olivier pour tous ces échanges enrichissants.

Remerciements

A Goood! qui a accepté de financer ce projet nous donnant les moyens de boooksprinter quatre jours pour livrer une première version de l’Agile Rocket Guide^[75].

Bonus

L’Agile Rocket à travers les âges

Agile Rocket

Guide

Ce guide, rédigé par cinq coaches agiles de la société Goood!, vous propose de construire un voyage de transformation agile de façon modulaire et progressive.

Au travers de la métaphore d’une fusée à plusieurs étages, les auteurs vous amènent à découvrir et mettre en oeuvre progressivement les composants d’une agilité contextualisée et respectueuse.

Sponsor, managers et équipage sont conviés à imaginer leur destination : la mythique étoile du Nord. Puis, accompagnés par la facilitation bienveillante des coaches, ils amélioreront progressivement et de manière structurée leur fonctionnement quotidien.

Prêts à embarquer à bord de l’Agile Rocket ?

Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Pas de Modification 4.0 International.