🚀 Wardley Map de l'Agilité: Équipe qui Démarre [VERSION A - COMPLÈTE]
3872 mots soit environ 19 minutes de lecture.
🎯 Objectif: Relier Wardley Maps et Agilité
Cet article répond à une question centrale:
Comment cartographier l’évolution d’une équipe qui passe du management traditionnel à l’agilité?
Le Défi Pédagogique
Habituellement, on parle d’agilité de manière abstraite:
- ❌ “Soyez agiles!” (injonction vague)
- ❌ “Appliquez Scrum” (recette mécanique)
- ❌ “Changez de culture” (idéalisme)
Avec les Wardley Maps, on peut montrer concrètement:
- ✅ État initial (tayloriste/command-control)
- ✅ État cible (auto-organisation/empirisme)
- ✅ Chemins de transition (patterns vs antipatterns)
- ✅ Points critiques (dépendances, risques)
📚 Source: Fresque de l’Agilité
Cet article s’appuie sur la Fresque de l’Agilité de agileradical.org:
Structure de la Fresque
ACTEURS (qui?)
├─ Coéquipiers
├─ Sponsor/Manager
└─ Usagers/Clients
PROBLÈMES INITIAUX (quoi?)
├─ Surprise (imprévu fréquent)
├─ Inefficacité (pertes de temps)
├─ Mésusages (mauvais usage)
└─ Souffrance au travail (burn-out)
THÈMES (axes fondamentaux)
├─ Organisation des personnes
├─ Organisation du temps
├─ Question du sens
└─ Attention au résultat
PRINCIPES MODERNES (antipatterns courants)
├─ Division du travail (spécialisation)
├─ Division du temps (planning rigide)
├─ Performance individuelle
└─ Optimisation de la production (vitesse)
PRINCIPES DE L'AGILITÉ (solutions)
├─ Auto-organisation
├─ Boucles orientées utilisateurs
├─ Robustesse de l'équipe
└─ Durabilité des effets
🗺️ Wardley Map: Équipe au Démarrage de l’Agilité
Contexte: Une Équipe Tayloriste Classique
Imaginons une équipe informatique typique d’une grande organisation en 2024:
Taille: 8-12 développeurs
Organisée: Par spécialité (frontend, backend, infra)
Management: Hiérarchique (Directeur tech → Leads → Devs)
Processus: Cascade: Spécification → Développement → Test → Prod
Problèmes: Lenteur, silos, surprises, surcharge, décalage client
Structure Verticale (Axe Y): Flux de Valeur Visible → Invisible
Commençons par comprendre le flux de valeur du point de vue du client:
┌──────────────────────────────────────────────────────────┐
│ WARDLEY MAP: ÉQUIPE TAYLORISTE (État Initial) │
├──────────────────────────────────────────────────────────┤
│
│ HAUT (VISIBLE CLIENT)
│ │
│ ★ Fonctionnalité Livrée (tous les 12 mois)
│ │
│ ◆ Processus de test (caché, 2 mois)
│ ◆ Code développé (backend, invisible)
│ │
│ ────────────────────────────────── DÉMARCATION
│ │
│ ◆ Spécifications écrites (planning)
│ ◆ Réunions de lancement
│ ◆ Contrats, SLA
│ │
│ BAS (INVISIBLE - ORGANISATION INTERNE)
│
│ ♦ Hiérarchie (directeur → leads → devs)
│ ♦ Contrôle qualité externe
│ ♦ Reporting horaire (timetracking)
│ ♦ Infrastructure classique (serveurs)
│
└──────────────────────────────────────────────────────────┘
Stratégie Horizontale (Axe X): Innovation vs Commodité
Maintenant, appliquons l’évolution des composants:
GAUCHE (INNOVATION) CENTRE (PRODUIT) DROITE (COMMODITÉ)
★ Agilité ◆ Processus ♦ Infrastructure
(Nouveau, de test (Commodité)
propriétaire) (Établi)
♦ Hiérarchie
★ Retours ◆ Spécifications (Commodité
utilisateur écrites - standard
(Innovation (Produit standard) dans org)
= clé!)
◆ Développement ♦ Contrôle
★ Auto-org (Artisanal) qualité
(Nouveau,
risqué) ◆ Code modulaire ♦ Timetracking
(Produit)
◆ Livraison ♦ Runbook standard
(Processus)
Carte 2D Complète: Y puis X
GAUCHE (INNOV) CENTRE (PRODUIT) DROITE (COMMOD)
│ │ │
HAUT│ ★ Retours ◆ Spec écrite ♦ Infrastructure
VISI│ client (visible) (commodité)
BLE │ (Innovation!)
│
│
SEMI│ ★ Auto-org ◆ Code modulaire ♦ Contrôle QA
VISI│ Équipe (semi-visible) (commodité)
BLE │ (Nouveau)
│
│
INVI│ ◆ Retros (rare!) ◆ Processus ♦ Hiérarchie
SIBLE│ testing ♦ Timetracking
│
🔴 Problèmes Identifiés par la Carte
1. Retours Utilisateur en Position Dangereuse
Observation:
- Position: Visible (HAUT) + Innovant (GAUCHE)
- Mais: Invisible en pratique (réunion annuelle)
Diagnostic:
Le client DEVRAIT voir les retours constants.
Mais le processus les cache → Décalage croissant
Antipattern (Fresque): “Pas de voix des utilisateurs”
2. Auto-organisation Impossible
Observation:
- Auto-org positionnée GAUCHE + SEMI-INVISIBLE
- Mais: Hiérarchie DROITE + INVISIBLE impose control
Conflit Y→X:
Équipe veut auto-s'organiser (gauche = innovation)
Mais structure hiérarchique (droite = commodité) l'en empêche
= Frustration, stagnation
Antipatterns (Fresque):
- “Contrôle”
- “Hiérarchie”
- “Pression hiérarchique”
3. Qualité Externalisée
Observation:
- Contrôle QA positionné DROITE + INVISIBLE
- Signifie: “On teste après”, pas en continu
Problème:
Tests en fin de cycle (commodité, externe)
Au lieu de tests continus (innovation, intégration)
= Bugs tardifs, rework massif
Antipattern (Fresque):
- “Contrôle qualité externe”
- “Big bang” (test le tout ensemble)
4. Spécifications Figées
Observation:
- Specs écrites positionnées DROITE + SEMI-INVISIBLE
- Signifie: “Plan fixe, pas d’itération”
Antipattern (Fresque):
- “Plan détaillé à l’avance”
- “Big design up front”
- “Méthode séquentielle”
✨ État Cible: Équipe Agile
Nouveau Flux de Valeur (Axe Y Réinventé)
WARDLEY MAP: ÉQUIPE AGILE (État Cible)
HAUT (VISIBLE CLIENT)
│
★ Sprint Review (client voit tous les 2 semaines)
★ Feedback utilisateur (CONTINU, VISIB!L)
│
★ Démonstration (ce qu'on a livré)
★ Code livré (petit incrément)
│
────────────────────────────────── DÉMARCATION
│
◆ Rétrospective (amélioration continue)
◆ Daily standup (coordination équipe)
◆ Timebox/Sprint (rythme cadencé)
│
BAS (INVISIBLE)
◆ Tests automatisés (continu)
◆ Intégration continue (continu)
◆ Infrastructure moderne (cloud)
Nouvelle Stratégie (Axe X Réinventé)
GAUCHE (INNOV) CENTRE (PRODUIT) DROITE (COMMOD)
★ Feedback ◆ Démo ♦ Infrastructure
utilisateur (Sprint review) cloud
(CLIQUE CLIENT!)
◆ Timebox/Sprint ♦ Outil git
★ Auto- (cadence ♦ Outil chat
organisation établie)
★ Confiance ◆ Retro équipe
(plutôt que (méthode)
control!)
◆ Tests auto
(practice établie)
Carte 2D Cible
GAUCHE (INNOV) CENTRE (PRODUIT) DROITE (COMMOD)
│ │ │
HAUT│ ★ Feedback ◆ Sprint Review ♦ Cloud infra
VISI│ CONTINU (cadencé)
BLE │ (Innovation!)
│
│
SEMI│ ★ Auto-org ◆ Daily standup ♦ Git/Chat
VISI│ Auto-décision ◆ Timebox (commodité)
BLE │ (Clique!)
│
│
INVI│ ★ Confiance ◆ Tests auto ♦ Monitoring
SIBLE│ (plutôt que (continu) (external)
│ control)
│
🔄 Transition: De Tayloriste à Agile
Pourquoi ces 4 Mouvements?
L’objectif est de déplacer les composants critiques de la droite (commodité/control) vers la gauche (innovation/autonomie), ET du bas vers le haut (rendre visible ce qui compte).
🎯 Mouvement 1: Rendre Visible le Feedback Utilisateur
Position sur Wardley: BAS-DROITE → HAUT-GAUCHE
Intention Stratégique:
POURQUOI?
- Feedback = le signal le plus important pour piloter le produit
- Actuellement caché/rare → Équipe décide aveuglément
- Agile = empirisme = décisions basées sur retours réels
- Déplacer vers HAUT: le feedback DOIT être visible EN CONTINU
- Déplacer vers GAUCHE: c'est une INNOVATION (pas commodity)
État Tayloriste AVANT
Symptômes:
- 1 réunion de lancement (déc année N)
- 1 réunion de review (déc année N+1)
- Entre temps: Silence radio
- Client connaît pas les développements
- Devs connaissent pas l'usage réel
Responsabilités par acteur:
| Acteur | Responsabilité AVANT |
|---|---|
| Product Manager | Écrit spec 200 pages seul, ne contacite client qu’en fin |
| Manager/Lead | Impose le plan, suit la deadline fixe |
| Développeurs | Appliquent les specs sans questions; livrables = “j’ai codé ce qu’on a demandé” |
| Client/Sponsor | Accepte le plan en déc, attend la livraison en déc+1, découvre les problèmes trop tard |
État Agile APRÈS
Symptômes:
- Démo + Sprint Review TOUTES les 2 semaines (30 min live)
- Client voit LE CODE, pas des slides powerpoint
- Feedback immédiat: "oui c'est bon" ou "en fait on veut ceci"
- Équipe ajuste dans le sprint suivant (2 sem après)
- Cycle de feedback = 2-3 semaines, pas 12 mois
Changements d’Acteurs:
| Acteur | Nouvelle Responsabilité APRÈS | Changement Concret |
|---|---|---|
| Product Manager | Co-crée les items avec l’équipe + client; clarifie AU SPRINT pas avant | “Je dois être présent 2x/sem pour clarifier, pas 1x/an” |
| Manager/Lead | Facilite démos, écoute feedback, protège l’équipe des interruptions | “Je me tais pendant les démos; j’écoute le client” |
| Développeurs | Demandent clarifications en live; montrent les brouillons aux utilisateurs | “Je pose des questions plutôt que d’assumer; j’apprends de vraies usages” |
| Client/Sponsor | Participe activement (30 min/2sem); influence directement les prochaines itérations | “Je suis impliqué en continu, plus d’attente passive” |
Défi du Mouvement
Résistance courante:
❌ "Le client n'a pas le temps venir toutes les 2 semaines"
→ RÉALITÉ: Si on attend 12 mois, on perd 12 mois
→ SOLUTION: 30 min de qualité > 0 min d'inattention
❌ "Les specs doivent être complètes avant de coder"
→ RÉALITÉ: Les specs complètes sont TOUJOURS obsolètes
→ SOLUTION: Spécifications émergentes (voir Mouvement 4)
❌ "On perd du temps en démos"
→ RÉALITÉ: On évite de PERDRE 6 mois en mauvaise direction
→ SOLUTION: Calcul d'effet: 2h demo = éviter 6 mois de rework
🎯 Mouvement 2: Donner Autonomie Réelle à l’Équipe (Auto-Org)
Position sur Wardley: BAS-DROITE (hiérarchie bloquante) → SEMI-VISIBLE-GAUCHE (autonomie)
Intention Stratégique:
POURQUOI?
- L'équipe est la plus proche du PROBLÈME (code, client, livraison)
- Taylorisme = manager décide, équipe exécute (lent, démotivé)
- Agile = équipe décide COMMENT, manager facilite
- Gauche = innovation: chaque équipe adapte sa façon de travailler
- Semi-visible = confiance (pas de tracking/surveillance)
État Tayloriste AVANT
Symptômes:
- Manager dit: "Vous utilisez Jira de cette façon précis"
- Standup = rapport au manager (15 min de parade)
- Rétro n'existe pas (ou c'est un rapport au manager)
- Changement de processus? Décision top-down
- Équipe: "On fait ce qu'on nous dit"
- Stress: Vous avez pas fait comme dit (blame)
Responsabilités par acteur:
| Acteur | Responsabilité AVANT |
|---|---|
| Manager/Lead | Décide comment travailler; impose les outils; inspecte le travail; corrige |
| Développeurs | Suivent les ordres; peu de voix au chapitre; responsables de l’exécution |
| Sponsor | Suit le plan, demande des rapports d’avancement |
État Agile APRÈS
Symptômes:
- Manager crée CONDITIONS pour que l'équipe s'auto-organise
- Équipe décide: standups, rythme, outils, process
- Rétro = "Qu'est-ce qu'on change?" (pas blame, d'amélioration)
- Essais/expérimentations bienvenues
- Équipe: "On s'auto-organise pour résoudre ce problème"
- Confiance: "Vous trouverez la meilleure façon"
Changements d’Acteurs:
| Acteur | Nouvelle Responsabilité APRÈS | Changement Concret |
|---|---|---|
| Manager/Lead | Crée cadre (deadline, objectif); puis s’éloigne; facilite obstacles | “Je dis QUOI (objectif), pas COMMENT; je m’abstiens de micro-management” |
| Développeurs | Décident ensemble du processus; améliorations en retro; s’auto-régulent | “Nous choisissons nos outils, notre standup, nos standards; NOUS amélliorons” |
| Sponsor | Fait confiance à l’équipe; évalue les résultats pas les process | “Je regarde les démos, pas les burn-down charts” |
Changements Opérationnels Concrets
Standup (15 min):
AVANT (Taylorisme):
Chacun rapporte au manager: "J'ai fait X, je fais Y, bloqué par Z"
→ Manager veut tous les détails
→ Blame potentiel si pas productif
→ Séquence: manager pose 15 questions
APRÈS (Agile):
Équipe se demande: "On synchro sur ce qui bloque?"
→ Détails seulement si pertinent pour LE GROUPE
→ Identification collaborative des blocages
→ Manager présent mais n'impose pas l'ordre du jour
→ Équipe peut décider: "Pas de standup aujourd'hui, on code"
Rétro (1h/2 sem):
AVANT:
N'existe pas, ou c'est des 1-1 manager/dev
Peur: "Si je dis un problème, responsable?"
APRÈS:
Format de sécurité: Équipe entière, pas de manager jugeant
"Qu'est-ce qui a bien marché? Quoi d'améliorer?"
Équipe propose, vote, expérimente dans le sprint suivant
Exemple d'amélioration testée:
S1: On bosse 9h-17h rigide (commodité)
Rétro: "On s'interrompt trop"
Décision: On essaie 10h-15h blocs de focus continus
S2: "Ça a marché! On garde"
Nouvelle règle VIENT DE L'ÉQUIPE
Défi du Mouvement
Résistance courante:
❌ "Si on les laisse faire, ils vont flâner"
→ RÉALITÉ: Équipes autonomes se motivent PLUS (psycho)
→ SOLUTION: Clarifier objectif et résultats attendus
❌ "On va perdre la cohérence des processus"
→ RÉALITÉ: Les processus de commodité ne créent pas de valeur
→ SOLUTION: Quelques principes communs (démo, retro, feedback)
Mais HOW c'est équipe
❌ "Ça va devenir le chaos"
→ RÉALITÉ: Chaos = manque de visibilité, pas manque de control
→ SOLUTION: Feedback continu (Mouvement 1) = vous voyez problèmes
Point critique: Quand manager DOIT intervenir
✅ Quand: Équipe bloquée par facteur EXTERNE (process org, politique)
✅ Quand: Objectif stratégique change (client perdu, pivot)
✅ Quand: Valeurs compromises (burnout grave, inconduite)
❌ JAMAIS sur: Comment coder, quel outil, ordre des tâches
🎯 Mouvement 3: Intégrer la Qualité (QA du BAS-DROITE vers SEMI-VISI-CENTRE)
Position sur Wardley: BAS-DROITE (externe, fin cycle) → SEMI-VISIBLE-CENTRE (intégré, continu)
Intention Stratégique:
POURQUOI?
- QA externe = test EN FIN de cycle = bugs découverts trop tard = coûteux
- Intégré = test PENDANT le dev = bugs attrapés tôt = cheap
- Semi-visible = tests auto (pas de "manual QA testing")
- Centre = c'est une pratique devenue fiable/reproducible (produit)
État Tayloriste AVANT
Symptômes:
- Développement: 6 mois
- QA externe (département séparé): 1-2 mois
- Bugs trouvés: mois 7-8 → Rework → Délai
- Cycles de dev/test/rework/test: 3+ itérations
- Équipe QA SURMENÉE (rattraper les bugs tardifs)
- Accusation croisée: "Dev devrait tester" / "QA trop exigeant"
Responsabilités par acteur:
| Acteur | Responsabilité AVANT |
|---|---|
| Développeurs | “Mon job = coder; QA teste après” (pas de tests) |
| QA Team | Teste tout à la fin; crée rapports de bugs; reçoit code “terminé” |
| Manager | Gère les délais de rework; arbitrage “qualité vs calendrier” |
État Agile APRÈS
Symptômes:
- Développement + Tests = SIMULTANÉ (unit tests + CI/CD)
- Tests automatisés tournent à CHAQUE commit
- Bugs détectés en heures, pas en mois
- QA devient CONSULTANT (design les tests, aide l'équipe)
- "Done" = code LIVRABLE (pas juste compilé)
- Confiance: Si tests passent, on peut livrer
Changements d’Acteurs:
| Acteur | Nouvelle Responsabilité APRÈS | Changement Concret |
|---|---|---|
| Développeurs | Écrivent tests PENDANT le code (TDD/BDD); tester = PART du job | “Je teste mon code en même temps; ‘fait’ = tests passent + code review” |
| QA Team | Guide la stratégie de test; crée/maintient l’infrastructure CI/CD; mentore devs | “Je ne fais plus de testing manual; je design qu’est-ce qu’on teste et pourquoi” |
| Manager | Impose “définition de fini = tests passent”; revoit la culture QA | “Si tests échouent, on ne déploie pas. Pas de débat.” |
Changements Opérationnels Concrets
Avant une Feature:
AVANT (Taylorisme):
Dev reçoit spec, code 5 jours, livre au QA
QA teste 2 jours, trouve 10 bugs
Dev corrige 2 jours, rend à QA
Cycle: 9 jours pour 1 feature
APRÈS (Agile):
Dev: "Acceptes tests? (1h pour unit tests + CI/CD setup)"
Dev code la feature (4h coding + 1h test writing)
Dev push: CI/CD run tests AUTO
Si rouge: Dev voit immédiatement
Si vert: Feature RÉELLEMENT fini
Cycle: 5h pour 1 feature (et sûr!)
Rôle du QA:
AVANT: QA = "Police de la qualité" (oppose les bugs)
→ Relation conflictuelle avec Dev
APRÈS: QA = "Architecte de la fiabilité" (guide)
→ Relation: "Comment on teste ceci?"
→ Exemple conversation:
QA: "Et si l'utilisateur fait X en offline?"
Dev: "Bon point, je dois tester ça"
QA: "Voici la technique pour automatiser ce test"
Dev: "OK, j'ajoute au CI/CD"
Défi du Mouvement
Résistance courante:
❌ "Les tests ralentissent le dev"
→ RÉALITÉ: Tests rapides le dev en long terme (moins de debug)
→ SOLUTION: Tests écrits en MÊME temps (pas après)
❌ "On n'a pas le temps de tout tester"
→ RÉALITÉ: Tester les user-journeys critiques suffit
→ SOLUTION: Commencer par les 20% qui représentent 80% des bugs
❌ "Les tests automatisés, c'est compliqué"
→ RÉALITÉ: Au départ oui, puis devient normal
→ SOLUTION: QA forme l'équipe (Mouvement 2 = auto-org)
🎯 Mouvement 4: Accepter les Spécifications Émergentes
Position sur Wardley: BAS-DROITE (specs figées, commodité) → SEMI-VISIBLE-GAUCHE (specs vives, innovation)
Intention Stratégique:
POURQUOI?
- Specs écrites AVANT = on assume connaître le futur (faux)
- Résultat: 50% des specs initial jamais utilis, 50% mauvais
- Émergentes = specs écrites JUSTE-À-TEMPS (quand on comprend)
- Gauche = innovation: chaque user story adaptée au contexte
- Semi-visible = on documente au besoin, pas à l'excès
État Tayloriste AVANT
Symptômes:
- Septembre: Réunion de lancement, 200-page spec
- Devs reçoivent spec, jamais remis en question
- Décembre: Livraison = ce qui était dans la spec (pas ce qui aide client)
- Client: "C'est pas tout à fait ce qu'on voulait"
- Rework: Janvier-Février
- Cause racine: Spécifications écrites TROP tôt, jamais challenging
Responsabilités par acteur:
| Acteur | Responsabilité AVANT |
|---|---|
| Product Manager | Écrit spec (seul, dans le bureau); c’est “parole d’évangile” |
| Développeurs | Lisent spec, posent pas de questions existentielles; c’est le contrat |
| Client/Sponsor | Accepte spec en déc, attend la livraison |
État Agile APRÈS
Symptômes:
- Au lieu de: 200-page spec en sept
- On fait: User story courte (3 lignes) décrivant l'intention
- Avant chaque sprint: PM + Dev + Client clarifient ENSEMBLE
- Acceptance criteria = définition partagée du "fini"
- Spec change = ATTENDU (et bienvenu si fondé sur feedback)
- Exemple story:
"En tant que gestionnaire, je veux voir les rapports du mois
pour piloter les décisions"
(Au lieu de: 12 pages de mockups, wireframes, edge cases)
Changements d’Acteurs:
| Acteur | Nouvelle Responsabilité APRÈS | Changement Concret |
|---|---|---|
| Product Manager | Crée USER STORIES (courtes, intention); clarifie EN SPRINT avec équipe | “Je ne définis pas la solution; je pose le problème et on l’explore ensemble” |
| Développeurs | CHALLENGENT l’intention: “Pourquoi? Et si…?” ; co-créent l’acceptation | “Je pose des questions; j’apporte des idées techniques dès le départ” |
| Client/Sponsor | Reste flexible; accepte changements basés sur apprentissage | “Si on découvre une meilleure approche, on pivot; pas d’ego.” |
Changements Opérationnels Concrets
Specification Refinement:
AVANT (Taylorisme, sept):
Product Manager (seul):
"Spec rapport: titre, colonnes, filtre date, export PDF"
[5 heures pour écrire]
Devs reçoivent (déc):
"Aha, elle demande 'filtre date' mais on a besoin de filtre par client"
[Rework, pas bien compris]
APRÈS (Agile, sprint N-1):
Product Manager + Dev + Client (30 min):
PM: "On a besoin d'un rapport pour piloter les décisions"
Client: "Oui, je vois le mois et je compare au précédent"
Dev: "Et si on fait un graphique? Tendance?"
Client: "Excellente idée!"
Acceptance Criteria:
✓ Afficher le mois courant en tableau
✓ Graphique tendance sur 12 derniers mois
✓ Export CSV
Dev code ce qui est CLAIRement utile, pas spéculations
Changement d’Affichage:
AVANT: "Specs Doc"
APRÈS: "User Stories" (Jira)
Titre: "Rapport mensuel"
Description: "Permettre au gestionnaire de voir les tendances"
Acceptance Criteria:
- Afficher données du mois courant
- Graph tendance 12 mois
- Export CSV
(Pas 12 pages de mockups, interfaces, edge cases obscurs)
Défi du Mouvement
Résistance courante:
❌ "Si on n'a pas de plan détaillé, on va partir en freestyle"
→ RÉALITÉ: Feedback continu (Mouvement 1) = direction claire
→ SOLUTION: User story = "intention", pas liberté totale
❌ "Les clients changent trop d'avis"
→ RÉALITÉ: Ils change d'avis PARCE QUE les specs était mauvaises
→ SOLUTION: Être transparent: "Apprendre = changer d'avis"
❌ "Ça va prendre plus de temps (réunions)"
→ RÉALITÉ: Une 30-min clarification = eviter 3 semaines rework
→ SOLUTION: Calcul ROI: mieux vaut changer direction tôt
📋 Synthèse: 4 Mouvements = 1 Trajectoire
| Mouvement | État AVANT | État APRÈS | Changement Clé | Acteurs Impactés |
|---|---|---|---|---|
| 1. Feedback | Invisible, annuel | Visible, continu | PM+Dev+Client réunis 2x/sem | PM, Dev, Client, Manager |
| 2. Auto-Org | Imposée d’en haut | Décidée par l’équipe | Manager s’abstient, équipe décide | Manager, Dev, Lead |
| 3. QA | Externe, fin cycle | Intégrée, continu | Dev responsable de tests | Dev, QA team, Manager |
| 4. Specs | Figées, détaillées | Émergentes, courtes | PM challenge, Dev propose, Client accepte | PM, Dev, Client |
🔗 Interdépendances: Pourquoi l’Ordre Importe
Ces mouvements se renforcent mutuellement:
Mouvement 1 (Feedback continu)
↓
→ Donne à l'équipe CONFIANCE qu'elle fait le bon truc
→ Permet Mouvement 2 (Auto-org) = "On peut décider, on a feedback"
Mouvement 2 (Auto-org)
↓
→ Équipe peut EXPÉRIMENTER amélioration continue
→ Permet Mouvement 3 (QA intégrée) = "On teste comme on veut"
Mouvement 3 (QA intégrée)
↓
→ Donne CONFIANCE que le code est livrable rapidement
→ Permet Mouvement 4 (Specs émergentes) = "On peut pivoter sans peur"
Mouvement 4 (Specs émergentes)
↓
→ Donne FLEXIBILITÉ à l'équipe d'explorer
→ Nourrit Mouvement 1 (Feedback) = "On ajuste basé sur apprenants"
Chemin de Transition Séquencé
Recommandation: Ordre de déploiement
SEMAINE 1-2: Mouvement 1 (Feedback)
└─ Créer démo + sprint review cadencées
└─ Inviter client CHAQUE sprint
└─ Équipe voit feedback immédiatement
└─ ROI: Voir direction tout de suite
SEMAINE 3-4: Mouvement 2 (Auto-Org)
└─ Équipe décide HOW (standup format, tools, process)
└─ Manager lâche prise sur micro-management
└─ Rétro hebdo: qu'est-ce qu'on améliore?
└─ ROI: Équipe motivée, amélioration continue
SEMAINE 5-6: Mouvement 3 (QA)
└─ Commencer tests automatisés (les 20% critiques)
└─ CI/CD pipeline basique
└─ "Done" = tests passent
└─ ROI: Moins de bugs tard, plus de confiance
SEMAINE 7-8: Mouvement 4 (Specs)
└─ Changer format: user stories courtes
└─ Refinement en équipe (pas spec seul en PM)
└─ Acceptance criteria partagées
└─ ROI: Moins de rework, plus d'alignement
RÉSULTAT APRÈS 2 MOIS:
✅ Feedback continu → Équipe claire
✅ Auto-org → Équipe motivée
✅ QA intégrée → Équipe confiante
✅ Specs émergentes → Équipe agile
SCORE: Passe de 1/20 à 12-15/20 (60-75% agile)
📊 Bilan de la Transition par Axes
Axe Y (Visibilité): Repenser le Flux
| Élément | Avant (Tayloriste) | Après (Agile) |
|---|---|---|
| Feedback client | BAS (1x/an) | HAUT (1x/2 sem) |
| Qualité | BAS-DROITE (externe) | SEMI (intégré) |
| Décisions équipe | BAS (imposées) | SEMI (autonomes) |
| Code livré | BAS-INVISIBLE | HAUT-VISIBLE |
Axe X (Évolution): Déplacer l’Innovation
| Élément | Avant | Après | Mouvement |
|---|---|---|---|
| Feedback | Commodité | Innovation | GAUCHE ← |
| Auto-org | Bloquée | Clique | GAUCHE ← |
| QA | Commodity externe | Intégré | GAUCHE ← |
| Specs | Commodity figée | Émergence | GAUCHE ← |
Score d’Agilité
ÉTAT INITIAL (Tayloriste):
Feedback Client: ▓░░░░ 1/5 (annuel)
Auto-Organisation: ░░░░░ 0/5 (zéro)
Qualité Intégrée: ░░░░░ 0/5 (externe)
Empirisme: ░░░░░ 0/5 (plan figé)
──────────────────────────
Score Agilité: ▓░░░░ 1/20
ÉTAT CIBLE (Agile):
Feedback Client: ▓▓▓▓▓ 5/5 (continu)
Auto-Organisation: ▓▓▓▓░ 4/5 (équipe décide)
Qualité Intégrée: ▓▓▓▓░ 4/5 (tests auto)
Empirisme: ▓▓▓▓░ 4/5 (itératif)
──────────────────────────
Score Agilité: ▓▓▓▓░ 17/20
🚨 Antipatterns à Éviter
Selon la Fresque de l’Agilité, attention aux pièges:
| Antipattern (Fresque) | Manifestation | Comment l’Éviter |
|---|---|---|
| Contrôle | Manager dit quoi faire → Pas d’autonomie | Créer trust, retros |
| Hiérarchie | Décisions top-down → Lenteur | Empouvoirement équipe |
| Méthode séquentielle | Spec → Dev → Test → Prod | Itérations courtes |
| Planification de projet | Plan fixe à 6 mois | Backlog vivant |
| Timetracking | Rapport d’heures → Micro-management | Engagement sur objectifs |
| Spécialisation | Dev frontend/backend silos | Équipes cross-fonctionnelles |
| Formation standardisée | “Suivez la formation Scrum” | Équipe apprend ensemble |
| Vitesse à tout prix | “Plus d’itérations = mieux” | Rythme soutenable |
| Big design up front | Specs de 50 pages → Obsolète | Conception émergente |
| Contrôle QA externe | QA teste à la fin | Tests continus, CI/CD |
✅ Patterns à Adopter
| Pattern (Fresque) | Définition | Où on la Cartographie |
|---|---|---|
| Voix des utilisateurs | Feedback continu du client | HAUT + GAUCHE |
| Démarche empirique | Learn by doing, iterate | CENTRE-GAUCHE |
| Livraison fréquente | Demo souvent (1-2 sem) | HAUT + CENTRE |
| Auto-organisation | Équipe décide comment | SEMI-VISI + GAUCHE |
| Confiance | Plutôt que control | Partout, invisible |
| Convivialité | Bien-être équipe | SEMI-VISI |
| Méliorisme | Amélioration continue | Retros |
| Pluridisciplinarité | Cross-fonctionnel | SEMI-VISI |
| Qualité | Tests intégrés | SEMI-VISI + CENTRE |
| Rythme soutenable | Pas de burn-out | Timebox raisonnables |
🎓 Utilité de cette Cartographie
1. Diagnostic: “Où sommes-nous?”
La Wardley Map révèle:
- ✅ Feedback client vraiment visible? (Ou caché annuellement?)
- ✅ Auto-org réelle ou injonction? (Bloquée par hiérarchie?)
- ✅ Qualité intégrée ou externalisée?
2. Intention: “Vers où aller?”
La carte cible montre l’état agile:
- Feedback HAUT-GAUCHE (innovation + visible)
- Auto-org GAUCHE (empouvoirement)
- QA SEMI-VISIBLE (intégré, continu)
3. Chemin: “Comment transitionner?”
Les mouvements stratégiques répondent:
- Étape 1: Rendre visible ce qui compte (feedback)
- Étape 2: Donner autonomie réelle
- Étape 3: Intégrer QA au cycle
- Étape 4: Accepter l’émergence
4. Communication: “Parler stratégie, pas process”
Au lieu de:
“Appliquez Scrum, faites des standups”
On peut dire:
“Voyez cette carte? Votre feedback est INVISIBLE (bas), devrait être VISIBLE (haut). Votre auto-org est BLOQUÉE (hiérarchie), doit être LIBRE (empouvoirement). Qualité est EXTERNE (fin), doit être INTÉGRÉE (continu). Voici comment transitionner…”
🔗 Lien Fresque ↔ Wardley
Fresque = Composants
La Fresque fournit quoi mettre dans la Wardley Map:
- Acteurs: Coéquipiers, Sponsor, Usagers
- Problèmes: Surprise, Inefficacité, Mésusage, Souffrance
- Principes: Auto-org, Feedback, Robustesse, Durabilité
- Antipatterns: À DROITE (commodité bloquante)
- Patterns: À GAUCHE (innovation agile)
Wardley = Positionnement Stratégique
Wardley Maps positionnent ces composants:
- Où sont-ils? (Axe Y = visibilité)
- Quel état? (Axe X = maturité)
- Comment transitionner? (Mouvements)
📝 Conclusion
Cette première cartographie montre la pertinence de combiner:
✅ Wardley Maps = Framework stratégique spatial ✅ Fresque de l’Agilité = Langage commun des problèmes/solutions agiles ✅ Équipe au démarrage = Cas d’usage concret réaliste
Prochaines étapes explorées:
- Cas 2: Équipe mid-transition (partiellement agile)
- Cas 3: Équipe mature (agile établie)
- Cas 4: Organisation en transformation globale
Créé: 19 Novembre 2025
Type: Article pilote - Cas pratique Wardley + Agilité
Statut: ✅ Test de pertinence réussi
Prochaines itérations: Feedback? Raffinements?
