Les rôles au sein d’une Scrum Team

Cet article vous présentera les rôles au sein d’une équipe Scrum, basé sur ma vision et mes expériences professionnelles.
Pour rappel Scrum est une méthode agile dédiée à la « conduite de projet ». Cette méthode de gestion, ou plutôt ce Framework de management de projet, a pour objectif d’améliorer la productivité d’une équipe en délivrant de manière itérative et incrémentale.
Il existe trois rôles distincts au sein d’une équipe Scrum, Le Scrum Master, La dev team et le Product Owner.

Le Scrum Master

Le Scrum Master est garant de l’application de la méthodologie Scrum au sein d’une équipe. Il doit s’adapter aux problématiques de chaque projet et de chaque équipe dans lesquelles il est amené à intervenir. Son rôle n’est pas d’appliquer bêtement l’ensemble des règles mais de proposer l’implémentation d’artefacts agile adaptés à l’équipe.
Scrum n’est pas une loi de l’agilité mais un « Framework » (un genre de boite à outils), et le Scrum Master est la personne qui à pour rôle de choisir quels outils sont nécessaire pour aider l’équipe pour être plus productive.

Il est aussi la en tant que facilitateur de l’équipe, c’est-à-dire qu’il a ce rôle très important de faire son possible pour éliminer l’ensemble des obstacles rencontrés par l’équipe ; s’il ne peut pas supprimer l’obstacle lui-même, il fera son possible pour trouver ceux qui peuvent le faire et suivre l’avancée.

Néanmoins, il doit faire tout son possible pour rendre l’équipe autonome et ne pas créer de « Scrum Master dépendance ».

Il n’est pas rare de voir qu’un des rôles du Scrum Master est « d’animer les cérémonies ». Je ne suis pas d’accord avec cette affirmation du fait que l’équipe doit être la plus autonome possible (même si cela requiert un certain temps avant d’être atteint). Par exemple, le rôle du scrum master au sens du « scrum guide » est simplement de s’assurer que le daily meeting a lieu et qu’il ne dure pas plus de 15 min. Ou encore lors de la démo, il n’a pas la capacité de présenter le réalisé du sprint, contrairement au Product Owner.

Le Scrum Master est aussi un formateur, bien que cela soit compliqué lorsque le Scrum Master est junior, il doit cependant devenir le formateur de l’équipe. Il aidera le Product Owner à devenir meilleur dans son rôle et aux développeurs à bien comprendre ce qu’est être un développeur agile.

Le Scrum Master n’hésitera pas à faire des ateliers et des formations pour que l’équipe monte en compétence dans le domaine de l’agilité ; il pourra également accompagner les nouveaux membres qui arrivent dans l’équipe afin qu’ils s’adaptent au plus vite. Il ne doit pas hésiter également à sensibiliser les acteurs extérieurs qui ont des impacts sur l’équipe Scrum ; les sensibiliser diminuera le risque que ceux-ci deviennent des obstacles à l’avenir.

Le Product Owner

Le Product Owner est le lien entre le client et l’équipe. C’est donc lui qui, au sein de cette dernière, porte la vision du produit. Il est l’interlocuteur privilégié des utilisateurs. Il devra être très disponible, aussi bien pour les utilisateurs que pour l’équipe. Ses compétences ne se limitent toutefois pas au domaine métier puisqu’il participe activement au sprint et plus particulièrement à la mise en place des tests. Il favorise également la dynamique de l’équipe en maximisant la valeur de leur travail.

Bien que sa présence permanente auprès de l’équipe ne soit pas indispensable, plus celle-ci est importante, plus cela est bénéfique. Sa disponibilité doit être maximale tout au long du projet.
S’il ne décide pas de l’organisation de l’équipe, il est responsable de l’établissement des Users Stories et de leur priorisation. Il devra réétudier régulièrement la priorisation afin de la faire correspondre au mieux aux attentes du client et à la vélocité de l’équipe, itération après itération.
S’il doit être ouvert au feedback du client comme aux remarques de l’équipe lors des rétrospectives, c’est tout de même à lui qu’appartient la décision finale.

