QCM

Le Manifeste Agile privilégie la collaboration avec le client et la livraison progressive pour apprendre rapidement et réduire le risque. Concrètement, négocier une clause contractuelle autorisant des livraisons incrémentales permet d’inspecter des hypothèses utilisateur par des indicateurs métier et des revues régulières, ce qui protège la capacité à délivrer de la valeur validée. Les pièges sont la rigidité contractuelle qui empêche l’apprentissage et les escalades coercitives qui ignorent les contraintes légales ou financières.

L’empirisme Scrum repose sur inspecter, adapter et transparence ; une approche pratique face à une incertitude technique est d’explorer par expérimentation limitée. Time-boxer un spike technique fournit des preuves exploitables, puis l’équipe, avec le Product Owner, adapte le Sprint Backlog selon les résultats. Les erreurs sont d’ignorer l’incertitude, d’annuler sans analyse ou d’imposer une solution sans données issues d’inspections réelles.

Scrum définit clairement les responsabilités : le Product Owner explique la valeur et ordonne le backlog, les Developers décident comment atteindre le Sprint Goal et réévaluent le forecast, et le Scrum Master facilite la discussion et enlève les obstacles. La bonne pratique est donc une négociation collaborative où chaque rôle joue son rôle, pas une imposition hiérarchique ni une décision isolée des développeurs. Le piège est de confondre facilitation et autorité décisionnelle.

Le Product Goal donne une direction à moyen terme, mais Scrum encourage des Sprint Goals qui sont des expériences vérifiables pour progresser vers ce but. Décomposer le Product Goal en hypothèses testables et définir pour chaque sprint un objectif qui livre un incrément vertical permet d’apprendre vite et d’ajuster la feuille de route. Les erreurs consistent à attendre une spécification complète ou à découpler totalement Sprint Goals et Product Goal.

Les événements Scrum existent pour l’inspection et l’adaptation : la Sprint Review doit inclure des parties prenantes externes pour obtenir du feedback sur l’incrément, et la Retrospective est essentielle pour l’amélioration continue de l’équipe. Restaurer ces événements dans leur forme et traiter les actions décidées rétablit alignement métier et performance. Les pièges sont de réduire ces rencontres à des démonstrations internes ou de remplacer l’amélioration par de la documentation.

La transparence est une condition nécessaire à l’inspection et à l’adaptation : exposer immédiatement les métriques qualité pertinentes (tests, incidents, couverture) permet aux parties prenantes d’inspecter la réalité. Organiser une revue conjointe sans blâme et définir un plan d’amélioration priorisé applique correctement le cycle inspecter–adapter. Cacher les défauts fausse les décisions et retarde la résolution des causes racines.

La Definition of Done garantit qu’un incrément est potentiellement livrable et de qualité ; si l’intégration complète est réalisée par une équipe externe, la DoD est incomplète et le risque de non-reproductibilité existe. Étendre la DoD pour inclure intégration et capacité de déploiement, investir en compétences et automatisation CI/CD permet à l’équipe de livrer réellement « terminé ». Les mauvaises réponses consistent à déléguer systématiquement l’intégration ou à rendre la DoD optionnelle.

Prioriser uniquement selon l’urgence des sponsors produit du travail court-termiste et de l’irrégularité de valeur. Une approche durable classe les items par valeur réelle (impact utilisateur, coût du retard) et par coût estimé — par exemple WSJF — puis réduit le backlog via élimination ou expérimentation et met en place des raffinement réguliers axés sur résultats mesurables. Les pièges sont d’augmenter la cadence sans revoir la priorité ou d’externaliser la décision sans contexte technique.

Kanban stabilise le flux en contrôlant le travail en cours : l’introduction de limites WIP explicites par colonne, décidées avec l’équipe, force le pull et évite l’accumulation qui fait varier le cycle time. Mesurer et suivre le cycle time et appliquer des politiques de pull strictes offre l’impact le plus rapide sur la prévisibilité. Les erreurs sont d’ajouter du détail de workflow sans limiter le WIP ou d’imposer des deadlines individuelles qui court-circuitent le système de flux.

Restaurer qualité et prévisibilité exige une stratégie intégrée : time-boxer une période de stabilisation ciblée sur la dette critique, mettre en place intégration continue et pipelines de tests automatisés, et refactorer les modules partagés pour réduire les dépendances inter‑équipes. Remplacer la seule vélocité par des métriques de flux (lead/cycle time, MTTR) et utiliser les rétrospectives pour piloter un plan d’amélioration soutenable renforce la confiance. Les solutions ponctuelles sans automatisation ni plan coordonné ont peu d’effet durable.