Agile Rocket

Guide

rocket.002.jpeg

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.

Note : au vu de la difficulté de la sélection des profils, nous avons malheureusement dû mettre de côté Jean-René, cuistot. Cependant, l’agilité peut se rechercher dans tous les secteurs !

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.

"Life is what happens to you while you're busy making other plans." John Lennon

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.

Picard management tip:
Don't try to go at maximum speed all the time. You'll burn out your engines. @PicardTips

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.

"L’inconvénient de la décentralisation du pouvoir est un fonctionnement en silos,
ce qui est une entrave à l’apprenance en entreprise." Peter Senge

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.

IMG_5321 petit.jpg

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]).

“Pour atteindre l'inaccessible étoile.” J. Brel

“L’accent devrait être mis sur POURQUOI nous faisons quelque chose.” Edwards Deming

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

To enable any individual to immediately recognize the standard
(and any deviation from it) and manage the process

“Perfect is a verb.” Kent Beck

“May what I do flow from me like a river, no forcing and no holding back, the way it is with children.” Rainer Maria Rilke

“But anyone who has experienced flow knows that the deep enjoyment it provides requires an equal degree of disciplined concentration.” Mihaly Csikszentmihalyi

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) :

“We have learned how to develop five-minutes and even one-minute managers. But we would do better to ask ourselves what it takes to be an executive who helps build a better future.” Mihaly Csikszentmihalyi

“There is always one more thing to learn.” Steve Jobs

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

“In a three-year period, we had 78 projects, and 77 of them were delivered on time, on budget, and in scope. Then I surveyed the customers and found out that none of them was happy!”

Mary Poppendieck, Lean Software Development: An An Agile Toolkit

“I'm not a great programmer; I'm just a good programmer with great habits.” Kent Beck

“You can't go fast building on crappy code.” Dean Leffingwell

“In fact, in an agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow.” Jim Highsmith

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 ?

hole boat.png

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 :

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 ?

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 ?

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…


Retrouvez la bibliographie de l’AgileRocket Guide sur : https://inventaire.io/inventory/AgileRocket 

Capture d’écran 2017-01-21 à 18.51.10.png


Partie 1 : 

les étages de la fusée


North Star : embarquement immédiat !

"One day Alice came to a fork in the road and saw a Cheshire cat in a tree.

"Which road do I take?" she asked.

"Where do you want to go?" was his response.

"I don't know," Alice answered.

"Then," said the cat, "it doesn't matter."

Lewis Carroll

Structure du chapitre

La question

Déroulement

La vision

Élaborer la vision

Préparer l'équipage

Lancement de l'aventure : encourager le dialogue

Exemples d'atelier - Bibliographie - Liens

La question

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

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 :

“Je crois que cette nation devrait s’engager à atteindre l’objectif, avant la fin de cette décennie, de faire atterrir un homme sur la Lune et de le ramener en sécurité sur Terre”

JFK, Man on the Moon Speech

Joint Session of Congress May 25, 1961

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 :

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 :

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 :

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

Un exemple de protocole pour élaborer collectivement la mission peut être :

1) générer individuellement des mots en lien avec la mission

2) mettre en commun pour repérer les mots "forts"

3) former une phrase avec ces mots

4) itérer sur la phrase jusqu’à consensus

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 :

L'utilisateur final est-il clairement identifié, et facilement joignable ?

L'équipe est-elle co-localisée ?

Combien y a-t-il de personnes dans l'équipe ?

( alerte si plus de 10)

L'équipe est-elle stable ? Si non, à quelle proportion ?

(alerte si moins de 70%)

Quelle est la maturité de l'équipe ?

Depuis combien de temps travaillent-ils ensemble avec de bons résultats ?

Y a-t-il une volonté de changer ?

Y a-t-il des dépendances avec d'autres équipes ?

L'équipe dispose-t-elle du temps nécessaire à la transformation ?

(ateliers, expérimentations, réunions…)

etc.

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

Bibliographie

Liens

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Ne pas impliquer les sponsors dès le départ et attendre qu’ils réagissent aux premières difficultés
  2. Organiser une session de lancement en salle de conférence avec de beaux powerpoints et plein de bullet-points en évitant soigneusement tout dialogue
  3. Demander aux managers de définir la mission à la place de l'équipe, qui a mieux à faire avec son produit


Management visuel

Structure du chapitre

La question

Une histoire

Description de la démarche

Template de mise en oeuvre

Exemples d’atelier - Bibliographie

La question

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

Exemples d’insatisfactions rencontrées :

UNE HISTOIRE...

Une équipe sous l’eau douce

L’équipe de Cathy travaille à la réalisation de la v2 d’un produit qui permet la surveillance de l’orignal en milieu d’eau douce. Son équipe est en charge de la réalisation des nouvelles fonctionnalités, mais aussi de la maintenance de la v1.

Cathy, manager de l’équipe, se retrouve en réunion de CODIR. A la question “quel est l’avancement de ce produit stratégique ?”, elle reste évasive car elle a bien du mal à donner une réponse précise.

Son équipe est formée de quatre personnes.

Ernestette est surchargée par le travail et personne ne peut venir l’aider.

        Pierre-William, lui, est tranquillou sur son ordi à développer ce pourquoi on a fait appel à lui, il sait qu’il a un mois pour terminer sa réalisation, il sait ce qu’il doit réaliser et n’a besoin de personne. Il avance.

        Edouardo est de support de production ce mois-ci, il a passé les deux premières semaines du mois à se tourner les pouces car aucun bug. Depuis 3 jours, ses journées sont infernales, du 7h - 22h pour traiter un tas d’anomalies remonté sur une fonctionnalité.

        Lucette est nouvelle arrivante dans l’équipe, elle est junior et travaille aussi à la maintenance de la v1. Depuis deux jours, elle se retrouve bloquée par un bug coriace.  C’est l’horreur, elle ne sait pas à qui s’adresser. Edouardo est sous l’eau, Pierre-William lui répond que ce n’est pas son problème et Pabuelito, aussi sur la maintenance, est malheureusement en congés pour 3 semaines encore.

Kanban version Lego par Hakan Forss[6]

        

Cathy, après discussion avec Ernestette et Edouardo, décide de se faire aider pour trouver un moyen de régler les problèmes. Elle a déjà vu des équipes rendre visible leur travail au travers d’un “Management Visuel”. Elle décide de s’adresser au meilleur coach, Jaffar Breton, pour bénéficier d’un accompagnement personnalisé.

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”.

 

Challenge de l’équipe

