Maîtriser Scrum : La valeur dans la complexité
Un guide complet sur Scrum, les valeurs Agile et les mécanismes de la livraison itérative dans des environnements complexes.
Key Takeaways
- Scrum utilise l'empirisme pour naviguer dans un travail complexe.
- La livraison itérative réduit les risques et permet de recueillir des retours précoces.
- Des tailles de lots plus petites et un WIP faible permettent une livraison plus rapide.
- Les rôles Scrum (PO, SM, Développeurs) simplifient la responsabilité.
- Les équipes pluridisciplinaires réduisent les transferts et les silos.
1. Le Manifeste Agile : Notre étoile polaire
Avant de plonger dans le 'comment' de Scrum, nous devons comprendre le 'pourquoi'. En 2001, dix-sept développeurs de logiciels se sont réunis pour trouver une alternative aux processus lourds et axés sur la documentation qui faisaient échouer les projets. Ils ont créé le Manifeste Agile.Agile n'est pas un ensemble de règles ; c'est un état d'esprit qui valorise les individus et les interactions plus que les processus et les outils.
— Le cœur d'Agile
Les quatre valeurs : 1. Les individus et leurs interactions plus que les processus et les outils. 2. Des logiciels opérationnels plus qu’une documentation exhaustive. 3. La collaboration avec les clients plus que la négociation contractuelle. 4. L’adaptation au changement plus que le suivi d’un plan.
📹 Video Resource: Le Manifeste Agile expliqué
2. Naviguer dans la complexité : La matrice de Stacey
Pourquoi avons-nous besoin de Scrum ? Parce que le monde n'est pas linéaire. Ralph Stacey a développé une matrice pour nous aider à comprendre où nous nous situons. - Simple : La cause et l'effet sont clairs. Utiliser les meilleures pratiques. - Compliqué : La cause et l'effet nécessitent une analyse. Utiliser des experts et un plan. - Complexe : La cause et l'effet ne sont visibles qu'a posteriori. Utiliser Scrum (Tester, Ressentir, Répondre). - Chaotique : Aucune relation entre la cause et l'effet. Agir immédiatement.3. Livrer tôt et souvent : L'approche itérative
Dans les projets traditionnels en « Cascade » (Waterfall), vous planifiez tout, construisez tout et testez tout à la fin. Le risque est de construire la mauvaise chose. Scrum inverse cela à 90 degrés. Nous construisons une petite tranche fonctionnelle du produit à chaque Sprint. Cela réduit l'« écart de risque » entre ce que vous pensez qu'ils veulent et ce dont ils ont réellement besoin.Découper l'éléphant : L'analogie du pont Il existe de nombreuses façons de construire un pont, et de nombreuses façons de « découper un éléphant ». Le pouvoir de livrer tôt et souvent réside dans le fait que les utilisateurs et les parties prenantes reçoivent quelque chose de précieux rapidement. Cela leur permet de fournir des retours qui garantissent que le résultat final résout réellement leur problème. Au lieu d'attendre un pont complet, demandez-vous : quelle est la plus petite chose qui permette à quelqu'un de traverser l'eau aujourd'hui ?
Du Big Bang aux petits lots Livrer souvent signifie diviser un périmètre large et intimidant en plus petits « morceaux » ou lots gérables. Au lieu de travailler pendant des mois ou des années de manière isolée pour tout livrer en une seule fois (l'approche « Big Bang »), nous livrons ces petits paquets aux utilisateurs tôt. Cela garantit que même si nous découvrons que nous sommes sur la mauvaise voie, nous n'y avons passé que quelques semaines, et non quelques années. C'est la magie des petits lots.
4. Les rythmes de Scrum : Les réunions (événements)
Scrum ne consiste pas à multiplier les réunions, mais à organiser les *bonnes* réunions pour permettre l'empirisme : transparence, inspection et adaptation.- Le Sprint : Un conteneur pour tous les autres événements (généralement 1 à 4 semaines). C’est le rythme cardiaque de l'équipe. - Le Sprint Planning (Planification du Sprint) : Que pouvons-nous faire ? Comment allons-nous le faire ? L'équipe crée un objectif de Sprint – un résumé de la valeur à livrer. - Le Daily Scrum (Mêlée quotidienne) : 15 minutes pour inspecter la progression vers l'objectif du Sprint et adapter le plan pour les prochaines 24 heures. C'est pour les développeurs, par les développeurs. - La Sprint Review (Revue de Sprint) : Inspecter l'Incrément et adapter le Product Backlog. C'est là que l'équipe, le PO et les parties prenantes collaborent sur ce qu'il faut faire ensuite. - La Sprint Retrospective (Rétrospective de Sprint) : Inspecter le déroulement du dernier Sprint (personnes, relations, processus, outils) et planifier des améliorations. Il s'agit de devenir une meilleure équipe.
5. Les trois rôles : Qui fait quoi ?
Scrum ne définit que trois rôles. Cette simplicité est conçue pour réduire la bureaucratie et se concentrer sur la valeur.- Le Product Owner : Responsable de maximiser la valeur du produit. Ils gèrent le Product Backlog et décident des priorités. - Le Scrum Master : Le facilitateur et coach. Ils aident l'équipe et l'organisation à comprendre Scrum et éliminent les obstacles qui entravent la progression. - Les Développeurs : Les personnes qui créent l'incrément « Fini » (Done). Ils sont auto-organisés et décident *comment* transformer le backlog en logiciel opérationnel.
📹 Video Resource: La gestion de produit Agile en quelques mots
6. Briser les silos : Le pouvoir des équipes pluridisciplinaires
Les organisations traditionnelles sont souvent organisées par fonction (par exemple, un « département de test » ou un « département de conception »). Cela crée un effet de silo, où l'information et la responsabilité sont piégées au sein des départements.- Le gaspillage lié aux transferts : Dans les organisations fonctionnelles, le travail passe d'un silo à l'autre par des « transferts » (handoffs). Chaque transfert est une source de gaspillage : le travail attend dans des files d'attente, le contexte est perdu, et le syndrome du « c'est pas mon boulot » s'installe. - Équipes fonctionnelles vs équipes pluridisciplinaires : Les équipes fonctionnelles se concentrent sur une seule spécialité. Les équipes pluridisciplinaires (cross-functional) possèdent toutes les compétences nécessaires pour créer un incrément « Fini » — conception, codage, test et déploiement — au sein du même groupe. - Équipes de fonctionnalités (Feature Teams) : Dans Scrum, nous visons des « équipes de fonctionnalités » capables de livrer une valeur client de bout en bout, plutôt que des « équipes de composants » qui ne travaillent que sur une couche technique. Cela réduit considérablement les délais et accroît l'appropriation.
En savoir plus sur la dynamique d'équipe : - [L'effet de silo et comment le briser](https://fr.wikipedia.org/wiki/Silo_de_donn%C3%A9es) - [Pourquoi les équipes pluridisciplinaires sont essentielles à l'Agilité](https://fr.wikipedia.org/wiki/%C3%89quipe_pluridisciplinaire) - [La différence entre les équipes de composants et les équipes de fonctionnalités](https://en.wikipedia.org/wiki/Cross-functional_team#In_software_development)
7. Focus et coût du changement de contexte
Un élément clé de Scrum est le « Focus ». En limitant l'équipe à un seul objectif de Sprint à la fois, nous évitons le piège du « multitâche ». Lorsque vous passez d'une tâche à l'autre, votre cerveau paie un « coût de commutation », perdant souvent jusqu'à 40 % de son temps productif.📹 Video Resource: Le coût du changement de contexte
8. Gestion de l'encours (WIP), des petits lots et du flux
Scrum repose sur les principes du Lean Manufacturing, où la gestion de l'encours (Work In Progress - WIP) et de la taille des lots est la clé de l'efficacité. Le WIP désigne toute tâche commencée mais pas encore « Finie ». Lorsque le WIP est élevé, tout ralentit.- Le piège du multitâche : Lorsqu'une équipe a trop d'éléments en cours, elle souffre de changements de contexte constants. Cela ne donne pas seulement l'impression d'être très occupé ; cela ralentit fondamentalement l'ensemble du système. Des recherches montrent que le changement de contexte peut drainer jusqu'à 40 % du temps productif d'une personne. Dans Scrum, nous évitons cela en nous concentrant sur un seul objectif de Sprint. - La loi de Little : La mathématique du flux : Ce principe mathématique stipule que *Temps de cycle = WIP / Débit*. Cela signifie que si vous voulez livrer plus vite (réduire le temps de cycle), vous pouvez soit augmenter votre vitesse (ce qui est souvent difficile et provoque l'épuisement), soit simplement diminuer la quantité de travail que vous faites en même temps (ce qui est facile et très efficace). En limitant le WIP, vous réduisez automatiquement le temps nécessaire pour qu'un élément traverse votre système. - Le pouvoir de la livraison incrémentale : Les gros lots de travail sont risqués. Ils masquent les problèmes de qualité, retardent les retours et créent des cycles de livraison « tout ou rien ». La livraison incrémentale consiste à livrer régulièrement des morceaux de travail utilisables et précieux. Les petites tailles de lots permettent des retours plus rapides, moins de gaspillage et une livraison de valeur plus prévisible.
La taille de lot optimale pour le travail d'information est généralement beaucoup plus petite que vous ne le pensez.
— Donald Reinertsen
Approfondir le Lean et le Flux : - [Comprendre l'impact de l'encours (WIP) sur la vitesse de livraison](https://fr.wikipedia.org/wiki/Work_in_process) - [Comment la loi de Little régit la prévisibilité de vos Sprints](https://fr.wikipedia.org/wiki/Loi_de_Little) - [L'économie de la petite taille des lots dans le développement de produits](https://en.wikipedia.org/wiki/Economic_batch_quantity)