🚀 Wardley Map de l'AgilitĂ©: Équipe qui DĂ©marre [VERSION B - SUCCINCTE]

Agile, Cartographie, IA

🎯 Pourquoi cette Carte?

Habituellement, on parle d’agilitĂ© de maniĂšre abstraite:

  • ❌ “Soyez agiles!” (vague)
  • ❌ “Appliquez Scrum” (mĂ©canique)
  • ❌ “Changez la culture” (idĂ©alisme)

Avec une Wardley Map, on voit concrĂštement:

  • ✅ État initial: tayloriste/command-control
  • ✅ État cible: auto-organisation/empirisme
  • ✅ 4 mouvements: ce qui change CONCRÈTEMENT

đŸ—ș État Initial: Équipe Tayloriste

Situation Typique

Taille: 8-12 développeurs
Org: Par spécialité (frontend/backend/infra)
Management: HiĂ©rarchique (Directeur → Leads → Devs)
Processus: Cascade (Spec → Dev → Test → Prod)
ProblÚmes: Lenteur, silos, surprises, décalage client

Carte Wardley (Axe Y puis X)

                    HAUT (VISIBLE CLIENT)
                              │
                 ★ Livraison (tous les 12 mois)
                              │
                 ◆ Tests externes (cachĂ©)
                 ◆ Code dĂ©veloppĂ© (invisible)
                              │
          ─────────────────────────────────
                              │
                 ◆ Specs Ă©crites (planning)
                 ◆ RĂ©unions lancement
                 ◆ Contrats SLA
                              │
                    BAS (INVISIBLE)
                 ♩ HiĂ©rarchie imposĂ©e
                 ♩ ContrĂŽle qualitĂ© (fin cycle)
                 ♩ Reporting d'heures

Position sur X (Gauche-Droite):

GAUCHE (INNOV)    │    CENTRE (PRODUIT)    │    DROITE (COMMOD)

Retours clients       Spécifications          Hiérarchie
(rarement)            Ă©crites                 (standard org)
                      
Auto-org              DĂ©veloppement           ContrĂŽle externe
(impossible)          artisanal               (en fin cycle)
                      
                      Code modulaire          Infrastructure
                      (semi-stable)

ProblĂšmes Visibles

ProblĂšme SymptĂŽme Antipattern (Fresque)
Feedback caché Client voit code 1x/an Pas de voix des utilisateurs
Auto-org impossible Manager impose HOW Hiérarchie + ContrÎle
QA externalisée Tests EN FIN (2 mois) ContrÎle QA externe
Specs figées 200 pages avant de coder Big design up front

✹ État Cible: Équipe Agile

Carte Wardley (MĂȘme logique Y puis X)

                    HAUT (VISIBLE CLIENT)
                              │
         ★ DĂ©mos Sprint (toutes les 2 semaines)
         ★ Feedback utilisateur (CONTINU)
                              │
         ◆ Code livrable (petit incrĂ©ment)
         ◆ Tests automatisĂ©s (continu)
                              │
          ─────────────────────────────────
                              │
         ◆ RĂ©trospective (amĂ©lioration)
         ◆ Daily standup (sync Ă©quipe)
         ◆ Timebox/Sprint (rythme)
                              │
                    BAS (INVISIBLE)
         ◆ Confiance (pas de tracking)
         ◆ Infrastructure cloud

Position sur X (Gauche-Droite):

GAUCHE (INNOV)    │    CENTRE (PRODUIT)    │    DROITE (COMMOD)

★ Feedback           ◆ Sprint Review          ♩ Cloud
  CONTINU            (cadencĂ©)                ♩ Git/Chat
                     
★ Auto-org           ◆ Daily standup          
  Équipe dĂ©cide      ◆ Timebox                
                     
★ Confiance          ◆ Tests auto
  (pas control)      (continu)

🔄 Les 4 Mouvements pour Transitionner

❓ Question 1: Comment Avoir le Feedback du Client?

AVANT (Tayloriste):

DĂ©cembre N: RĂ©union de lancement, 200-page spec
...
DĂ©cembre N+1: Livraison = "J'ai fait la spec"
Client: "C'est pas vraiment ce qu'on voulait"

APRÈS (Agile):

Sprint 1: DĂ©mo + Sprint Review (30 min, client present)
  Client voit LE CODE, pas des slides
  "Oui, c'est bon" ou "Vous changerez ceci"
Sprint 2: Équipe ajuste et dĂ©montre Ă  nouveau

Cycle feedback: 2-3 semaines, pas 12 mois ✅

Changement Clé:

  • PM: “Je dois ĂȘtre prĂ©sent 2x/sem” (vs 1x/an)
  • Dev: “Je pose des questions, j’apprends l’usage rĂ©el”
  • Client: “Je suis impliquĂ© en continu”
  • Manager: “J’Ă©coute pendant les dĂ©mos”