L’équipe définit sa « condition cible » et la traduit sous la forme d’indicateurs de performance. Ces derniers montrent la qualité de ce que l’équipe produit, dans quels délais et avec quelle productivité ; le tout, du point de vue du résultat final, c’est-à-dire du point de vue du client.

Les indicateurs définis doivent donc couvrir les sujets suivants :

– Qualité du service ou produit livré : l’équipe a-t-elle réussi à livrer la bonne fonctionnalité du premier coup ?

– Respect des délais de livraison attendus par le client (et pas uniquement ceux négociés avec lui) ou le stock (le volume des demandes client dans le backlog que l’équipe n’a pas encore pu traiter). Charge à l’équipe de s’améliorer pour s’approcher de l’attente client.

– Productivité : indicateur clé pour suivre l’amélioration de la capacité de l’équipe.

– Satisfaction client : l’équipe peut avoir l’impression que tout va bien alors que le client n’est pas entièrement satisfait.

Tiré du “Petit guide de management lean à l’usage des équipes agiles”[7]

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.

Système

On parle de système pour représenter le processus de réalisation :
il vise à fournir de la valeur en continu.

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”

Scrum et transparence

En Scrum, le premier pilier est Transparence. C’est cette transparence qui soutient le deuxième pilier, l’Inspection, qui permet à son tour l’Adaptation.

Dans ce framework, la transparence se matérialise au travers des différents artefacts que va générer l’équipe (Scrum Board, Burndown chart), mais surtout des incréments de produit potentiellement livrables.

Grâce à ces informations et au feedback recueilli lors de la revue de Sprint, l’équipe, au moment de la rétrospective, pourra prendre les bonnes décisions pour s’améliorer, le Product Owner pourra réaménager le Product Backlog pour optimiser le flux de valeur.

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

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.

Template de mise en oeuvre

Le coach guide l’équipe en 3 étapes :

  1. Qu’est-ce qu’un management visuel et comment bien visualiser ?
  2. Commencer par représenter le système.
  3. Travailler à gérer le système à la lumière de sa représentation sur un tableau.

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 :

Un bon management visuel permet de répondre aux questions suivantes :

  1. Quel travail est en train d’être fait ici ?
  2. Comment le travail doit-il être fait ?
  1. Quel est notre processus ?
  2. Qu’est-ce qui est normal/attendu ?
  1. Comment les problèmes sont-ils remontés
  1. Qu’est-ce qui n’est PAS normal/attendu ?
  2. Qu’est-ce qui empêche notre travail d’être fluide ?
  1. Comment chacun sait ce qu’il y a à faire ?
  2. Est-ce que les objectifs métier sont atteints ?

Hakan Forss[8] 

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

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.

... the code is more what you’d call “guidelines” than actual rules

Captain Barbossa dans “Pirates des Caraïbes”

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

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 :

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

        

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.

Au démarrage de la pratique, le coach veille au respect de quelques règles de conduite :

  • commencer à l'heure prévue ;
  • respecter la timebox ;
  • parler fort et à l'équipe entière ;
  • démarrer par les impedimenta[11];
  • nettoyer le board et supprimer les tickets inutiles ;
  • ne pas régler les problèmes lors du daily.

Détecter les impedimenta

Impedimenta

nom masculin pluriel

Charrois, bagages, etc., qui alourdissent la marche d'une armée.

Littéraire. Ce qui entrave l'activité, le mouvement.

Dans notre contexte, impedimenta désigne à la fois les obstacles qui empêchent d’avancer et les freins qui ralentissent le déplacement. Ces derniers sont souvent négligés alors qu’ils représentent un gisement de gains en efficience.

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

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.

“Ce qui est important est rarement urgent et ce qui est urgent rarement important” Eisenhower

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  :

Exemple de modèle de carte d’impedimenta

“L’authenticité implique de vivre sous le mode du « je », et non du « on », ce mode de vie impersonnel dans lequel l’individu se perd dans la masse.” Heidegger

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

Effort pour l’équipe et les managers

Temps nécessaire pour construire le management visuel et apprendre à l’utiliser.

Sur un mois, cela se répartit :

  • en une demi-journée pour identifier le problème et lancer l’initiative ;
  • en une demi-journée d’apprentissage ;
  • en trois demi-journées de construction du management visuel ;
  • en 20 minutes par jour pour la gestion du travail lors du daily meeting.

Il est intéressant de prévoir 2 jours supplémentaires pour des ateliers ad-hoc avec l’équipe.

Charge pour le coach

  • 1 atelier initial d’identification du problème
  • 1 mini-formation de 3h
  • 3 ateliers de 3h pour construire le management visuel
  • 10 daily meetings de 20 minutes
  • 2 jours pour des réunions et des ateliers à la demande

Ex. de charge pour ce module

Exemples d’atelier

Bibliographie

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Demander au manager ou au coach de construire le management visuel le plus beau et le plus pertinent pour l’équipe
  2. Représenter le challenge de l’équipe comme seulement une date de livraison à respecter, sans définir ce que serait le succès d’un point de vue utilisateur
  3. Attendre que le manager soit là pour démarrer le daily meeting et compter sur lui pour régler les problèmes de l’équipe

Amélioration Continue

Structure du chapitre

Les questions

Une histoire

Description de la démarche

Template de mise en oeuvre

Exemples d’atelier - Bibliographie

Les questions

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 ?

Successful Evolutionary Change for Your Knowledge Business” David J Anderson

Exemples d’insatisfactions rencontrées :

UNE HISTOIRE...

Chanter mieux avec les mouettes

Hippolyte, émérite ornithologue et joueur de cornet à pistons à ses heures perdues, a demandé à une petite équipe de lui développer un logiciel permettant l’étude de la gamme chromatique des chants de mouettes.
Son objectif est de pouvoir prédire l’apparition de ces gammes car il souhaite monter un spectacle d’improvisation musicale animalier.
L’équipe est constituée de J
ean-Mouloud (chef de projet), Charleline (développeuse), Clémenton (développeur) et Lolilette (testeuse).

Malgré des tests très appliqués de la part de Lolilette, les versions livrées à Hippolyte présentent souvent des imperfections, ce qui, d’une part, a tendance à beaucoup frustrer l’équipe et de l’autre, inquiète énormément le client. Ce dernier a l’impression qu’il ne sera jamais prêt pour la première représentation.

Chaque nouvelle fonctionnalité développée fait pourtant l’objet de nombreux allers-retours entre Charleline, Clémenton et Lolilette.

Grâce à son tableau de suivi, l’équipe constate qu’elle passe en moyenne 50% de son temps à corriger des bugs et se rend bien compte qu’elle a un vrai problème de qualité. Mais elle n’a aucune idée de comment s’y prendre pour le résoudre.