Une des grandes responsabilités du Product Owner est donc la priorisation des Users Stories. C’est également un des sujets les plus abordés par ceux qui débutent à ce poste. Pour définir la priorité de chaque Users Stories, le Product Owner dispose d’un certain nombre d’outils ou plus exactement d’une liste de facteurs à prendre en compte :

  • L’importance de la fonctionnalité pour le client (business value)
  • L’estimation initiale donnée par l’équipe (coût)
  • L’expérience apportée
  • Le facteur de risque

Grâce à ces différents facteurs, le Product Owner pourra fixer une valeur étalon qui permettra le classement des différentes Users Stories par priorité au sein du backlog. Le backlog n’est pas définitif et pourra être modifié selon l’évolution des facteurs.
Par exemple, on peut imaginer que le développement d’une fonctionnalité lors d’un sprint apporte suffisamment d’expérience à l’équipe pour lui permettre de revoir à la baisse l’estimation initiale d’une autre fonctionnalité lors d’une prochaine itération.

Par conséquent, un bon Product Owner se doit de posséder les compétences suivantes :

  • Une bonne connaissance du domaine métier
  • Un bon esprit de synthèse
  • La faculté de définir techniquement un produit
  • Un forte capacité d’écoute
  • La capacité de prendre des décisions et de les assumer

Il n’est pas forcément aisé de trouver dans son équipe quelqu’un regroupant toutes ces qualités et faire appel à un coach ou à une formation est souvent nécessaire. Il n’est pas rare de voir des Business analysts se tourner vers le rôle de Product Owner.

La dev team

Souvent appelé « dev team », cette équipe est composée des personnes nécessaires à la réalisation d’un incrément potentiellement livrable. L’appellation « dev team » est réductrice car elle est bien plus qu’une simple équipe composée de développeurs.
En effet, l’équipe doit être complètement autonome sur les différentes tâches d’un incrément et par conséquent doit être composé de toute l’expertise nécessaire à la réalisation de celui-ci. Si une équipe à besoin d’un testeur ou d’un designer, elle doit en intégrer un. C’est pourquoi le scrum guide préconise une équipe composée de 3 à 9 personnes au maximum. 

Cette équipe possède les caractéristiques suivantes :

  • L’équipe doit être autonome, par conséquent personne n’a la capacité de dire comment l’équipe doit réaliser l’incrément.
  • L’équipe doit posséder toutes les compétences nécessaires à la réalisation d’un incrément.
  • Il n’y a pas de hiérarchies au sein de l’équipe
  • Elle ne possède pas de « sous-équipe » selon le domaine d’expertise, tous les membres font parties d’une même équipe quel que soit leurs expertises (développeur, designer, business analyste…).

La taille idéale d’une « dev team » dépend des individus qui la compose. Elle doit être petite pour rester agile mais suffisamment grande pour que les réalisations d’un sprint puissent être significative. En effet, moins de trois membres ne permettent pas une réalisation suffisante au cours d’un sprint sachant qu’elle doit contenir toutes les compétences nécessaires à la réalisation de celui ci. De plus, plus de neuf membres engendre une trop grosse complexité de coordination et engendrera une diminution du rendement de l’équipe.

Rétrospective Agile #1 – Le Speed Boat

En agilité, la rétrospective est une des cérémonies les plus importantes se déroulant à la fin de chaque sprint (itération).

Le but étant de faire le point avec l’équipe sur ce qui a été fait lors du dernier sprint en positif ou négatif afin d’en définir des actions d’amélioration pour les sprints suivants.

La rétrospective est donc un élément clef du principe d’amélioration continue rendant une équipe auto-apprenante.

Les rétrospectives peuvent se faire de mille et une façons différentes et se découpent en plusieurs étapes.

Cet article présente une de ses façons : le Speed Boat.

Etape 1 : dessine-moi un … bateau ?

La première chose à faire est le dessin du fameux bateau, c’est en général le Scrum Master qui met à profit ses talents artistiques mais il peut tout à fait en être autrement avec un volontaire (ou alors imprimer un dessin tout fait sur le net).

