Après de nombreux commentaires sur un des articles, je me suis dit qu’il serait intéressant de voir ce qu’est l’équipe de développement en scrum. Sa définition n’est pas si simple et peut amener à plusieurs interprétations possibles.
Pour cela, nous allons partir directement du scrum guide. Certaines interprétations peuvent être revue et d’autres pourront vous paraitre un peu poussées. Il ne faudra pas hésiter à amener d’autres interprétations si vous en avez en commentaire qui viendront alimenter cet article.
*Je vais utiliser des termes simples qui évolueront au cours de l’article volontairement. Ne soyez pas choqué avant de lire l’article dans sa globalité !
Vous pouvez regarder la vidéo de La Minute Agile qui parle justement de l’équipe de développement :
L’équipe scrum
Avant de partir sur le sujet de l’équipe de développement, voyons comment est défini une équipe scrum
Une équipe Scrum comprend un Product Owner, une équipe de développement (Development Team) et un Scrum Master. Les équipes Scrum (Scrum Teams) sont auto-organisées et pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur
Scrum Guide
travail, au lieu d’être dirigées par des personnes externes à l’équipe. Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre d’autres personnes n’appartenant pas à l’équipe.
Le scrum guide définit une équipe scrum en 3 parties différentes (le terme partie évoluera au cours de l’article) :
- product owner
- équipe de développement
- scrum master
Cette équipe doit être capable d’avancer sur le projet en toute autonomie. Cette notion est souvent claire pour tout le monde bien qu’elle soit peu respectée dans les faits.
Mais cette notion aura forcément des répercutions sur l’interprétation que nous devrons avoir sur l’équipe de développement.
product owner et scrum master
Sans aller dans les détails car ce n’est pas le sujet de cet article, il est important de voir quelques petits points définis pour ces deux parties.
product owner
Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement. La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus.
Scrum Guide
Je vais m’arrêter sur un terme précis très important qui peut guider l’interprétation à avoir :
« ce rôle » -> on parle ici d’un rôle et non d’une personne. Donc, nous allons voir les définitions possibles du terme « rôle ».
Voici les définitions que nous trouvons sur l’internaute (j’ai omis les définitions qui n’ont rien à voir avec l’analyse actuelle) :
A priori un rôle concerne une personne en particulier. Mais n’oublions pas que nous sommes sur une définition simple d’un dictionnaire.
Certains se demanderont alors si il n’est pas possible de jouer un rôle à plusieurs… Mais le Scrum Guide est clair sur ce fait dans la description du product owner : « Le Product Owner est une personne, et non un comité. »
scrum master
Le Scrum Master est chargé de promouvoir et supporter Scrum tel que défini dans le Guide Scrum. Les Scrum Masters remplissent leur rôle en aidant tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.
Le Scrum Master est un leader-serviteur de l’équipe Scrum. Le Scrum Master assiste les personnes externes à l’équipe Scrum pour identifier quelles sont les interactions bénéfiques avec elle. Le Scrum Master aide tout le monde à adapter leurs interactions avec l’équipe Scrum pour
Scrum Guide
maximiser la valeur créée par cette équipe.
Le scrum master est également défini comme un rôle tenu par une seule personne. Il serait difficile d’interpréter que ce rôle pourrait être tenu par plusieurs personnes.
L’équipe de développement
L’interprétation la plus simple avant même de regarder le scrum guide serait : nous avons 3 rôles différents et les 3 rôles regroupent l’ensemble des compétences pour mettre en place un produit en toute autonomie.
Donc, tous ceux qui ne sont pas product owner ou scrum master qui participent intégralement ou partiellement au produit font parti de l’équipe de développement.
Revenons à présent sur le scrum guide, pour pousser notre analyse car la dernière affirmation semble bien trop simpliste :
L’équipe de développement se compose de professionnels qui fournissent un incrément « Fini » potentiellement publiable (Releasable) à la fin de chaque Sprint. Un incrément « Fini » est requis à la revue de sprint. Seuls les membres de l’équipe de développement créent l’incrément.
Les équipes de développement sont structurées et habilitées par l’organisation à s’organiser et gérer leur propre travail. La synergie résultante optimise l’efficience et l’efficacité globale de l’équipe de développement.
Les équipes de développement ont les caractéristiques suivantes :
Scrum Guide
• Elles sont auto-organisées. Nul (pas même le Scrum Master) n’indique à l’équipe de développement comment transformer les éléments du Backlog Produit en incréments de fonctionnalités potentiellement publiables ;
• Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe, pour créer un incrément produit ;
• Scrum ne reconnaît aucun titre aux membres de l’équipe de développement, indépendamment du travail effectué par une personne ;
• Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement indépendamment des domaines qui doivent être couverts tels que l’exécution de tests, l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle ; et,
• Les membres de l’équipe de développement peuvent détenir individuellement des compétences et des centres d’intérêt spécifiques, mais c’est l’équipe de développement dans son ensemble qui est tenue responsable.
Le scope de cette équipe
Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe, pour créer un incrément produit => Bien que nous parlons souvent des membres techniques quand nous parlons de l’équipe de développement, dans cette partie, le scrum guide est beaucoup plus généraliste sur le scope. Ne supposant aucune compétences spécifiques, nous pouvons supposer qu’il parle de toutes les compétences sans exception.
Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement indépendamment des domaines qui doivent être couverts tels que l’exécution de tests, l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle ; et, => Cette phrase est très intéressante car elle site des domaines autres que les aspects pure technique comme l’analyse fonctionnelle.
Donc on peut considérer que les domaines cités font parti des domaines de compétences de l’équipe de développement :
- exécution des tests
- architecture
- gestion opérationnelle
- analyse fonctionnelle
Cependant, si nous utilisons d’autres rôle que le product owner pour travailler sur la partie fonctionnelle comme le Business Analyst, l’UX, le testeur (sur la partie spécification fonctionnelle des tests), comment pouvons-nous classifier ces personnes ?
Si on s’en réfère à cette partie du scrum guide, ils font partis de l’équipe de développement.
Curieux ? Pas temps que ça.
Le soucis étant que le terme développement est aujourd’hui associé à la programmation ; il y a 20 ans, nous ne parlions pas de développeurs d’ailleurs mais de programmeurs. Je ne connais pas précisément les raisons de ce changement mais c’est un constat que je fais depuis mon début de carrière.
Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe, pour créer un incrément produit ; => cette phrase pourrait d’ailleurs confirmer le côté général donné à cette équipe de développement.
Et nos acteurs en présence partielle ?
Sur ce point, il y aura des divergences d’interprétation. Et c’est intéressant de les analyser.
L’équipe de développement se compose de professionnels qui fournissent un incrément « Fini » potentiellement publiable (Releasable) à la fin de chaque Sprint.
Peut-on considérer que les membres de l’équipe de développement sont présents à chaque sprint ? Si nous mettons une lecture accentuée sur « à la fin de chaque sprint », nous pourrions l’affirmer. Du coup les acteurs présents partiellement (pas à chaque sprint) peuvent être considéré comme « non membre » de cette équipe.
Exemple :
- un juriste qui vient aider sur une spécification fonctionnelle seulement quelques fois.
- une personne venant tester une fonctionnalité pour valider 1 user-story, une fois de temps en temps. Dans les hopitaux, dans l’imagerie, il est parfois obligatoire de faire appel à un spécialiste pour faire un vrai test (seul capable d’utiliser la machine).
Mais d’autres diront, nous pouvons très bien être « membre » de cette équipe sur un petit laps de temps ; la partie « à la fin de chaque sprint » n’est présente que pour parler de l’incrément de fin de sprint. C’est une autre interprétation tout a fait acceptable.
Mais si nous revenons sur le premier paragraphe que nous avons vu :
Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre d’autres personnes n’appartenant pas à l’équipe.
Cette phrase peut au final être lue de plusieurs façons différentes. « les compétences pour effectuer le travail » peut vouloir dire la réalisation à partir de la demande clairement spécifiée ou dire que l’équipe fait le travail qui lui a été demandée tout en la spécifiant.
Donc ceux qui considèrent notre juriste et notre radiologue (testeur temporaire) comme « membre » de l’équipe de développement et ceux qui considèrent qu’ils ne sont « non membre » de l’équipe de développement, ont potentiellement tous raisons.
Honnêtement, ce n’est pas très grave car le principal est de faire travailler tout le monde dans la meilleure des harmonies possibles.
Mes utilisateurs alors ?
L’utilisateur peut faire parti de cette équipe de développement. Nous allons voir différents cas.
1/ Si mon utilisateur vient par exemple dans l’équipe de développement régulièrement pour écrire les tests fonctionnelles avec les développeurs : il est membre de l’équipe.
2/ Si mon utilisateur vient seulement en review pour voir les incréments finalisés : il est non membre de l »équipe.
3/ Si mon utilisateur vient par exemple dans l’équipe de développement de temps en temps pour écrire les tests fonctionnelles avec les développeurs : il est membre ou non membre de l’équipe (selon les interprétations).
4/ Si mon utilisateur vient dans l’équipe de développement pour aider le Business Analyst à compléter des règles de gestion des user-stories : il est membre de l’équipe.
Comme nous pouvons le voir, ce n’est pas si simple de définir qui est membre ou non membre de l’équipe de développement. Certains pourraient même remettre en question ces résultats avec la phrase ci-dessous où « effectuer » peut être interprété différemment selon les gens :
Si mon utilisateur vient par exemple dans l’équipe de développement de temps en temps pour écrire les tests fonctionnelles avec les développeurs : il est membre ou non membre de l’équipe (selon les interprétations).
Les petites choses qui vont gratter
Bien que certains diront, il ne faut pas faire du « scrum by the book », voici quelques informations intéressantes.
Pas de Business Analyst et d’UX
A priori, tous ceux qui ne sont pas product owner ou scrum master font parti de l’équipe de développement. Mais une phrase du scrum guide peut embarrasser un certain nombre de personnes :
Scrum ne reconnaît aucun titre aux membres de l’équipe de développement, indépendamment du travail effectué par une personne ; => Si nous parlons d’un scrum 100% respecté, personne ne peut avoir le titre de BA ou UX. Chaque membre de l’équipe de développement a le titre de « membre de l’équipe de développement ». Mais nous pouvons avoir des membres avec des compétences spécifiques sans soucis pour aider au développement du produit comme le montre la phrase ci-dessous.
Les membres de l’équipe de développement peuvent détenir individuellement des compétences et des centres d’intérêt spécifiques, mais c’est l’équipe de développement dans son ensemble qui est tenue responsable.
Cette phrase peut interpeller sur le fait que le travail du Business Analyst et de l’UX sont de la responsabilité de toute l’équipe. L’ensemble de l’équipe de développement peut ainsi critiquer (de façon positive) le travail fonctionnel réalisé par ces personnes. Dans le sens inverse, les membres aux compétences non technique peuvent également critiquer le travail des développeurs par exemple.
Interdiction de faire du scrum master intégré
Donc on peut confirmer que le scrum master intégré (dev étant scrum master) est bien une pratique non recommandée par le scrum guide.
Conclusion
Voici les résultats qu’on pourrait noter de cette analyse complète avec les possibles différentes interprétations :
le dev front => « membre »
le dev back => « membre »
testeur à 100% dans l’équipe => « membre »
testeur partiel mais présent à chaque sprint => « membre »
testeur présent de temps en temps => « membre » ou « non-membre »
le juriste => « membre » et « non-membre »
le business analyst => « membre »
l’UX => « membre »
l’utilisateur aidant à l’écriture de test à chaque sprint => « membre »
l’utilisateur aidant à l’écriture de test de temps en temps => « membre » ou « non-membre »
l’utilisateur à la review => « non membre »
Cet article est un peu exagéré mais qui permet de bien définir qui fait parti de l’équipe de développement. Cependant, dans certaines situations, il est possible d’en avoir différentes interprétations.
Cet article pourra d’ailleurs évoluer si certains d’entre vous m’amènent d’autres interprétations.
Ces différentes interprétations possibles sont logiques car le scrum guide est volontairement court. Il faudrait des centaines de pages pour pouvoir limiter au maximum les interprétations.
8 Rétroliens / Pings