Le chef de projet Jean-Mouloud, en accord avec le client Hippolyte, décide de faire appel à un coach de renom, Jaffar Breton, pour les accompagner sur la mise en œuvre d’une démarche d’amélioration continue.

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 :

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 :

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 ?

Une opinion partagée est un fait.- Claudio Perrone

Claudio Perrone estime qu’un problème remonté par une personne est au départ le fruit de son opinion. Il est donc nécessaire de s’assurer que ce problème est partagé par l’ensemble de l’équipe avant de s’engager dans sa résolution : l’investigation coûte quoi qu’il arrive du temps et de l’argent.

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

“Avoir une option n’est pas un choix ; deux options est un dilemme ;

trois options offrent de nouvelles possibilités.” Virginia Satir

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.

Exemple de problématique : “Je suis manager et mon équipe manque de cohésion”

  • Option 1 : je peux organiser un team building hors des murs
  • Option 2 : je peux effectuer des entretiens individuels avec chacun des membres de l’équipe
  • Option 3 : je peux faciliter une rétrospective d’équipe

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 :

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

 

Exemple 2 : Carte Kaizen

Exemple 3 : Kata

Mode opératoire - Kata

  1. Quelle est la situation cible ?
  2. Quelle est en fait la situation actuelle ?
  1. Qu’avez-vous planifié comme étant votre dernière étape ?
  2. A quoi vous attendiez-vous ?
  3. Que s’est-il réellement passé ?
  4. Qu’avez-vous appris ?
  1. Quels sont les obstacles qui selon vous, vous empêchent d’atteindre votre situation cible ? Lequel adressez-vous en ce moment ?
  2. Quelle est votre prochaine étape ? (prochaine expérimentation) Qu’en attendez-vous ?
  3. A quelle vitesse pouvons-nous aller voir ce que l’on a appris en mettant en oeuvre cette étape ?

Exemple 4 : A3 - Agendashift

Mode opératoire - A3 (Agendashift)

Mike Burrows recommande de procéder ainsi :

  1. Structurer l’hypothèse
  2. Faire émerger les suppositions et les dépendances. Sont-elles à valider ? A résoudre ?
  3. Définir les expérimentations pilotes pouvant potentiellement générer de nouveaux A3.
  4. Évaluer les risques que l’on pressent pour la mise en oeuvre de ces expérimentations, les avantages et les inconvénients.
  5. Voir si l’évocation des risques devrait mener à l’élaboration d’autres expérimentations pilotes.
  6. Réfléchir aux personnes directement impactées puis aux autres parties prenantes ou influentes.

La partie spécifique aux idées sera potentiellement remplie après la mise en oeuvre de l’expérimentation pour y inscrire les apprentissages.

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.

Popcorn Flow

Popcorn Flow[18] propose un modèle de tableau PDCA permettant de suivre les expérimentations. Claudio Perrone le définit comme un tableau d’apprentissage qui se combine très bien au tableau de création de valeur déjà présent.

Afficher l'image d'origine

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 :

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

Template de mise en oeuvre

Pré-requis :

Effort pour l’équipe et les managers

Temps nécessaire pour mettre en oeuvre une démarche d’amélioration continue, structurer et générer des comportements de résolution de problèmes.

  • Disponibilité de l’équipe avec le coach équivalente au total à 1 jour (réunion et ateliers cumulés) + 0,5 jour pour la gestion des actions d’amélioration + 0,5 jour de rétrospective finale
  • Temps dédié au traitement des actions dépendant du contexte, à estimer avec le coach en début de module
  • Disponibilité du sponsor 30mn par semaine pour suivre l’évolution

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]

Charge pour le coach

  • Initialisation de l’initiative avec le demandeur et l’équipe
  • une durée de 6 semaines d’assistance (incluant une rétrospective de clôture) à raison d’1/2j par semaine en moyenne
  • une prolongation optionnelle de 4 semaines de support (un Daily Meeting + une participation à des ateliers par semaine)
  • 4 réunions sur demande ou ateliers (max 2h)

Synthèse de l’accompagnement

Exemple de répartition des activités

Cadence

Type

Durée

Participants

Activités

Jour

Daily Meeting

20 mn

équipe + coach

Synchronisation

Détection d’impedimenta

Jour

Impedimenta Meeting

30 mn

(maxi)

ad’hoc + coach

Gestion des impedimenta

Semaine

Revue

Amélioration continue

30 mn

équipe + sponsor + coach

Sponsor-Équipe

Synchronisation

(Escalade/Vision/Besoins...)

Semaine

Gestion de l’Amélioration continue

60 mn

équipe + coach

Affinage du backlog d’amélioration continue

Revue

Semaine

Synchro Sponsor/Coach

30 mn

sponsor + coach

Synchronisation sur les objectifs, la progression, les impedimenta de l’initiative

Semaine

Amélioration continue

Rétrospective

60 mn

équipe + coach + sponsor

Rétrospective de l’initiative

Exemples d’ateliers

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

Rétrospectives exploratoires : changer nos processus

Ateliers de résolution de problèmes

Bibliographie

 

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Vouloir régler tous les problème à la fois en y mettant toute notre bonne volonté
  2. Lancer en parallèle de nombreuses actions d’amélioration irréalisables et dont on ne maîtrise pas la portée
  3. Toujours privilégier le temps de la production à celui de l’amélioration


Flux

Structure du chapitre

La question

Une histoire

Description de la démarche

Template de mise en oeuvre

Exemples d’atelier - Bibliographie

La question

Comment optimiser le flux de production de valeur,

la prédictibilité de la livraison finale au client sans surcharger les équipes ?

Exemples d’insatisfactions rencontrées :

UNE HISTOIRE...

Un rythme à trous

Cela fait deux ans que Marvin et ses collaborateurs travaillent sur cette application de calibrage des trous d’Emmental.

L’équipe a pour clients principaux Emma Tal & Fils et Bonfrometon Company, qui les alimentent régulièrement en nouvelles fonctionnalités.

Depuis plusieurs mois, l’équipe a énormément de mal à gérer les nouvelles demandes de Bonfrometon Company qui nécessitent de gros travaux dans l’application.

Le responsable client dit “oui” à tout, car Bonfrometon est important pour l’entreprise.

Il est primordial de le livrer le plus vite possible. Marvin et ses collègues subissent une forte pression qui les oblige à tout traiter en même temps pour finir le plus vite possible.

