Savoir déléguer des décisions ou des tâches est une compétence clé qui évite les innombrables attentes à chaque étape d’un projet et améliore le flux de travail des équipes.
Encore faut-il savoir ce qu’il faut déléguer et à quel niveau ?
Pour remporter l’adhésion de tous autour de ce sujet parfois sensible, il est préférable d’encourager votre équipe à définir elle-même ses propres mécanismes de délégations.
Pour cela, nous vous présentons les principes du « Delegation Poker » et quelques cas pratiques pour mieux comprendre la démarche et la mettre en application dans vos contextes.
Principes du Delegation Poker
Le « Delegation Poker » est un atelier qui vise à clarifier les responsabilités entre les membres d’une équipe et leur manager.
Mais il peut aussi s’appliquer à des individus ou des équipes sans liens hiérarchiques, dans un contexte agile ou non agile.
Il met rapidement en exergue les difficultés ou différences de perception concernant les responsabilités de chacun.
Pour illustrer la démarche, prenons l’exemple d’un représentant des utilisateurs finaux (A) amené à travailler avec les membres d’une équipe agile (B) dans le cadre d’un nouveau projet.
Souhaitant une collaboration efficace, ils se réunissent pour définir ensemble les mécanismes de délégation.
Chaque participant dispose d’un jeu de 7 cartes où chaque carte représente un niveau de délégation :
- DIRE : A prend la décision et informe B
- VENDRE : A prend la décision, essaye de convaincre B et l’aide à se sentir impliqué
- CONSULTER : A demande son avis à B avant de prendre une décision qui tient compte de cet avis
- S’ACCORDER : A et B dialoguent, avant de prendre une décision commune
- PRÉCONISER : A donne son avis et espère que B en tiendra compte dans sa prise de décision
- SUIVRE : A laisse à B le choix de la décision, mais demande à ce qu’elle soit argumentée
- DÉLÉGUER : A délègue entièrement la décision à B sans nécessité d’être informé
Pour chaque activité qui concerne A et B, l’objectif est de se mettre d’accord sur le niveau de délégation souhaité, entre 1 et 7.
Pour une activité donnée (exemple : prioriser les besoins), demandez à chaque participant d’abattre une carte pour indiquer le niveau de délégation souhaité.
Suite au vote, place au dialogue !
A : « En tant que représentant métier, j’ai voté 1 (DIRE) car je considère que c’est à moi seul de prioriser les besoins ! ».
B (PO) : « En tant que Product Owner, j’ai voté 5 (PRÉCONISER) car je considère que prioriser les besoins fait pleinement partie de mon rôle ! Bien entendu, j’écouterai les avis de A sur la priorisation, mais au final, c’est moi qui dois prendre la décision ».
B (SM) : « En tant que Scrum Master et garant de l’application de Scrum, j’ai voté 6 (SUIVRE) car je considère que le Product Owner a toute la légitimité pour faire ses choix. Par conséquent, le représentant métier (A) doit simplement suivre les choix effectués ».
A répond à B (SM) : « Je n’ai pas encore bien assimilé la théorie du cadre Scrum et notamment le rôle de Product Owner, mais en tout cas, je pense qu’il faut adapter la méthode au contexte. J’ai mon mot à dire sur la priorisation et je ne veux pas seulement suivre les choix effectués par le PO. Je souhaite à minima être entendu par le PO pour qu’il priorise au mieux. »
B (PO) répond à A : « OK, je prendrai ton avis en considération pour faire les meilleurs choix possibles.»
Favorisez les discussions pour comprendre les écarts.
Assurez-vous que le temps de parole de chacun est bien respecté.
Ensuite, procédez à un 2ᵉ tour de vote.
Si le dialogue à l’issue du 1ᵉʳ tour a été constructif, vous devriez avoir moins de disparité parmi les résultats du 2ᵉ vote.
Dans tous les cas, vous devez trouver un consensus pour ne retenir au final qu’un seul niveau de délégation.
Dans notre exemple, tout le monde s’est aligné sur un vote à 5 (PRÉCONISER) sauf le SM qui reste campé sur sa position avec un vote à 6 (SUIVRE).
Au final, le consensus adopté est 5 (PRÉCONISER).
Recommencez ainsi le processus pour l’ensemble des activités pour lesquelles un niveau de délégation doit être clarifié.
À la fin de l’atelier, vous pouvez en faire une synthèse sous forme de tableau :
Vous remarquerez ici que la délégation peut concerner des tâches (exemple : Rédiger les User Story) ou bien des décisions (exemple : Valider les User Story).
Cet atelier peut également être réalisé en cours de projet pour clarifier les rôles.
Dans ce cas, il est intéressant de le faire en deux passes :
- Une 1ʳᵉ passe pour aligner tout le monde sur la perception de la situation actuelle
- Une 2ᵉ passe pour construire la nouvelle situation désirée
Voyons maintenant les cas pratiques les plus classiques pour lesquels il est pertinent de réaliser un atelier « Delegation Poker ».
Cas pratique 1 : Product Owner (PO) et Business Analyst (BA)
Pour jouer pleinement son rôle, un Product Owner doit être légitime, compétent et disponible.
Dans les faits, nous constatons qu’il est souvent très difficile de trouver une personne qui réunit ces 3 qualités.
Bien souvent, la personne la plus légitime n’a pas la disponibilité suffisante pour tenir le rôle, d’où le recrutement d’un Business Analyst pour venir compléter le dispositif.
Dans le binôme ainsi constitué, l’un possède la légitimité (PO), l’autre non (BA).
Définir les niveaux de délégation entre le PO (A) et le BA (B) prend donc tout son sens !
Voici un résultat possible de l’atelier :
Les résultats ci-dessus peuvent être interprétés de la manière suivante :
- Le PO est légitime pour porter seul la vision produit. Il définit la valeur métier des items du Product Backlog tout en impliquant le BA dans ses choix. Il consulte le BA pour la priorisation et la validation des User Story, mais reste décideur sur ces activités.
- Faute de disponibilité, le PO délègue la rédaction des User Story au BA en lui donnant malgré tout des préconisations.
Cas pratique 2 : Tech Lead (TL) et développeurs (DEV)
Le Tech Lead (TL) est le référent technique de l’équipe. Il est garant de la qualité logicielle du produit.
Il possède une excellente maîtrise des technologies nécessaires à l’élaboration du produit.
Et il est en charge de la montée en compétences techniques des membres de l’équipe.
Dans un dispositif multi-équipes (agilité à l’échelle), il participe à la synchronisation hebdomadaire des Tech Lead pour représenter son équipe d’un point de vue technique.
Dans ce contexte, que peut faire un DEV en toute autonomie ?
À quels moments le TL doit-il intervenir ?
Là encore, définir les niveaux de délégation entre le TL (A) et les DEV (B) prend tout son sens !
Voici un résultat possible de l’atelier :
Les résultats ci-dessus peuvent être interprétés de la manière suivante :
- Le TL est garant de la conception technique générale qu’il définit lui-même. Il rédige les directives techniques des User Story complexes en impliquant les développeurs.
- Il laisse l’autonomie aux développeurs sur les développements et les tests unitaires, mais leur demande d’être capables d’argumenter leurs choix.
- Il valide le code d’une User Story en consultant les développeurs.
Cas pratique 3 : Product Owner (PO) et Quality Analyst (QA)
Le Quality Analyst (QA) possède une expertise sur les tests.
Pour être prête, une User Story doit contenir des tests d’acceptation.
Qui écrit les tests ? Qui exécute les tests ? Qui valide les User Story ?
Là encore, définir les niveaux de délégation entre le PO (A) et le QA (B) vous aidera à clarifier les rôles de chacun :
Les résultats ci-dessus peuvent être interprétés de la manière suivante :
- Le PO et le QA rédigent en binôme les critères d’acceptation,
- Le PO laisse le soin au QA de tester les User Story, mais il suit l’avancement des tests,
- Le PO consulte le QA pour valider les User Story,
- Enfin, le PO suit les travaux concernant l’automatisation des tests.
Cas pratique 4 : Product Owner (PO) et Scrum Master (SM)
Le Scrum Master (SM) est un véritable coach pour le Product Owner (PO) concernant l’agilité sous tous ses aspects.
Le « Delegation Poker » peut vous aider à clarifier le niveau d’aide dont bénéficie le PO (A) de la part du SM (B) :
Les résultats ci-dessus peuvent être interprétés de la manière suivante :
- Le PO a le pouvoir de décider seul d’abandonner un sprint,
- Le PO se fait aider par le SM concernant le découpage des User Story trop grosses,
- Le PO demande au SM de produire les indicateurs agiles du sprint,
- Le PO et le SM préparent ensemble la Sprint Review.
Conclusion
Vous maîtrisez désormais la technique du « Delegation Poker ».
Elle vous sera fort utile pour clarifier les rôles et responsabilités de chacun non seulement au sein de votre équipe, mais aussi entre votre équipe et son écosystème.
Les 4 cas pratiques étudiés dans cet article sont des cas rencontrés très fréquemment sur le terrain.
Vous aurez donc sûrement l’occasion de tester rapidement le « Delegation Poker » dans votre contexte !
Profitez des rétrospectives pour revoir régulièrement vos mécanismes de délégation afin d’améliorer en permanence la collaboration au sein de votre équipe.