blog ai3 01 Rétrospective Agile #1 - Le Speed Boat

Le dessin ressemble approximativement à ceci.

Le Scrum Master va ensuite expliquer à l’équipe ce que représente le dessin.

blog ai3 02 Rétrospective Agile #1 - Le Speed Boat

1 – Les propulseurs : Les actions / choses qui font avancer l’équipe à accomplir les objectifs du sprint (ex : Bon esprit d’équipe, bon niveau technique, serveur de tests)

2 – Les ancres : Ce qui a ralenti l’équipe durant le sprint (parfois chaque ancre représente les freins passés, présents et futurs) (ex : vacances, changement de PO).

3 – Les obstacles : Les risques/obstacles que l’équipe va potentiellement rencontrer dans le futur (ex : pas de budget, gel des MEP)

4 – Scrum Team : Le bâteau représente l’équipe et son travail

5 – Sprint Goal : L’île paradisiaque représente les objectifs à atteindre du sprint

Etape 2 : Réflexion et partage

L’équipe entière aura ensuite quelques minutes (généralement 5 min) pour noter les faits marquants sur des post’its. Une fois que tout le monde aura terminé, chacun viendra positionner ses post’its à l’endroit adéquat en expliquant son choix.

Niveau post’its le SM a le choix entre :

Option 1 : une couleur unie pour tous les faits

Option 2 : une couleur par type de fait (Propulseurs, Ancres ou Obstacles)

blog ai3 03-1024x574 Rétrospective Agile #1 - Le Speed Boat

Etape 3 : Actions

Le Scrum Master et l’équipe prendront soin de regrouper les post’its de même sujet.

L’équipe choisira à partir de là et en fonction des capacités des actions à effectuer pour améliorer le prochain sprint.

Ces actions seront écrite sur post’its d’une autre couleur et collées sur les problèmes concernés (ou sur les propulseurs que nous pouvons encore améliorer).

blog ai3 04 Rétrospective Agile #1 - Le Speed Boat

Par exemple sur une ancre « Changement de PO » le plan d’action nécessaire pour palier au ralentissement serait peut-être d’effectuer un On-boarding Agile et fonctionnel rapide.

Avant la fin de la rétro, chaque tâche se verra affectée d’une personne (volontariat) qui se chargera de la traiter au prochain sprint.

Au sprint suivant, un point sur les actions sera fait pour s’assurer d’être le plus efficaces possible.

—————————–

Et voilà, très simple, n’hésitez pas si vous avez des questions. Il en existe plusieurs variantes dont certaines avec les objectifs sur le cocotier ou un soleil représentant les gratitudes, à vous de faire comme bon vous semble 😉

WSJF : Priorisez simplement votre backlog

Qu’est ce que le WSJF ?

Le WSJF « Weighted Shortest Job First » : il s’agit d’un système Agile de priorisation qui vise à effectuer les US (ou features, epics tout dépend de la couche qu’on veut prioriser) dans un ordre optimisé .

L’algorithme utilisé se traduit graphiquement comme ceci :

 

blog ai3 1 WSJF : Priorisez simplement votre backlog

Le but étant de faire dans l’ordre :

  • les US non complexes mais avec une forte valeur
  • Les US complexes mais avec une forte valeur
  • Les US non complexes mais avec une valeur moindre
  • Les US complexes avec une valeur moindre (bien souvent, ces US ne sont jamais faites et finissent par être annulées côtés client car elles ne rapportent pas assez par rapport au coût)

 

Quand l’utiliser ?

Tout comme l’agilité, il faut savoir s’en servir à bon escient. Tous les projets ne sont pas faits pour être conduits en Agile, ils ne sont pas tous bons à prioriser en WSJF.

Il est surtout bon de l’utiliser quand le projet n’a pas de priorités précises ou si vous trouvez qu’elles ne sont pas justifiées.

Quoi qu’il en soit, le résultat n’est pas gravé dans le marbre, il ne permet d’avoir qu’une ligne directrice. A voir ensuite avec le PO pour ajuster à sa convenance.

 