Mais rien à faire, l’équipe n’arrive pas à tenir les délais prévus tant les demandes et les priorités changent fréquemment.

Le pire est que ces demandes empiètent sur celles d’Emma Tal & Fils, ce qui impose à l’équipe de stopper tout développement pour cette dernière.

Marvin s’inquiète car l’équipe leur avait promis une importante livraison qui se décale de jour en jour.

L’équipe est frustrée de ne pouvoir livrer Emma Tal comme promis. Ce client menace d’aller voir la concurrence s’il ne dispose pas des fonctionnalités attendues dans les plus brefs délais.

Malgré les partages d’information réguliers, la pression monte. Impossible de savoir par quoi commencer et comment prendre le problème à bras le corps. L’équipe s’épuise et le client s’énerve. Ce n’est plus possible, il faut trouver un moyen de mieux gérer le travail à faire. Pour prendre de la hauteur, l’équipe décide de s’adresser à Jaffar Breton, le meilleur coach flux de la région.

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 :

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.

Kanban est une méthode pour une gestion du changement évolutionnaire permettant au processus d’évoluer en se basant sur les boucles de feedback, l’apprentissage rapide et l’amélioration continue (Kaizen).

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 :

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 :

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] :

WSJF = (valeur pour l’utilisateur + Criticité liée au temps + Réduction de risques et ouverture d’opportunités Value) / Effort relatif de réalisation

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 :

Effort pour l’équipe et les managers

Temps nécessaire pour mener des expérimentations sur le flux de production.

Sur un mois, cela peut se répartir :

  • en l’équivalent de deux jours pour les managers et l’équipe : temps nécessaire pour la mini-formation, les ateliers expérientiels et les réunions de synchronisation ;
  • en une demi-journée hebdomadaire de définition, suivi et analyse des expérimentations ;
  • en 1h par semaine de disponibilité du sponsor pour suivre et discuter les apprentissages de l’équipe.

Charge pour le coach

  • Initialisation de l’initiative, atelier de recensement des insatisfactions sur les thèmes liés au flux.
  • deux mini-trainings de 2 x 0,5j
  • 2 mois d’accompagnement
  • 3 mois d’assistance à la demande et de supervision
  • 4h sur deux mois pour des réunions et des ateliers à la demande

Synthèse de l’accompagnement

Exemples d’atelier

Bibliographie

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Remplir son agenda à 100% pour être certain de ne pas pouvoir gérer les imprévus
  2. Lorsqu’un nouveau problème se présente, commencer une nouvelle tâche et surtout ignorer le problème qui vient de se poser
  3. Ne pas connaître la capacité réelle de production et penser que de toute façon, plus on pousse de demandes, plus on a de chance d’avoir rapidement des résultats


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

Structure du chapitre

Les questions

Une histoire

Contenu

Exemples d’atelier - Bibliographie - Liens

Les questions

Le management agile est un des deux stabilisateurs de vol de l’Agile Rocket. Sans lui, les risques de dévier hors de sa trajectoire vers la North Star sont importants.

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

Comment peut-on accompagner le management à se transformer ?

Le manager agile est un stabilisateur :

  • d’objectif, il aligne l’équipe sur la vision (la North Star) ;
  • d’énergie, il aligne l’équipe par rapport à elle-même et à l’organisation ;
  • de vol, il soutient la transformation agile en donnant l’exemple.

UNE HISTOIRE...

Johnny s’en va-t-en guerre

Johnny est manager d’une équipe agile auto-organisée qui développe une application pour un client.

L’équipe délivre de la valeur régulièrement pour le client mais elle fait un peu ce qu’elle veut. L’auto-gestion de l’équipe a été décrétée avec la mise en place de l’agilité, du coup Johnny ne sait plus comment interagir avec elle.

Le top-management ne connaît pas l’agilité et lui demande des comptes une fois par mois lors des CODIR projet. Il a besoin de visibilité pour annoncer des dates à certaines parties prenantes mais il en est incapable : il a perdu la visibilité sur l’avancement des travaux. Il essaye bien de demander à l’équipe des dates mais il obtient systématiquement la même réponse : “on peut te dire ce qu’on va livrer dans 2 semaines mais après ça dépend, on ne peut pas s’engager”.

Cela le pousse alors à faire ses propres estimations pour donner des dates mais il n’est pas très à l’aise et se met en danger avec son propre management.

Johnny est responsable de l’équipe et doit justifier systématiquement les retards. Il prend sur lui mais cette pression est de plus en plus difficile à supporter.

Quand il demande à l’équipe de livrer en urgence une fonctionnalité demandée par le top management, l’équipe refuse car elle s’est engagée sur d’autres fonctionnalités avec le client. Elle sait très bien que traiter cette urgence créera un risque sur la prochaine livraison.

Johnny est convaincu des bienfaits de l’auto-organisation et l’équipe a prouvé par le passé qu’elle était performante. Mais il n’a pas le choix, il faut que cette fonctionnalité soit livrée rapidement.

Il reprend sa posture de chef et devient plus directif avec l’équipe en lui demandant d’intégrer ce développement le plus vite possible.

L’équipe ressent de plus en plus cette pression : la motivation est en berne.

Les mêmes problèmes reviennent tout le temps : les environnements de tests ne sont pas performants et l’équipe perd un temps fou à tester le produit.

Cette répétition des problèmes qui ne se règlent pas, désespère l’équipe et de plus en plus à la pause café, les équipiers se disent que le produit ne sortira pas.

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

“Individus et interactions plus que processus et outils”

1ère valeur du Manifeste Agile, 2001

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.

Système

Un système est constitué d’un ensemble d’éléments en interaction dont chacun concourt à l’objectif commun ou finalité du système, ou y est impliqué

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.

"Lorsque le manager augmente l’autonomie qu’il donne à son équipe, il augmente en même temps la capacité de nuisance de son équipe pour le reste de l’entreprise ou pour ses parties prenantes." Damien Thouvenin

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.

"Donner plus de pouvoir à un personnel non préparé,
dans une entreprise dépourvue d’unité d’action,
peut avoir des retombées négatives." Peter Senge

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 :

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.

Discipline : définition

Règles de conduite que l’on s’impose, maîtrise de soi, sens du devoir.

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).

Autonomie - Nous voulons sentir que nous contrôlons notre destinée. Nous voulons croire que nous pouvons influencer les choses que nous faisons, que cela peut faire une différence.

people being able to think and do for themselves 

Maîtrise - Nous voulons sentir que nous maîtrisons ce que nous faisons, que nous sommes respectés pour nos capacités.

people having opportunities to learn and grow, and become highly skilled

