1. Developers en 30 secondes
Les Developers sont l'une des trois accountabilities officielles de la Scrum Team, avec le Product Owner et le Scrum Master. Ils sont responsables de créer, à chaque Sprint, un Increment conforme à la Definition of Done.
2. Qu'est-ce qu'un Developer ?
Dans Scrum, un Developer est toute personne qui contribue directement à créer un aspect utilisable de l'Increment à chaque Sprint. Cela inclut évidemment les développeurs logiciels, mais aussi bien d'autres profils.
Pourquoi le terme « Developers » en Scrum Guide 2020
Le Scrum Guide 2020 a remplacé le terme Development Team par Developers. Cette évolution poursuit plusieurs objectifs :
- Casser l'idée d'une « équipe dans l'équipe » (Scrum Team ->Development Team).
- Rappeler que Product Owner et Scrum Master font partie de la Scrum Team.
- Insister sur des accountabilities partagées plutôt que sur des rôles hiérarchiques.
- Élargir la notion : un Developer n'est pas défini par son titre mais par sa contribution à l'Increment.
Quelques exemples de Developers
- Développeurs backend, frontend, mobile, embarqué
- QA / testeurs automatisation
- UX designers, UX researchers
- Data engineers, data scientists
- Spécialistes sécurité, DevOps, SRE
- Rédacteurs techniques
- Experts métier intégrés à l'équipe (actuaires, cliniciens, juristes…)
3. Les trois accountabilities de la Scrum Team
La Scrum Team est composée d'un Product Owner, d'un Scrum Master et de Developers. Les Developers ont une responsabilité unique : produire l'Increment.
4. Les responsabilités des Developers
Les responsabilités officielles portées par les Developers dans le cadre Scrum forment un ensemble cohérent centré sur la livraison d'un Increment de qualité. Elles impliquent aussi de contenir la dette technique à chaque Sprint, sous peine de compromettre la Definition of Done.
Livrer à chaque Sprint un produit utilisable, conforme à la Definition of Done.
Aucune tolérance : un travail non conforme à la DoD n'appartient pas à l'Increment.
Le créer au Sprint Planning, le mettre à jour à tout moment, l'adapter au Daily Scrum.
Réviser l'approche selon la progression vers le Sprint Goal.
Clarifier les items, discuter des compromis, préparer le refinement.
Vérifier chaque jour que le Sprint Goal reste atteignable.
Se remettre en cause en Sprint Retrospective et ajuster en continu.
Les Developers sont un collectif : la qualité et les engagements sont partagés.
5. L'auto-management (self-managing)
En 2020, le Scrum Guide a introduit un changement subtil mais majeur : les Developers ne sont plus seulement self-organizing, ils sont self-managing.
| Dimension | Self-organizing (avant 2020) | Self-managing (depuis 2020) |
|---|---|---|
| Qui fait quoi | Décidé par l'équipe | Décidé par l'équipe |
| Comment le faire | Décidé par l'équipe | Décidé par l'équipe |
| Quand le faire | Cadré par le management | Décidé par l'équipe dans le Sprint |
| Périmètre du travail à faire | Fixé par le management | Négocié avec le Product Owner |
| Portée du contrôle | Exécution du plan | Exécution + planification + adaptation |
Pourquoi ce changement
Scrum Guide 2020 a voulu insister sur une équipe véritablement autonome, capable de décider non seulement comment travailler, mais aussi quoi planifier dans le Sprint et quand le faire. Ce changement de vocabulaire rapproche Scrum d'un cadre de management moderne fondé sur la confiance.
6. Le Sprint Backlog appartient aux Developers
Le Sprint Backlog est l'artefact possédé exclusivement par les Developers. Ils le créent au Sprint Planning, l'adaptent au Daily Scrum et le mettent à jour à tout moment du Sprint.
- Créer : les Developers sélectionnent les PBI qu'ils s'engagent à livrer.
- Décomposer : ils traduisent chaque PBI en un plan de travail.
- Adapter : chaque jour, ils actualisent le plan selon la progression.
- Posséder : personne d'autre — ni PO, ni Scrum Master, ni management — ne peut le modifier.
7. Le flux d'un Sprint côté Developers
Voici comment le travail des Developers s'articule autour des événements du Sprint, depuis le Sprint Planning jusqu'à la livraison de l'Increment.
8. Developers et Product Owner
Developers et Product Owner sont complémentaires : le PO définit quoi livrer et pourquoi, les Developers décident comment et livrent l'Increment.
| Dimension | Product Owner | Developers |
|---|---|---|
| Vision | Porte la vision produit | Comprennent la vision, y contribuent |
| Priorisation | Ordonne le Product Backlog | Fournissent estimations et impact technique |
| Valeur | Maximise la valeur livrée | Livrent un Increment qui matérialise la valeur |
| Planification | Fixe le Sprint Goal avec l'équipe | Sélectionnent les PBI et créent le plan |
| Livraison | Décide quand l'Increment est mis en production | Rendent chaque Increment livrable |
| Backlog | Possède le Product Backlog | Possèdent le Sprint Backlog |
| Décisions | Décisions produit et priorisation | Décisions techniques et organisation du travail |
9. Developers et Scrum Master
Le Scrum Master ne pilote pas les Developers : il les aide à devenir toujours plus autonomes et efficaces.
| Dimension | Scrum Master | Developers |
|---|---|---|
| Responsabilités | Efficacité de la Scrum Team | Création de l'Increment |
| Leadership | Servant leader du framework | Leadership technique et opérationnel |
| Facilitation | Facilite les événements Scrum | Participent activement aux événements |
| Coaching | Coache l'équipe et l'organisation | S'auto-coachent et progressent en continu |
| Création de valeur | Indirecte, via un environnement sain | Directe, via un Increment livrable |
| Décisions techniques | N'en prend aucune | En prennent l'intégralité |
10. Developers vs Development Team
Le passage de Development Team à Developers n'est pas cosmétique : il modifie la façon de penser l'équipe.
| Aspect | Development Team (2017 et avant) | Developers (2020) |
|---|---|---|
| Structure implicite | Sous-équipe dans la Scrum Team | Membres directs de la Scrum Team |
| Vision | Cellule d'exécution | Accountability partagée |
| Frontière avec PO/SM | Séparation nette | Une seule équipe cohésive |
| Taille recommandée | 3 à 9 personnes | Comptés dans la Scrum Team de 10 ou moins |
| Focus | Livrer le Sprint Backlog | Créer un Increment de valeur |
11. Developers et Stakeholders
Oui, les Developers peuvent — et doivent — échanger avec les Stakeholders. Rien dans Scrum ne l'interdit ; au contraire, la transparence et l'apprentissage empirique en dépendent.
Dans quels contextes
- Clarifier un besoin métier lors du refinement.
- Valider une hypothèse d'usage pendant le Sprint.
- Recueillir un feedback qualitatif lors de la Sprint Review.
- Explorer un compromis technique/fonctionnel avec un expert.
Bonnes pratiques
- Le Product Owner reste au courant des échanges structurants.
- Aucune décision d'ordonnancement du Product Backlog n'est prise sans le PO.
- Les échanges nourrissent la transparence, pas les silos.
12. Bon Developer vs mauvais Developer Scrum
- Contribue à l'Increment à chaque Sprint.
- Respecte scrupuleusement la Definition of Done.
- Collabore quotidiennement avec le reste de l'équipe.
- Rend visible ce qu'il fait et ce qu'il bloque.
- Aide ses coéquipiers à atteindre le Sprint Goal.
- Participe activement au refinement et aux estimations.
- Cherche à améliorer le processus en Retrospective.
- Se forme en continu, techniquement et sur le domaine.
- Travaille en silo, uniquement sur « ses » tickets.
- Ignore la Definition of Done sous prétexte de deadline.
- Attend qu'on lui attribue son travail au Daily.
- Refuse de discuter les besoins avec le PO ou les Stakeholders.
- Cache les blocages ou les livre le dernier jour du Sprint.
- Considère le Sprint Backlog comme la propriété du chef de projet.
- Ne participe pas aux estimations, laisse « les seniors décider ».
- Refuse d'apprendre en dehors de sa spécialité initiale.
13. 8 erreurs fréquentes (et pièges PSM I)
Ces erreurs figurent parmi les plus courantes en entreprise et parmi les distracteurs les plus fréquents du PSM I.
Le mot désigne toute personne qui contribue directement à créer l'Increment : QA, UX, data, SRE, rédacteur, expert métier.
Le Scrum Master ne pilote pas le travail. Ce sont les Developers qui décident, ensemble, comment atteindre le Sprint Goal.
Le Product Owner ordonne le Product Backlog. Le Sprint Backlog appartient exclusivement aux Developers.
Scrum privilégie des équipes cross-functionnelles. Les spécialisations existent, mais l'équipe couvre toutes les compétences nécessaires.
Rien ne l'interdit. C'est même encouragé pour maximiser la transparence et la vitesse d'apprentissage.
Ils sont responsables de l'Increment complet : tests, doc, déploiement, conformité à la Definition of Done.
Les Developers se tiennent mutuellement responsables. Le collectif prime sur les affectations individuelles.
Les Developers sont les seuls à estimer la taille des Product Backlog Items — personne ne peut le faire à leur place.
14. 8 exemples industriels : qui sont vraiment les Developers ?
Dans la vraie vie, une équipe de Developers ne se résume presque jamais à « des développeurs logiciels ». Ces huit cas concrets illustrent la diversité des profils qui contribuent à l'Increment.
🎬 Contexte — Nouvelle app mobile pour un service de virement instantané.
👥 Developers — 3 développeurs mobile, 1 backend, 1 QA automatisé, 1 UX designer intégré.
🎯 Point clé — Tous contribuent à l'Increment : le UX participe aux revues, le QA écrit les tests.
🎬 Contexte — Refonte du moteur de tarification multi-produits.
👥 Developers — 2 développeurs backend, 1 actuaire, 1 data engineer, 1 architecte.
🎯 Point clé — L'actuaire est un Developer à part entière : sans lui, pas d'Increment tarifaire.
🎬 Contexte — Portail patient pour la prise de rendez-vous en ligne.
👥 Developers — 2 développeurs fullstack, 1 spécialiste sécurité HDS, 1 designer, 1 chef de projet clinique.
🎯 Point clé — Le spécialiste sécurité fait partie de l'équipe : la conformité est un critère de DoD.
🎬 Contexte — Module de reporting analytique.
👥 Developers — 4 développeurs, 1 data engineer, 1 SRE.
🎯 Point clé — Le SRE code les alertes et l'observabilité. Il est un Developer.
🎬 Contexte — Nouvelle offre de stockage objet géo-répliqué.
👥 Developers — 3 ingénieurs plateforme, 2 SRE, 1 architecte, 1 rédacteur technique.
🎯 Point clé — Le rédacteur produit la documentation livrable — un composant obligatoire de l'Increment.
🎬 Contexte — Firmware pour un capteur IoT industriel.
👥 Developers — 2 firmware, 1 électronicien, 1 backend cloud, 1 testeur terrain.
🎯 Point clé — Le testeur terrain valide chaque Increment sur site — c'est un Developer.
🎬 Contexte — Nouvelle interface de gestion de forfaits.
👥 Developers — 3 fullstack, 1 designer, 1 QA, 1 spécialiste facturation.
🎯 Point clé — Le spécialiste facturation modélise les règles : sans lui, l'Increment est incorrect.
🎬 Contexte — Refonte du tunnel de commande sur mobile.
👥 Developers — 3 frontend, 2 backend, 1 UX researcher, 1 spécialiste paiement.
🎯 Point clé — L'UX researcher intègre les tests utilisateurs au Sprint : Developer à part entière.
15. Checklist : notre équipe est-elle une vraie équipe de Developers Scrum ?
Passez chaque case en revue. Un « non » est un sujet à traiter en Sprint Retrospective.
- ☐Notre équipe gère elle-même son Sprint Backlog
- ☐Personne (Scrum Master, manager, PO) ne distribue les tâches
- ☐Nous collaborons chaque jour, pas uniquement au Daily Scrum
- ☐Nous produisons un Increment utilisable à chaque Sprint
- ☐Nous respectons la Definition of Done sans exception
- ☐Nous améliorons continuellement notre façon de travailler
- ☐Nous communiquons directement avec le Product Owner
- ☐Nous inspectons nos progrès vers le Sprint Goal chaque jour
- ☐Nous participons collectivement au refinement et aux estimations
- ☐Nous nous tenons mutuellement responsables des engagements
16. 7 questions PSM I corrigées sur les Developers
Ces sept questions couvrent les formulations les plus fréquentes du PSM I sur le rôle, l'ownership du Sprint Backlog, l'auto-management et la collaboration.
17. FAQ Premium sur les Developers
20 questions/réponses de référence pour lever tous les doutes avant l'examen PSM I. La FAQ complète est également disponible au bas de cette page, avec un balisage FAQPage exploité par Google.
18. Conclusion
Les Developers sont la force qui matérialise, à chaque Sprint, la valeur imaginée par le Product Owner et rendue possible par le Scrum Master. En Scrum, ils ne sont ni de simples exécutants ni un sous-groupe de la Scrum Team : ils sont l'un des trois piliers, au même titre que le PO et le SM. Bien comprendre leur rôle — auto-management, propriété du Sprint Backlog, engagement sur la Definition of Done — est indispensable pour réussir le PSM I et faire vivre Scrum en équipe.