Qui participe à l’atelier ?

  • Le PO
  • Le SCRUM MASTER
  • La Dev Team (toujours bon pour les devs d’avoir un point de vue business sur les US et inversement)

 

Calcul du Cost Of Delay

Le cost of delay est comme son nom l’indique l’impact qu’aura le temps sur le coût de chaque US.

Il se calculera sur 3 axes :

  • La Business Value
  • La Criticité
  • Réduction des risques / Facilitation développement d’une autre US

Pour le calculer, le plus simple est d’utiliser les cartes de planning poker comme ceci :

 

blog ai3 2 WSJF : Priorisez simplement votre backlog

LE PO place ensuite les US sous les valeurs correspondantes.

Si le départ est compliqué car trop vague, il faut essayer de repérer une ou deux US moyennes pour s’en servir comme base de référence.

Cette méthode permet d’avoir une vision d’ensemble et de pouvoir facilement comparer les US entre elles et les revaloriser.

Une fois toutes les US évaluées dans un axe, notez la valeur obtenue pour chacune et effectuez la même chose pour les deux axes restants.

 

Business Value :

US 1

3

US 2

40

US 3

0,5

US 4

8

US 5

13

US 6

13

Etant donné que la manipulation peut être très longue et redondante suivant les intervenants, le dernier axe (Réduction des risques/facilitation développement) est parfois supprimé.

En additionnant la valeur obtenue pour ces trois axes on obtient le Cost Of Delay.

 

Calculer le WSJF

Pour calculer la valeur WJSF permettant d’ordonner les priorités, il vous faut le Cost Of Delay mais également vos compléxités.

Pour cela trois solutions :

  • Soit la DEV Team a effectuer un planning poker en amont et a donc pricé l’ensemble des US (attention, il ne faut pas que le PO voit ses valeurs avant d’effectuer ses choix pour ne pas être influencé)
  • Soit la complexité se calcule de suite de la même manière que les trois axes précédents par la DEV TEAM (mais celle-ci risque d’être influencé par les choix PO)
  • Soit un planning poker sera effectué plus tard par la DEV TEAM (mais celle-ci risque d’être influencé par les choix PO également)

Selon moi, la meilleure solution reste d’effectuer un planning poker avant de venir en atelier WSJF mais de cacher les résultats au PO dans la premier temps.

Une fois la complexité de chaque US effectuée, calculez le WSJF comme suit :

WSJF = Cost Of Delay / Complexité

Une fois que toutes les US ont une valeur WSJF, il suffit des les trier dans l’ordre décroissant pour obtenir les priorités :

 

blog ai3 2 WSJF : Priorisez simplement votre backlog

blog ai3 3-1 WSJF : Priorisez simplement votre backlog  blog ai3 4 WSJF : Priorisez simplement votre backlog

 

Exemple de valeurs :

US

Business Value

Criticité

Opportunité/Risks

Cost of delay

Complexité

WSJF

US 1

3

2

1

6

80

0,075

US 2

40

8

1

49

3

16,34

US 3

0,5

40

20

60,5

8

7,56

US 4

8

2

3

13

1

13

US 5

13

3

1

17

5

3,4

US 6

13

0,5

1

14,5

13

1,11

 

L’ordre serait donc le suivant :

US 2

US 4

US 3

US 5

US 6

US 1

 

Ce qui dans notre courbe représente :

blog ai3 5 WSJF : Priorisez simplement votre backlog

Comme on peut le constater, les US 2,5 et 4 sont à effectuer en premières. Exception faite de l’US 3 qui a été ajoutée à cause de son impact Risque/Dépendance (on peut imaginer qu’elle est nécessaire pour faire le reste).

L’US 6 vient ensuite pour finir par la 1 qui est trop complexe par rapport à ce qu’elle apporte.

Cet ordre est donc le plus optimisé entre plusieurs facteurs clés et les US seront donc traitées dans ce sens.

Le PO peut tout de même faire des ajustements s’il trouve que cela est nécessaire.