Finalité - Nous voulons donner du sens à ce que nous faisons. Cela devrait être pour quelque chose nous dépassant

people to feel their work is meaningful and connected to a greater purpose and vision

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

Construire le contexte pour la motivation intrinsèque

Catalyser l’intelligence collective

Leadership

Bibliographie

Liens

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Manager une équipe et ses interactions comme on manage un individu, sans prendre en compte la complexité et l’incertitude
  2. Ne pas impliquer les managers dans la transformation agile et les considérer comme des vestiges du passé voués à disparaître
  3. Considérer que dans une transformation agile ce sont surtout les autres qui doivent changer

 

Maîtrise personnelle

Structure du chapitre

Les questions

Une histoire

Contenu

Exemples d’atelier - Bibliographie - Liens

Les questions

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 ?

                                                   

Exemples d’insatisfactions rencontrées :

UNE HISTOIRE…

Les aventures de Dindin

Le capitaine Waterzoï a roulé sa bosse sur toutes les planètes que compte la galaxie, mais fut soumis à rude épreuve lors de sa mission la plus difficile.

On lui mit dans les pattes un petit reporter spatial du nom de Dindin, petit bonhomme brun avec une coupe mulet, et son petit proto-teckel du nom de Filou.

La mission de Dindin était de mener de front trois reportages en parallèle : le premier sur la crevette aux pattes d’argent, le second sur les cigarettes mentholées du sultan et le troisième sur les 46 pyramides en verre anti-bris de glace.

La mission patinait, Dindin naviguant d’une mission à une autre au gré des nouvelles qui lui parvenaient. C’en était trop pour le capitaine Waterzoï qui sur-consommait son carburant, sans qu’il voit le bout de la mission de Dindin. “Orchidoclaste!”, “Alburostre!”, “Coprolithe!” le capitaine n’en pouvait plus.

Il décida au plus vite de faire appel au fameux coach intergalactique Jaffar Breton pour aider Dindin à mieux organiser la gestion de sa mission. Faisant preuve d’une clairvoyance extrême, il demanda à se faire accompagner lui-même pour mieux gérer sa collaboration avec Dindin.

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.

La conviction d’un enjeu d’accompagnement “transformationnel”

Bien plus que de mettre en place des actions de changement, des techniques, de la formation, etc. Il s’agit de créer les conditions dans lesquelles les interlocuteurs prennent conscience que le changement qu’ils veulent mettre en place autour d’eux passe par une mutation de leur propre identité, de leur rôle et de leur positionnement, par le changement de leurs représentations, par le changement culturel et la remise en question permanente d’eux-mêmes.

“La chenille devient papillon” en continu et chaque décision comporte une interpellation personnelle.

Extrait de Vincent Lehnardt - “les responsables porteurs de sens”

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 !

“On peut facilement se plaindre d’une situation que l’on construit et dont on profite.” 

J-A Malarewicz

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 :

Déni

“Une météorite ? Quelle météorite ?”

Accusation

“C’est la faute du pilote, il aurait dû l’éviter !”

Justification

“C’est comme ca dans l’espace !”

Culpabilité

“J’aurais dû faire plus attention, je suis vraiment mauvais.”

Obligation

“Bon ok je vais regarder, mais c’est vraiment pas le truc le plus important que j’ai à faire !”

Fuite

“Tiens, pause café ? on en reparle à un autre moment ?”

Responsabilité

“Il est important que cela ne nuise pas à l’atteinte de notre objectif. Je suis prêt à mettre mon énergie pour réparer et, surtout, éviter que ca se reproduise !”

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]

Être responsable versus prendre ses responsabilités

Être responsable, c’est être bon et acceptable aux yeux des autres. C’est recevoir une approbation, se conformer à des attentes. C’est un engagement à être bon et faire la bonne chose (même si vous sentez misérable pour l’accomplir).

Prendre ses responsabilités, c’est avoir la capacité de choisir ses réponses aux situations de la vie. C’est un engagement à s’approprier sa vie, au leadership personnel, à la liberté et à l’épanouissement.

“Vous avez la liberté et le pouvoir de choisir” - Christopher Avery[44]

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.

“Change will not come if we wait for some other person or some other time. We are the ones we've been waiting for. We are the change that we seek.” Barack Obama

Passer de l’individuel au collectif

“Le tout est plus grand que la somme des parties.” Aristote

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.

                                                   

Les principes d’Argyris

Lorsqu’une société se transforme, 90% de cette transformation se situe au niveau des personnes et 10% est du changement de processus et de la réorganisation (je donne ces nombres comme ça)[46]. En définissant le changement interne des personnes, on pourrait utiliser les règles de base d’Argyris pour les conversations :

  • n’engagez pas une conversation pour gagner ;
  • engagez-vous dans une conversation pour apprendre ;
  • n’oubliez pas d’enquêter sur ce que les autres pensent ;
  • ne faites pas que défendre vos visions, comme les managers tendent à faire ;
  • la prise de décision devrait être libre de toute “peinture politique”, d’intérêt personnel.

Extrait de Twenty Years of Organizational Learning and Ethics at Hanover Insurance: Interviews with Bill O’Brien by Barry Sugarman (SOL)

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)

Selon son créateur, Marshall B. Rosenberg, la communication non violente est « le langage et les interactions qui renforcent notre aptitude à donner avec bienveillance et à inspirer aux autres le désir d’en faire autant ».

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.”

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

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

  1. 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.

ORID.001.jpeg

le questionnaire ORID de la conversation structurée

L’écoute active

“Celui qui sait écouter deviendra celui qu’on écoute.” Vizir Ptahhotep

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 :

Lors d’une formation d’équipe, le coach peut inviter les personnes à pratiquer l’écoute active en binôme de la manière suivante :

  • pendant 2 mn, une personne se présente, le partenaire prend des notes,
  • pendant 1 mn, le partenaire questionne, confirme et reformule certains propos,
  • pendant 2 mn, le partenaire partage ce qu’il a retenu des propos de son binôme.

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.

Un exemple de questionnement de feedback :

  • Qu’as-tu aimé de ta prestation pendant cet épisode spatio-temporel ?
  • Si tu devais le refaire, que ferais-tu autrement ?

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

“Until we can manage time, we can manage nothing else.” Peter F. Drucker

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 :

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

Bibliographie

Liens

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Toujours se plaindre de problèmes insolubles et indépendants de notre volonté
  2. Voir la transparence et le feedback comme une opportunité d’exprimer ses jugements et opinions aux autres membres de l’équipe
  3. Vouloir répondre à toutes les sollicitations en même temps sans organisation personnelle

 


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

