QCM

Le Manifeste Agile privilégie la collaboration réelle avec les utilisateurs plutôt que la seule conformité contractuelle ; cela signifie ajuster le travail selon le feedback pour maximiser la valeur. Organiser des ateliers réguliers entre utilisateurs, Product Owner et sponsor permet d'inspecter la valeur perçue et de prioriser le backlog en conséquence. Le piège est de confondre engagement contractuel et valeur utilisateur : livrer strictement ce qui est écrit sans validation peut produire un produit inutile.

L'empirisme Scrum repose sur transparence, inspection et adaptation : face à une incertitude technique, l'équipe doit rendre l'état visible, informer le PO et réajuster le Sprint Backlog si l'objectif du Sprint l'exige. Les Developers adaptent le plan de travail, le PO arbitre les priorités et le SM facilite la décision; cela protège la prévisibilité en centrant les choix sur le Sprint Goal. Le risque est de rester figé par souci de prévisibilité ou d'interrompre précipitamment le Sprint sans inspection.

Le Guide Scrum répartit clairement les responsabilités : le Product Owner décide des priorités, les Developers déterminent comment atteindre le travail et le Scrum Master facilite la collaboration. Lorsque des changements radicaux apparaissent, le SM organise la discussion, le PO évalue l'impact sur la valeur et l'objectif, et les Developers estiment l'effort et proposent un plan d'adaptation. Les erreurs fréquentes sont les décisions unilatérales, l'inertie du SM ou l'annulation hâtive du Sprint.

Product Goal et Sprint Goal sont complémentaires : le Product Goal donne une direction stratégique tandis que le Sprint Goal est un engagement tactique mesurable pour un Sprint qui rapproche l'équipe du Product Goal. Chaque Sprint choisit des éléments du Product Backlog contribuant à cette progression, assurant cohérence et focus. Le piège est de confondre les deux ou d'omettre des Sprint Goals clairs, ce qui affaiblit l'alignement et la capacité d'inspection.

Les événements Scrum sont time-boxés parce qu'ils supportent la transparence et l'inspection : la Sprint Review permet d'inspecter l'Increment avec les parties prenantes, la Retrospective permet d'adapter le processus. Supprimer ou abrèger ces événements fragilise la qualité et l'alignement métier ; il faut donc les rétablir et utiliser la rétrospective pour identifier actions correctives. Le piège est de considérer ces cérémonies comme options non essentielles au lieu d'en faire des mécanismes d'amélioration continue.

La transparence est fondamentale : dissimuler des indicateurs qualité empêche une inspection honnête et retarde les améliorations. Rendre visibles les métriques qualité aux parties prenantes, conduire une inspection conjointe et décider d'actions concrètes (tests automatisés, refactoring planifié, intégration continue) sont prioritaires. Le principal piège est de protéger l'image de l'équipe en cachant les problèmes, ce qui amplifie la dette technique et sape la confiance.

La Definition of Done garantit qu'un Increment est potentiellement livrable ; si des tests d'intégration sont effectués hors de l'équipe, l'Increment n'est pas réellement 'done'. Il faut donc ajuster la DoD pour inclure l'intégration et l'automatisation des tests et construire les compétences nécessaires dans l'équipe. Les erreurs courantes sont de traiter la DoD comme optionnelle ou d'externaliser des responsabilités critiques qui empêchent la livraison indépendante.

La priorisation doit être guidée par la valeur utilisateur et le coût du délai plutôt que par l'urgence politique. Mettre en place une matrice de priorisation (valeur utilisateur, coût du retard, dépendances) et expérimenter pour mesurer la valeur réelle avant d'investir permet de réaligner le backlog sur l'impact. Le piège est de céder systématiquement aux pressions sponsorales, ou de privilégier la facilité d'exécution au détriment de la valeur.

Dans Kanban, limiter le travail en cours (WIP) est l'outil le plus direct pour réduire le multitâche, stabiliser le flux et obtenir des temps de cycle prévisibles. Fixer des limites WIP explicites, mesurer le cycle time par type de travail et analyser les goulots permet d'améliorer rapidement la prévisibilité. Les mauvaises réponses consistent à croire que les estimations ou l'augmentation de staff remplaceront l'effet de contrôle du WIP.

Une stratégie holistique combine pratiques techniques et organisationnelles : mettre en place l'intégration continue (builds et tests automatiques), rendre les dépendances visibles et stabilisées (contrats d'API), réserver du temps récurrent pour rembourser la dette technique et utiliser des métriques saines (cycle time, lead time, fréquence de déploiement, taux de défauts). Eviter de s'appuyer uniquement sur la vélocité comparée entre équipes ; externaliser ou suspendre les releases sont des solutions risquées qui retardent l'amélioration continue.