Dans ce troisième article de cette série, nous allons expliquer les raisons pour lesquelles plusieurs membres d’une équipe de développement logiciel Scrum ont souvent une spécialisation.
L’objectif de cette série d’article de blogue est de démystifier l’application du cadre Scrum dans un contexte réel dans lequel, au final, des compromis sur le cadre sont presque toujours nécessaires. Voici la liste des articles de cette série :
- Mise en contexte
- Il y a une hiérarchie dans l’équipe Scrum
- Plusieurs équipiers ont une spécialisation (cet article)
- Les changements, en milieu de Sprint et impactant l’objectif de sprint, sont acceptés
- Les projections ne sont pas basées à 100% sur l’empirisme
- La décision d’annuler un Sprint n’est pas prise seulement par le PO
- Des personnes externes à l’équipe Scrum peuvent influencer la planification de Sprint
Note : Les arguments qui suivent s’appliquent principalement dans le contexte d’une équipe Scrum de développement logiciel.
Les écosystèmes de développement d’aujourd’hui sont composés de plusieurs outils, technologies, infrastructures et langages, chacun offrant plusieurs versions et, très souvent, pouvant être configuré d’une multitude de façons. Pour un développeur ou une développeuse, le simple fait de maintenir ses connaissances à jour sur une pile technologique est un défi et demande un bon investissement de temps. Il est donc très commun pour les développeuses et développeurs logiciels se spécialiser.
« 75 % des développeurs et développeuses backend répondants ne connaissent qu’une seule pile technologique. »
Ici, j’aimerai supporter mon utilisation du qualificatif « très commun ». StackOverflow fait un sondage annuel [1] auprès de ces utilisateurs et utilisatrices. L’analyse [2] des résultats de 2021 démontre que 75 % des développeurs et développeuses backend répondants ne connaissent qu’une seule pile technologique et que seulement 20 % en connaissent deux. Je dois avouer que ces chiffres m’ont personnellement surpris, car je croyais que la majorité des développeurs et développeuses backend connaissait au moins 2 piles technologiques. J’étais clairement loin du compte. Sans prendre de risques, en supposant que la réalité des développeurs et développeuses backend s’applique aux autres profils de développement, on peut déduire que la vaste majorité des développeurs et développeuses ont aussi un profil spécialisé. Ceci s’explique sûrement par le fait qu’une pile technologique moderne est une collection de dizaines des composantes ayant presque toutes plusieurs alternatives et que, une fois mise en place, cette pile sera en constante évolution. La probabilité de travailler 2 fois sur des piles technologiques identiques doit être spectaculairement faible. Une développeuse ou un développeur aujourd’hui doit perpétuellement demeurer en maîtrise de certaines technologies tout en devant en apprendre d’autres.
« On doit donc s’appuyer sur le potentiel de croissance des membres de l’équipe. »
Du point de vue de l’efficacité, le monde idéal serait d’avoir une équipe permanente, dédiée à un produit et/ou à une pile technologique, et ayant un faible taux de roulement. Dans une telle équipe, on atteint au final un équilibre où chaque partie de la pile technologique est couverte par plus d’une ou d’un expert et/ou la majorité des membres de l’équipe a eu le temps de se perfectionner sur plusieurs aspects de cette pile (profil T-Shape*).
*Une personne ayant un profil « T-Shape » est experte sur au moins un sujet tout en étant fonctionnelle sur plusieurs autres.
La vraie problématique survient lorsque nous devons composer une nouvelle équipe. Dans ce cas, la situation idéale serait d’avoir une sélection de candidatures qui, individuellement, couvrirait une grande partie de la pile technologique et qui, ensemble, assurait une double couverture pour tous les éléments de la pile.
Si vous avez déjà composé des équipes, vous savez que ceci est de la pure science-fiction.
Pour atteindre notre objectif de couverture technologique, on doit donc s’appuyer sur le potentiel de croissance des membres de l’équipe. Afin de diminuer le risque dans une telle situation, on cherche dans les candidats et candidates des indices, comme la démonstration d’un grand intérêt à apprendre, le goût d’avoir de nouvelles responsabilités, ou des expériences équivalentes dans une pile similaire.
« Peu importe votre choix, il sera guidé par un compromis. »
Le résultat est donc qu’initialement, et à long terme si les astres ne sont pas alignés, une ou plusieurs expertises ne sont couvertes que par un seul membre qui n’est pas nécessairement une ou un expert. Cette situation, qu’elle soit temporaire ou permanente, demandera un ajustement des attentes, une forme d’amélioration, ou une combinaison des deux. Peu importe votre choix, il sera guidé par un compromis qui variera selon :
- votre tolérance au risque d’avoir une ou un seul expert ou même aucun;
- votre volonté d’investir du temps de l’expert ou l’experte pour former ses pairs, plutôt que de développer;
- le temps que vous estimez économiquement acceptable pour la résolution de cette situation.
« L’équipe idéale a le potentiel de s’adapter à son contexte. »
En conclusion, après avoir tenté de combattre ce dragon, j’ai fini par changer ma définition de l’équipe idéale : l’équipe idéale a le potentiel de s’adapter à son contexte. Je vois l’équipe de la même façon que je vois le produit ou le processus, à savoir un système en constante évolution qui, s’il est bien soutenu, s’améliore de façon itérative.
Adapting Scrum – Return on experience 3/7
In this third article of this series, we’ll explain why many members of a Scrum software development team are often specialized.
The objective of this series is to review the application of the Scrum framework in a practical context where, eventually, compromises are almost always necessary. Here is the list of articles in this series:
- Introduction & context
- There is a hierarchy in the Scrum team
- Many team members are specialized (this article)
- Changes, in the middle of a sprint and impacting the sprint objectives, are accepted
- Projections are not 100% based on empiricism
- The decision to cancel a sprint does not only fall on the PO
- People outside the Scrum team can influence the sprint planning
Note: The following arguments apply mainly in the context of a Scrum team working on software development.
Today’s software development ecosystems consist in multiple tools, technologies, infrastructures, and languages, each offering multiple versions and, very often, configurable in many ways. For a developer, simply staying up to date on a technology stack is a challenge and demands a significant time investment. Consequently, a software developer being specialized is very common.
“75% of the back-end developer respondents know only one technology stack”
I would like to take a moment to support my use of the qualifier “very common”. StackOverflow does an annual survey [1] with its users and an analysis [2] of the 2021 results demonstrates that 75% of the back-end developer respondents know only one technology stack and that only 20% of them know two stacks. I must admit that I was surprised by those numbers as I thought that a majority of back-end developers knew at least two technology stacks… I really missed the target on that one. Without taking much risk, and assuming that this reality for the back-end developers is the same for other developers, we can induce that the vast majority of developers are specialized. This can be explained since a modern technology stack is composed of dozens of components all having many alternatives and, once deployed, the stack is in constant evolution. The probability of working twice on an identical technology stack must be spectacularly small. Today’s developer is continuously mastering some technologies while continuously having to learn new ones.
“We must rely on the growth potential of the team members.”
From an efficiency perspective, the ideal situation would be to have a permanent team, dedicated to a product and/or a technology stack, and with a low turnaround rate. In such a team, we eventually reach an equilibrium where each part of the technology stack is covered by one or more experts and where the majority of the team members have time to perfect themselves on many aspects of the technology stacks (T-Shape*).
*A T-Shape person is an expert on at least one subject while also being functional on many others.
The true problem appears as we try to compose a new team. The ideal situation then would be to have access to a selection of candidates who, individually, cover a large part of the technology stack and who, together, ensure double coverage of all the stack’s elements.
If you ever had to build a new team, you know that this is pure science fiction.
To reach our technology coverage objective, we must rely on the growth potential of the team members. To reduce risk in this kind of situation, we look for clues in the candidates such as a demonstration of great interest in learning, and the will to assume new responsibilities or equivalent experiences.
“No matter the choice you make, it will be guided by a compromise.”
This results initially, and in the longer term if the stars are not aligned, with one or more expertise being covered by only one member. Whether temporary or permanent, this situation will force an adjustment of the expectations, an improvement, or a mix of both. No matter what choice you make, it will be guided by a compromise based on:
- your tolerance for the risk of having one or no expert;
- your willingness of investing the expert’s time in training others rather than developing;
- the time you consider as economically acceptable for the resolution of this situation.
“The ideal team has the potential to adapt to its context.”
In conclusion, after trying to battle this dragon, I eventually changed my definition of the “ideal team”: the ideal team has the potential to adapt to its context. I see the team in the same way I see the product or the process, i.e., a system in constant evolution that, if well supported, improves iteratively.
Références
[1] StackOverflow Annual Survey, Online: https://insights.stackoverflow.com/survey
[2] Cantin P., Web Developer’s Shape, Estimation Drift blog, Online: https://estimationdrift.wordpress.com/2022/12/20/web-developers-shape/
Excellence Agile 