Structure du chapitre

La question

Une histoire

Contenu

Exemples d’atelier - Bibliographie - Liens

La question

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

Exemples d’insatisfactions rencontrées :

UNE HISTOIRE...

L’entreprise japonaise a la fusée en berne

L’entreprise japonaise d’aéronautique Tavumafuzé se targue de disposer du système de production de moteur à fission nucléaire le plus performant du marché. Capable de produire plus de 400 moteurs par mois, elle a, depuis longtemps démontré ses capacités.

Las, le carnet de commande n’est plus ce qu’il était et l’entreprise consomme la trésorerie constituée dans un passé plus glorieux.

Malgré leur processus de travail ultra-compétitif, la société n’a pas su s’adapter à son marché et l’entreprise est en sursis.

Pour relever la barre, Tavumafuzé a décidé de revoir les étapes en amont de la construction et de questionner sa connaissance du marché. Pour repartir sur de bonnes bases, elle fait appel à Jaffar Breton, coach international en innovation produit.

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 :

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.

Une démarche pour générer de la valeur pour le client et l’entreprise

Chacune de ces étapes peut être re-déclenchée en fonction des résultats et des apprentissages obtenus.

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 :

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 ?

Output

S’apparente à la matière livrée, la matérialisation d’une idée.

Penser Output c’est avoir une pensée auto-centrée, ce que je, nous réalisons.

Ex :

une fonctionnalité, un produit, une page...

Outcome

Impact (comportemental, systémique) généré par un output.

Penser Outcome, c’est avoir une une pensée excentrée.

Je ne pense plus à moi, mais à l’impact de la réalisation sur celui qui va consommer cette réalisation.

Ex :

une fonctionnalité de commande en ligne fait que j’achète des chaussures sur internet

le produit AirBnb fait que je me mets à louer ma maison

la page d’inscription d’un site fait que je m’abonne à un service

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

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.

“Si j’avais demandé aux gens ce qu’ils voulaient,
ils auraient répondu des chevaux plus rapides.”

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.

Gemba Walk

La démarche d’aller chercher l’information au plus près de ceux qui la génèrent a été théorisée par Toyota dans le Toyota Production System.

L’idée du Gemba Walk  (Genchi Genbutsu en japonais) est d’aller “là où ça se passe”. Le but du Gemba tel que décrit par Toyota a vocation à aller chercher les points d’amélioration de la chaîne de valeur. Transposé dans la création de produit, le Gemba permet d’aller chercher les informations utilisateurs au plus près de ces derniers.

Dans son Bootleg Bootcamp[52], l’institute of Design de Stanford propose de nombreuses astuces pour mener des observations et des enquêtes terrain de qualité :

  • Adopter la posture du débutant
  • Tout questionner à travers principalement des questions ouvertes
  • Animer une interview empathique
  • Capturer des histoires et des émotions

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].

Empathie

nom féminin

Capacité de ressentir les émotions de quelqu'un d'autre, d'arriver à se mettre à la place d'autrui. L'empathie cognitive consiste à comprendre les idées d'un autre et l'empathie émotionnelle à partager ses sentiments.

L’internaute

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 :

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 :

Des canevas performants

Business Model Canvas

  1. Poser le business model existant
  2. Etudier les sources d’innovation et les impacts sur l’entreprise

Lean Canvaslean canvas.png

Poser plusieurs hypothèses de solutions répondant à des problèmes à résoudre. Étudier les moyens à mettre en oeuvre pour construire la solution

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

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 :

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.

Ex : l’attente principale d’une entreprise de livraison est d’avoir plus de commandes.

Lors d’une session de brainstorming émerge une idée : “il nous faudrait que nos livreurs soient géolocalisables !”.

Étudier ensuite l’impact sur l’outcome (suivre son livreur, améliorer son parcours pour livrer plus rapidement, mieux répartir les livreurs dans l’espace géographique…).

Puis voir en quoi cet outcome permettra à l’entreprise de recevoir plus de commandes.

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.

demarche lean.png

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 :

“Stop roadmaps, do maps with roads” Gojko Adzic

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 est une stratégie qui aligne le développement des services et produits avec les besoins actuels d’un segment restreint de clients dans le but de maximiser leur valeur financière à long terme dans l’entreprise. Dr. Peter Fader

La culture produit c’est :

Exemples d’ateliers

Comprendre l’utilisateur

Définir la vision

Business Model

Brainstorming

Processus

Bibliographie

Liens

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Savoir ce dont a besoin l’utilisateur sans jamais lui avoir demandé
  2. Ne jamais montrer un produit non fini, de peur de faire fuir les utilisateurs
  3. Penser le produit uniquement d’un point de vue utilisateur, sans jamais étudier la valeur et les impacts pour l’entreprise


Excellence de l'ingénierie

Structure du chapitre

La question

Une histoire

Contenu

Bibliographie - Liens

La question

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

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

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 ?

UNE HISTOIRE...

Des recettes viriles introuvables

Ludinette et Casserolin font partie de l’équipe de développement de E-LCuizine (prononcer il Cuisine), l’application mobile de recettes pour homme.

L’équipe de développement d’E-LCuizine travaille en Scrum et la capacité de livraison des fonctionnalités est excellente, 3 845 points par itération de deux semaines pour 5 développeurs.

Malgré ces bons chiffres, des problèmes persistent. La mise en production approche et le nombre d’anomalies ne cesse de grandir, l’équipe doit gérer des bugs remontés dans la phase de recette et vieux de plusieurs mois.

Exemple de cas d’usage défectueux : il semble qu’après avoir corrigé un bug dans l’administration de l’application, un autre problème est apparu : lorsque leur persona “Mâle Alpha” souhaite cuisiner un plat avec entrecôte, patates et sauce barbecue, rien ne remonte, alors qu’il est évident que cela devrait afficher la top recette d’E-LCuizine. Le souci est que cette anomalie concerne la base même de toutes les fonctionnalités. Comment se fait-il qu’ils n’aient pas détecté ça plus tôt ?

Pourtant, dans son processus, l’équipe a intégré une phase de tests unitaires infaillible pour chaque item. Chaque cas est vérifié par son développeur qui passe dans tous les recoins de la fonctionnalité.

En cherchant sur les internets, Ludinette et Casserolin s’intéressent aux techniques de sécurisation des développements, des tests automatisés, de l’intégration continue. Devant le chantier qui s’annonce, l’équipe va avoir besoin d’aide. Elle appelle Jaffar Breton, coach technique renommé…

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.

“Testing is not the point.
The point is about responsibility.” Kent Beck

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é.

