Dans le deuxième article de cette série, nous allons expliquer pourquoi une hiérarchie a été mise en place dans les équipes Scrum, pourquoi cette pratique s’applique dans plusieurs contextes et, pour finir, comment elle peut s’aligner avec le cadre Scrum.
L’objectif de cette série de blogues est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires. Voici la liste des articles de cette série et les liens des articles déjà publiés :
- Mise en contexte.
- Il y a une hiérarchie dans l’équipe Scrum (cet article).
- Plusieurs équipiers ont une spécialisation.
- 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.
Métier, organisation et leadership
Il est très rare que tous les membres d’une équipe agile soient des experts, vétérans ou séniors. La plupart du temps, on retrouve un mélange de juniors, intermédiaires et séniors qui, ensemble, cumulent « toutes les compétences nécessaires »[1] à la réalisation des items du carnet de produit. Mais qu’est-ce que ça veut vraiment dire « toutes les compétences nécessaires » pour une équipe agile? Selon mon expérience[2], les compétences nécessaires sont composées de deux parties : l’autonomie métier et l’autonomie organisationnelle.
Autonomie métier : pour assurer un niveau minimal d’expertise métier lors de la composition d’une équipe agile, on doit composer avec trois éléments : le niveau individuel d’expérience des membres composant l’équipe, le nombre de membres dans l’équipe et le coût total de l’équipe. Ici, le premier piège serait de tomber dans l’un des deux extrêmes : tous les équipiers maîtrisent le bout-en-bout métier (explosion des coûts) ou les équipiers ne maîtrisent que des fragments du bout-en-bout métier (explosion du risque).
La solution la plus économique, et sécuritaire, est d’avoir dans l’équipe un minimum de membres maîtrisant le bout-en-bout. Cela permet d’assurer une vue d’ensemble des travaux (métier). Ensuite, on ajoute des équipiers qui assurent à la fois la quantité d’expertises nécessaires (assurer la capacité) et une double couverture de chacune des expertises nécessaires (atténuation du risque).
Autonomie organisationnelle : la structure de gestion autour des équipes agiles est volontairement légère et suppose que l’équipe, ainsi que les membres qui la composent, est autonome sur l’aspect organisationnel des travaux intraéquipe. D’un autre côté, en début de carrière ou dans les premiers semaines ou mois dans un nouvel environnement de travail, il est normal d’avoir un manque d’autonomie à ce niveau. Lors de la composition de l’équipe agile, il est donc important d’avoir un minimum d’équipiers qui sont déjà autonomes sur cet aspect. Ce sont eux qui viendront assurer l’autonomie de l’équipe pendant la montée en compétence des membres n’ayant pas encore acquis le même niveau d’autonomie.
Les personnes n’ayant pas encore accumulé assez d’expérience pour être autonome dans leurs tâches métier, dans l’organisation de leurs efforts personnels et de leurs interactions, sont donc considérées comme « non autonomes », alors que les autres sont « autonomes ». Il s’agit d’une progression normale pour de nombreux métiers dans plusieurs contextes. Il est donc important, pour une organisation, de clarifier de telles attentes.
Vue de l’extérieur, cette situation peut ressembler à une hiérarchie, mais c’est seulement la différence naturelle entre les membres non autonomes et autonomes. Contrairement à des rôles, il n’y a pas de limite sur la quantité de membres autonomes. En fait, il devrait être attendu que tous gagnent leur autonomie personnelle à terme. Voici une description de l’état d’autonomie d’une l’équipe selon différentes compositions de membres autonomes et non autonomes :
| Membres autonomes | Membres non autonomes | Niveau d’autonomie de l’équipe | État d’autonomie |
|---|---|---|---|
| 1 | 8 | 10% | Garderie |
| 2-3 | 6-7 | 30% | Non efficace |
| 4-5 | 4-5 | 50% | Fonctionnelle/risquée |
| 6-7 | 2-3 | 70% | Idéale |
| 8 | 1 | 90% | Navy SEALs |
Leadership : il est bien d’avoir dans l’équipe agile des gens métier autonomes, capables de juger de leur propre autonomie, mais que ce passe-t-il si l’on désire avoir le pouls de l’ensemble de l’équipe métier? Si l’on veut avoir un avis expert sur le niveau d’autonomie métier des différents individus, à qui parle-t-on? Ici, il est important qu’au moins un ou deux (idéalement) membres autonomes et séniors métier faisant partie de l’équipe agile possèdent aussi des capacités de leadership métier. Ces personnes peuvent, a minima, devoir connaître l’état de santé métier de leur équipe et savoir identifier d’éventuels risques ou problématiques. Personnellement, je délègue encore plus de responsabilités à ce type de responsable sénior, comme la supervision de la montée en compétence métier des « non autonomes » de son équipe.
Scrum et le Scrum Master
Comme spécifié dans le guide Scrum, l’équipe Scrum doit avoir « toutes les compétences nécessaires pour créer de la valeur à chaque Sprint. Elle est également autogérée […] »[1]. Afin d’avoir ces « compétences nécessaires », l’équipe devrait être capable, sans aide extérieure, de planifier, d’organiser et de réaliser les efforts métier prévus dans un sprint. Aussi, afin d’avoir ces « compétences nécessaires », l’équipe devrait, sans aide extérieure, avoir une compréhension globale de la capacité métier à livrer les éléments du carnet de produit.
Dans cette approche, on s’attend à ce que l’agilité métier soit de la responsabilité des membres autonomes au niveau métier, alors que l’agilité du cadre/l’approche de travail reste la responsabilité du Scrum Master.
Adapting Scrum — Return on experience 2/7
In the second article of the series, we will explain why a hierarchy was introduced in the Scrum teams, why this practice is applicable in multiple contexts, and how it can align with the Scrum framework.
The goal of this series is to examine the application of the Scrum framework in a practical context where, in the end, compromises are almost always necessary. Here is the list of articles from this series:
- Introduction & context.
- There is a hierarchy in the Scrum team (this article).
- Many team members are specialized.
- 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
Skills, organization, and leadership
It is rare that all the Agile team members are experts, veterans, or seniors. Most of the time, we will find a mix of juniors, intermediaries, and seniors who, together, have “all the skills necessary”[1] for the production of the backlog items. But what does “all the skills necessary” mean for an Agile team? Based on my experience[2], those skills are divided into two parts: skills autonomy and organizational autonomy.
Skills autonomy: to ensure a minimum level of skill expertise while creating an Agile team, we must balance three elements: the level of expertise of the individuals in the team, the number of team members, and the total cost of the team. Here, the first trap is to fall into one of the following extremes: only having people that completely master the end-to-end skills (explosion of cost) or having people that only master a part of the end-to-end skills (explosion of risk). A more economical and safer solution is to have a minimum of members mastering the end-to-end, which will provide an overview of the skilled efforts, combined with a selection of members ensuring both the quantity of necessary expertise and double coverage of the necessary expertise (risk mitigation).
Organizational autonomy: the management structure around Agile teams is purposefully light and assumes that the team and its members are autonomous for the organization of the in-team efforts. On the other hand, when starting a career or in the first weeks or months in a new work environment, it is normal to lack autonomy. While creating a new Agile team, it is then important to have a minimum of members that are already able to ensure the autonomy of the whole team while the member lacking those skills are ramping up.
People who don’t have accumulated enough experience yet to be autonomous in their own trade (skills) and in the organization of their own tasks and interactions are considered “non-autonomous”, while others are “autonomous”. This is a usual progression in many professions in many contexts, and it is then important for the organization to clearly communicate such expectations.
From an outside perspective, this may look like a hierarchy, but it is simply a natural difference between skilled workers that are either autonomous or not. Contrary to roles, there are no limits on how many autonomous members you can have. In fact, it should be expected that all members gain their personal autonomy over time. Here’s a description of the state of a team’s autonomy based on different mixes of autonomous and non-autonomous team members:
| Autonomous Team members | Non-autonomous Team members | Team Autonomy Level | State of autonomy |
|---|---|---|---|
| 1 | 8 | 10% | Kindergarten |
| 2-3 | 6-7 | 30% | Inefficient |
| 4-5 | 4-5 | 50% | Functional/Risky |
| 6-7 | 2-3 | 70% | Ideal |
| 8 | 1 | 90% | Navy SEALs |
Leadership: It is good for the agile team to have autonomous skilled people capable of understanding their own level of autonomy, but what if we want to have a global view of the team? If we want an expert perspective on the level of “skill” autonomy of the team members, who do we talk to? Here it is important to have at least one (ideally two) senior and autonomous members of the realization team who also possess some leadership skills. Such people can, minimally, be accountable for understanding the state of the realization team and identifying possible risks and problems. I personally delegate even more responsibility to this type of “senior-lead” profile, like the supervision of the skill acquisition of the non-autonomous members of their team.
Scrum and the Scrum Master
As specified in the Scrum Guide, the Scrum team must have “all the skills necessary to create value each Sprint. They are also self-managing […]”[1]. In order to have the “skills necessary”, the team should be able, without outside help, to plan, organize, and execute the in-sprint skilled efforts. Also, in order to have the “skills necessary”, the team should, without outside help, have a global understanding of the team’s capacity to deliver the product backlog items.
In this approach, we expect that profession-specific agility is under the responsibility of the autonomous members of the realization team while the framework/approach agility would remain the responsibility of the Scrum Master.
Références/References
[1] Sutherland J. Schwaber K., The Scrum Guide, November 2020 version, Hyperlien/Hyperlink: https://scrumguides.org/scrum-guide.html
[2] Pour connaître le contexte et de l’information organique, lisez le premier article de cette série/For context and bio information, read the introduction article of this series. Hyperlien/Hyperlink: https://excellenceagile.com/2022/10/31/adaptation-de-scrum-retour-dexperience-1-7/
Excellence Agile 