RĂ©sistance courante:

❌ "Le client n'a pas le temps"
   → Une dĂ©mo = Ă©viter 6 mois de rework
   
❌ "Les specs doivent ĂȘtre complĂštes avant"
   → Les specs complùtes sont TOUJOURS obsolùtes

❓ Question 2: Comment Donner Autonomie Ă  l’Équipe?

AVANT (Tayloriste):

Manager: "Vous utiliserez Jira de cette façon précise"
Standup: Chacun rapporte au manager (15 min parade)
RĂ©tro: N'existe pas
Équipe: "On fait ce qu'on nous dit"

APRÈS (Agile):

Équipe dĂ©cide: Format standup, outils, processus
Standup: "On synchro sur ce qui bloque le groupe?"
RĂ©tro: "Qu'est-ce qui a bien marchĂ©? À amĂ©liorer?"
Équipe: "On s'auto-organise pour rĂ©soudre le problĂšme"

Manager présent mais S'ABSTIENT de décider HOW

Changement Clé:

  • Manager: “Je dis QUOI (objectif), pas COMMENT”
  • Dev: “Nous choisissons nos outils, nos standards”
  • RĂ©tro: Équipe propose, vote, expĂ©rimente

Exemple concret - Standup:

AVANT:
  Dev1: "J'ai codé X" (rapport au manager)
  Manager: [15 questions détaillées]
  
APRÈS:
  Équipe: "Quelqu'un est bloquĂ©?"
  Dev2: "Oui, je dois les infos du client"
  Dev1: "Je peux te les passer"
  [3 min, problÚme résolu]

RĂ©sistance courante:

❌ "Ils vont flñner"
   → Équipes autonomes se motivent PLUS (psycho)
   
❌ "Ce sera le chaos"
   → Chaos = pas de visibilitĂ© (voir Question 1 = feedback)

❓ Question 3: Comment Avoir la QualitĂ© Tout de Suite?

AVANT (Tayloriste):

Dev: 6 mois
QA externe: 2 mois (teste Ă  la fin)
Bugs trouvĂ©s: Mois 7-8 → Rework
Cycle total: 9 jours par feature

APRÈS (Agile):

Dev code + teste EN MÊME TEMPS
  - 1h: Unit tests + CI/CD setup
  - 4h: DĂ©veloppement
  - 1h: Test Ă©criture
  - Commit → CI/CD teste AUTO
  
Si rouge: Dev voit immédiatement
Si vert: Feature RÉELLEMENT fini

Cycle total: 5h par feature (et sĂ»r!) ✅

Changement Clé:

  • Dev: “Je teste pendant, pas aprĂšs” (c’est MON JOB)
  • QA: De “police de bug” → “architecte de fiabilitĂ©”
    • Guide la stratĂ©gie de test
    • Aide Ă©quipe avec techniques
    • Design les tests critiques
  • Manager: “Si tests Ă©chouent, on ne dĂ©ploie pas”

Exemple - Conversation QA/Dev APRÈS:

QA: "Et si l'utilisateur fait X en offline?"
Dev: "Bon point, je dois tester ça"
QA: "Voici comment automatiser ce test"
Dev: "J'ajoute au CI/CD"

RĂ©sistance courante:

❌ "Les tests ralentissent"
   → Tests parallùles = moins de debug (plus rapide)
   
❌ "On n'a pas le temps de tout tester"
   → Tester les 20% critiques suffit

❓ Question 4: Comment Accepter les Changements de Spec?

AVANT (Tayloriste):

Sept: PM Ă©crit 200 pages seul
  (assume connaĂźtre le futur)
Dec: Dev code la spec
  (jamais remise en question)
Déc+1: Client voit le résultat
  "C'est pas vraiment ça"
Jan-Fev: Rework

50% des specs initial ne sont jamais utilisées

APRÈS (Agile):

Sprint N-1: PM + Dev + Client (30 min) clarifient ENSEMBLE
  
  PM: "On veut un rapport pour piloter les décisions"
  Client: "Oui, voir le mois comparé au précédent"
  Dev: "Et si on ajoute un graphique?"
  Client: "Excellente idée!"
  
  Acceptance Criteria (partagés):
    ✓ Tableau du mois courant
    ✓ Graphique tendance 12 mois
    ✓ Export CSV

Sprint N: Dev code ce qui est VRAIMENT utile

Spec change? ATTENDU (basĂ© sur apprentissage) ✅

Changement Clé:

  • PM: “Je pose le problĂšme, on l’explore ensemble” (vs “Je dĂ©finis la solution seul”)
  • Dev: “Je challenge: pourquoi? Et si…?” (vs “Je dis oui et je code”)
  • Client: “Si on dĂ©couvre mieux, on pivot” (vs “Je signe le contrat et j’attends”)