“If you're having trouble succeeding, fail.” Kent Beck

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

“There is nothing so useless as doing efficiently that

which should not be done at all.” Peter Drucker

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

“BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

Dan North

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

“Si construire la release fait mal, il faut le faire plus souvent.”

Kent Beck

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

« How long would it take your organization to deploy a change that involves just one single line of code? » Mary Poppendieck

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.

 devops.jpeg

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

TTR.png

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

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/

Dan Leffingwell proposes eight principles for the development and maintenance of enterprise-class architectures in the lean and agile enterprise:

1. The team that code the system also design the system

2. Build the simplest architecture that can possibly work

3. When in doubt, code it or model it out

4. They build it, they test it

5. The bigger the system, the longer the runway

6. System architecture is a role collaboration

7. There is no monopoly on innovation

8. Implement architectural flow

Source: “Agile Software Requirements”, Dean Leffingwell, Addison-Wesley, 489 pages, IBSN 978-0-321-63584-6

Bibliographie

Liens

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. intégrer une phase de test/intégration de plusieurs semaines avant chaque livraison
  2. Ne pas automatiser les tâches répétitives que je maîtrise
  3. Se satisfaire de produire un code de qualité et optimisé et chercher le coupable s’il ne fonctionne pas en production

La culture agile :
propulseur vers la réussite

Structure du chapitre

Les questions

Une histoire

Nécessité d'une transformation

Que changer ? Par où commencer ?

Les niveaux logiques

Le courage du choix - le choix du courage

Comment commencer ?

Comment poursuivre ?

Les questions

Que changer et par où commencer ?

Est-il suffisant d’adopter un jeu de bonnes pratiques ?

UNE HISTOIRE...

Des toutous pas tout doux

Tony Rlipimpon est CEO de l’entreprise “Chi..ouah ! ouah !”, qui fabrique des boîtes de conserves canines révolutionnaires, dopées aux hormones d’hyènes d’Afrique subsaharienne.

Cela transforme temporairement n’importe quel mignon petit toutou poilu en féroce molosse à poil ras, ce qui ne va pas sans plaire à ces vieilles dames soucieuses de leur sécurité lorsqu’elles vont acheter le pain.

Pendant 5 ans, l’entreprise a connu un succès fulgurant, mais malheureusement, elle a dû récemment faire face à une série d’articles assassins de la part de la presse.

Cette dernière prétexte que le produit serait dangereux pour la santé des petits roquets, ce qui semble tout à fait improbable vu que les hormones utilisées sont issues de hyènes 100% bio.

Pour autant, Tony se rend compte que cette campagne calomnieuse a eu un impact non négligeable sur ses équipes, qui depuis ont des mines bien déconfites.

Il décide donc de mettre en place un nouveau processus visant à augmenter le fun sur le lieu de travail.

Ce processus définit que :

  • lorsqu’on arrive à son poste de travail, on enlève ses chaussures, et on fait la danse des clébards (une variation de celle des canards),
  • chaque employé devra se trouver un nom de toutou, et n’appeler ses collègues qu’avec leur nom de baptême canin (le CEO étant l’exception) ,
  • tout le monde doit changer sa sonnerie de téléphone pour qu’elle joue la chanson “who let the dog out”,
  • tout l’espace de travail sera filmé sous l’oeil attentif de 47 caméras qui live-streameront cette ambiance de travail super fun sur les internets.

Mais après 2 semaines d’application de ce process, Tony constate que le moral des employés n’est toujours pas au beau fixe, et pire, que le taux d’absentéisme a augmenté.

Il décide alors de parler avec Ragnarette, une de ses plus fidèles employées, pour mieux comprendre ce qui se passe.

Il ressort de cette discussion que :

  • les employés ne sont pas à l’aise avec le fait d’être observés par les internautes,
  • ils se mettent beaucoup d’échardes dans les pieds en dansant le matin,
  • quand un téléphone sonne, tout le monde se sent concerné,
  • il est le seul à continuer à se faire appeler par son prénom.

Tony Rlipimpon est complètement abasourdi par ce qu’il vient d’entendre (son plan était pourtant génial !).

Mais passé la surprise, il réalise qu’il a besoin d’aide. Il décide de faire appel à un coach spécialisé en changement culturel, qui à défaut d’être épagneul, est breton : Jaffar Breton.

Nécessité d’une transformation

It is not the strongest or the most intelligent who will survive but those who can best manage change. Charles Darwin

Quelques raisons de frissonner :

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 ?

Alistair Cockburn : "Agile is about behaviors"

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.

Index computation.png

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

Les niveaux logiques

Être agile, c’est

être capable de s’adapter

sans stress

en conservant son identité

Damien Thouvenin

Les entreprises qui avaient survécu étaient à la fois très décentralisées
(c’est-à-dire qu’elles avaient des “frontières poreuses” et des “bords excentriques”),
tout en ayant une très forte identité
(c’est-à-dire des valeurs, une culture, des croyances).

Arie de Geus The living company 
(traduit en français sous le titre “La pérennité des entreprises”)

Ceux qui seront capables de résister le mieux dans ce contexte de changement permanent sont ceux qui pourront s'appuyer sur des valeurs essentielles solides et sur un "sens de la vie" sain. Se fixer un but, travailler sur sa vision de l'avenir sont sans doute les seules démarches sensées dans ces périodes turbulentes. Hudson

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

Tout changement demande sacrifice

Pour que quelque chose puisse changer,  
quelque chose doit être payé,

abandonné ou mis de côté.

Nelson Zink - le coût du sacrifice 1995

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 :

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:

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.

We are what we repeatedly do. Excellence, then, is not an act, but a habit. Aristote

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.

Peter Senge : "l’Intelligence Collective se construit dans l’action partagée"[68]

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 :

culture-map-v015-with-questions1.png

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 ?

Believe you can change the world.

Work quickly, keep the tools unlocked, work whenever.

Know when to work alone and when to work together.

Share tools, ideas. Trust your colleagues.

No Politics. No bureaucracy. (These are ridiculous in a garage).

The customer defines a job well done.

Radical ideas are not bad ideas.

Invent different ways of working.

Make a contribution every day.

If it doesn’t contribute, it doesn’t leave the garage.

Believe that together we can do anything.

Invent.

HP Garage Rules

La suite vous appartient…

Bon voyage !

Résultat de recherche d'images3 conseils pour mieux réussir à ne pas décoller :

  1. Croire qu’adopter des bonnes pratiques ayant fait leurs preuves ailleurs suffiront pour transformer l’entreprise
  2. Penser que le changement c’est pour les autres
  3. Négliger ce qui devra être abandonner et le travail de deuil correspondant


Les (étroits) boooksketaires

Booksketaires petit.png

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 IMG_5312 petit.jpg

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.

La démarche présentée est accompagnée pour chaque composant :

  • de la présentation de la question à résoudre,
  • d’une introduction humoristique aux symptômes dysfonctionnels rencontrés,
  • d’une description de la mise en oeuvre de l’amélioration,
  • de références à des ateliers expérientiels,
  • d’un exemple d’estimation de la durée et de l’effort requis pour démarrer,
  • d’une bibliographie pour explorer les concepts introduits.

boosketaires plage.jpg

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

Licence Creative Commons

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.

/


[1] en référence au True North du Lean Management http://www.aleanjourney.com/2014/01/what-do-we-mean-by-true-north.html 

[2] Note : dans les fusées récentes, les systèmes de pilotage et de guidage sont si performants que les stabilisateurs physiques ne sont plus nécessaires. Un objectif pour une agilité de prochaine génération ?

[3] voir la bibliographie

[4] se référer au chapitre sur la culture agile.

[5]  ce qui peut se traduire par “quels avantages pour moi à en faire partie ?”

[6] https://hakanforss.wordpress.com/lego-kanban-cartoon-2/ 

[7]  voir bibliographie en fin de chapitre

[8] https://hakanforss.wordpress.com/resources/ 

[9] http://www.agilex.fr/jeu-au-tableau/ 

[10] voir le paragraphe dédié

[11] voir le paragraphe dédié

[12] en réalité, un management visuel n’est jamais “fini”, il demeure en évolution permanente pour s’adapter au contexte changeant

[13] cf. Module Management Visuel

[14] se reporter au chapitre “North Star”

[15] voir une liste d’ateliers pour cette activité en fin de chapitre

[16] cf. module “Management Visuel”

[17] voir WSJF dans le chapitre sur “le flux”

[18] https://popcornflow.com/ 

[19] http://pt.slideshare.net/agabrillagues/boostez-votre-amlioration-continue-avec-popcorn-flow 

[20] https://hakanforss.wordpress.com/2014/03/10/are-you-too-busy-to-improve/ 

[21] Se reporter au chapitre “Culture Produit” pour plus de détails sur la gestion par la valeur.

[22] Se référer au chapitre “Amélioration continue” pour comprendre comment développer cette compétence collective.

[23] en anglais acronyme WIP : Work In Progress

[24] cf. Stop to start de yannick Quenechd’u : http://fr.slideshare.net/yquenechdu/stop-to-start 

[25] voir le chapitre “Amélioration continue”

[26]  cf. le chapitre “Maîtrise Personnelle”

[27] se référer au chapitre correspondant

[28] voir les références en fin de chapitre

[29] se référer au site http://blackswanfarming.com/cost-of-delay/ pour approfondir ces notions

[30] https://www.amazon.fr/Kanban-Inside-Understand-connect-introduce/dp/0985305193 

[31] voir le chapitre “Maîtrise personnelle” et aussi “Culture agile”

[32] http://stateofagile.versionone.com/

[33]  voir chapitre “Maîtrise personnelle”

[34] voir rubrique Liens

[35] Don Reinertsen parle d’éviter de laisser des “barrières électriques invisibles” qui au final découragent toute initiative

[36] voir Exemples d’atelier

[37] voir plus loin “Leadership et posture”

[38]  voir la théorie des 2 facteurs de motivation de Herzberg

[39] voir “Ecoute” dans le chapitre “Maîtrise personnelle

[40] voir le “management situationnel”, émanant de la théorie du leadership situationnel créé par Paul Hersey et Ken Blanchard

[41] “Change or Die: The Three Keys to Change at Work and in Life” Alan Deutschman

[42] voir chapitre “Maîtrise personnelle”

[43] voir aussi la motivation dans “Management agile”

[44] Extrait de “The Responsibility Process” de Christopher Avery

[45] voir exemples d’ateliers

[46] interview de Bill O’Brien

[47] http://www.ica-international.org/top-facilitation/ 

[48]  voir “Management Agile”

[49]  voir module sur le Flux

[50] Loi de Brooks : « Ajouter des personnes à un projet en retard accroît son retard » projet en retard > rajouter du monde (augmenter le coût) > projet encore plus en retard. Cf. “Mythical Man Month” de Brooks et son fameux « neuf femmes ne font pas un bébé en un mois ! » https://fr.wikipedia.org/wiki/Le_Mythe_du_mois-homme 

[51] dette technique : voir l’article InfoQ https://www.infoq.com/fr/articles/managing-technical-debt 

[52] références en fin de chapitre

[53]  cf. ateliers Empathy Map et Personas en fin de chapitre

[54] Pour aller plus loin et créer des produits de rupture : https://www.blueoceanstrategy.com/ 

[55] https://strategyzer.com/books/business-model-generation 

[56] https://leanstack.com/lean-canvas/ 

[57] https://www.impactmapping.org/fr/ 

[58] http://jpattonassociates.com/jeff-pattons-book-released-user-story-mapping/ 

[59] Cf. chapitre “Culture Produit”

[60] Cf. chapitre “Maîtrise Personnelle”

[61] voir chapitre “Management Visuel”

[62] Richard Foster dans “La destruction créative” [2001]

[63] https://www.torbenrick.eu/blog/change-management/iceberg-that-sinks-organizational-change/ 

[64]  La maîtrise personnelle est une des cinq disciplines évoquées par Peter Senge dans son livre “la 5ème discipline.”

[65] http://www.kolibricoaching.com/self-management/lindex-de-conscience-chacun-son-mode/

[66] depuis nombre d’autres ouvrages sont parus sur le même thème, par exemple “Les entreprises humanistes” de Jacques Lecomte

[67] https://blog.goood.pro/2016/12/07/des-canevas-a-broder3-on-se-leve-tous-pour-lintelligence-collective/#more-6483.

[68] Les Echos : http://goo.gl/KxDd6W 

[69] davegrayinfo.com

[70] http://blog.strategyzer.com/posts/2016/1/11/best-practices-how-to-use-the-culture-map 

[71]B = f(P,E) https://en.wikipedia.org/wiki/Lewin's_equation

[72] https://blog.goood.pro/2016/04/21/des-canevas-a-broder1-culture-map/

[73] Même pas vrai, il a fait super beau…bon, au début !

[74] voir “L’Agile Rocket à travers les âges”

[75] https://blog.goood.pro/2016/12/29/agile-rocket-guide-ready-set-go/