Format change:

AVANT: "Specs Doc" (200 pages)
APRÈS: "User Story" (3 lignes)
  Titre: "Rapport mensuel"
  Description: "Permettre au gestionnaire de voir les tendances"
  Acceptance Criteria:
    - Données du mois courant
    - Graph tendance 12 mois
    - Export CSV

RĂ©sistance courante:

❌ "Sans plan, on va partir en freestyle"
   → Feedback continu (Q1) = direction claire
   
❌ "Les clients changent trop d'avis"
   → Ils changent parce que les specs Ă©taient mauvaises
   → Être transparent: "Apprendre = changer d'avis"

📊 RĂ©capitulatif: 4 Mouvements sur la Carte

Mouvement AVANT APRÈS Changement
1. Feedback Invisible (1x/an) Visible (2x/sem) HAUT + GAUCHE
2. Auto-org Imposée (control) Libre (équipe décide) GAUCHE
3. QA Externe (fin) Intégrée (continu) SEMI + CENTRE
4. Specs FigĂ©es (200p) Émergentes (3 lignes) GAUCHE

🔗 Pourquoi Cet Ordre?

Ces mouvements se renforcent:

Mouvement 1 (Feedback)
  ↓ Donne confiance Ă  l'Ă©quipe
  
Mouvement 2 (Auto-org)
  ↓ L'Ă©quipe peut expĂ©rimenter
  
Mouvement 3 (QA intégrée)
  ↓ Confiance pour pivoter vite
  
Mouvement 4 (Specs Ă©mergentes)
  ↓ Retour à Mouvement 1 = feedback continu
  
→ Boucle vertueuse!

📅 ImplĂ©mentation: 8 Semaines

Semaine 1-2: Mouvement 1 (Feedback)

- DĂ©mo + Sprint Review toutes les 2 semaines
- Inviter le client CHAQUE sprint
- (Pas besoin de perfection, juste voir l'avancement)

Semaine 3-4: Mouvement 2 (Auto-org)

- Équipe dĂ©cide format standup, outils, process
- Manager lĂąche prise sur comment
- RĂ©tro hebdo: "Qu'est-ce qu'on change?"

Semaine 5-6: Mouvement 3 (QA)

- Commencer tests automatisés (les 20% critiques)
- CI/CD pipeline simple
- "Done" = tests passent

Semaine 7-8: Mouvement 4 (Specs)

- Format user stories courtes
- Refinement en Ă©quipe (pas PM seul)
- Acceptance criteria partagées

RĂ©sultat aprĂšs 2 mois:

Score Agilité:
  AVANT: ▓░░░░ 1/20 (Tayloriste)
  APRÈS: ▓▓▓▓░ 17/20 (Agile)
  
= 60-75% d'agilité en 2 mois!

✅ Signes de Succùs

Vous saurez que ça marche quand:

  1. Feedback

    • Client assiste rĂ©guliĂšrement aux dĂ©mos
    • Équipe ajuste rapidement aprĂšs feedback
    • Plus de “surprise” 6 mois aprĂšs livraison

  2. Auto-org

    • Équipe propose amĂ©liorations en rĂ©tro
    • Manager n’impose plus la HOW
    • Moins de stress (pas de micro-management)

  3. QA

    • Bugs dĂ©tectĂ©s en HEURES, pas en mois
    • Dev responsable de son code testĂ©
    • Confiance Ă  dĂ©ployer

  4. Specs

    • User stories de 3 lignes, pas 200 pages
    • Changements acceptĂ©s (pas “hors scope”)
    • Moins de rework

🔗 Lien Fresque ↔ Wardley

Fresque = QUOI mettre dans la carte

  • Antipatterns: À DROITE (commoditĂ© bloquante)
  • Patterns: À GAUCHE (innovation agile)

Wardley = OÙ et COMMENT transitionner

  • Axe Y: Rendre visible ce qui compte
  • Axe X: DĂ©placer vers l’innovation
  • Mouvements: 4 changements concrets

📝 Conclusion

Cette cartographie montre qu’on peut passer de tayloriste Ă  agile en 2 mois avec 4 mouvements stratĂ©giques simples:

  1. Rendre Visible le feedback client (en continu)
  2. LibĂ©rer l’Ă©quipe (auto-organisation)
  3. Intégrer la qualité (tests continus)
  4. Accepter les changements (specs Ă©mergentes)

Chaque mouvement est concret (pas d’injonction abstraite), et tous se renforcent mutuellement.

Créé: 19 Novembre 2025
Type: Cas pratique - Wardley + Agilité
Statut: ✅ PĂ©dagogie Ă©tape par Ă©tape