Atelier Coaching – Approche Paradoxale

Qui n’a pas été confronté à une situation qui stagnaient sans trouver de réelles solutions à cause de non remise en question ?

blog ai3 approche-paradoxale Atelier Coaching - Approche Paradoxale

Le plus bel exemple qui nous ait été donné de faire, fût pour une société qui était en plein turnover et cherchait désespérément à garder ses collaborateurs.

Si l’on questionnait chaque Manager/Directeur la réponse était évidente « on fait tout comme il faut, je ne vois pas pourquoi ils partent ! « . Et pourtant, les collaborateurs partaient bel et bien …

Si à contrario on allait questionner les collaborateurs nous avions pleins de choses à mettre dans notre panier ! Mais tout le problème était de le faire comprendre aux supérieurs…

« L’approche Paradoxale » est un outil permettant de trouver des solutions à des situations qui stagnent en partant du pire pour trouver le meilleur ou comment tourner un sujet important à la dérision pour mettre le doigt sur des choses auxquelles nous n’aurions pas pensé sinon.

Dans l’exemple plus haut, la problématique de l’atelier n’était donc pas « Comment garder nos collaborateurs ? « , ça ils avaient déjà tous penché la dessus, mais au contraire « Comment faire partir ces p*** de collaborateurs ? « .

Déroulé

La première étape est d’annoncer la problématique. Gardez le ton du dérisoire et de l’amusement sur tout le long, il faut que les gens se sentent à l’aise et que l’ambiance soit présente pour faire un effet choc sur la fin de l’atelier.

Exemple : « Comment faire partir ces p*** de collaborateurs ?

Ils nous embêtent, on doit travailler plus et ils nous coûtent un max de blé ! Non mais franchement, comment on peut faire pour les pousser à la porte ???? Il faut que ça reste légal bien sûr, on ne veut pas mettre la clé sous la porte 🙂 » (imaginez la tête de la DRH quand on lui a dit ça :p).

Partie 1 : Réflexion

Chaque participant se verra munit de post-its et prendra le temps de la réflexion pour trouver ce qui ferait partir les collaborateurs au plus vite.

Après un temps défini, chacun son tour ira coller ses idées au tableau en les expliquant et en regroupant avec les post-its similaires.

Exemples à ce stade :

  • « Plus d’augmentation »
  • « Des heures sup le soir et weekend »
  • « On les forme pas »
  • « On ne les félicite jamais, on les enfonce même ! « 
  •  » Pas d’afterworks et moments d’équipe »

Partie 2 : Regroupement

Tous ensemble les participants réfléchissent et convergent sur ce qui peut être regroupé.

Partie 3 : Prise de conscience

C’est là, que tout va se jouer, vous allez poser la question qui fâche « Mais en fait, il n’y a pas des choses que vous faites déjà là-dedans avec vos collaborateurs ? ».

Généralement, les sourires s’effacent et c’est là que les participants prennent conscience qu’ils ne font pas si bien en fin de compte.

Chacun se verra distribué des gommettes et ils iront tous les déposer sans commenter sur les post-its sur lesquels ils se retrouvent.

Partie 4 : Améliorations

Pas de panique, on est là pour trouver justement les solutions aux vrais problèmes !

Demandez aux participants de trouver de solutions sur les idées contenant le plus de gommettes et tirez des améliorations à effectuer.

Exemple :

  • « On les forme pas  » => Octroyer une formation à chacun sur l’année.
  • « On ne les félicite jamais, on les enfonce même ! » => Mettre en place des façons collectives de se féliciter.
  • … (on parle pas de l’augmentation hein, ça c’est le directeur qui tranche :p)

Partie 5 : Actions concrètes

La dernière phase consiste à trouver les actions concrètes de ses actions d’améliorations avec Owner et date de mise en place.

Exemple :

  • « Octroyer une formation à chacun sur l’année » => Chaque manager fait un point avec ses collabs pour trouver une formation et contacte le service associé pour les inscrire, deadline dans 1 mois
  • « Mettre en place des façons collectives de se féliciter » => Tartenpion met en place les Kudo Cards dans son équipe, deadline dans 2 semaines

Conclusion

Très bon atelier de coaching à sortir dans de nombreuses situations. Vous pouvez également utiliser cet outil lorsqu’une équipe part à la dérive sans en rendre compte avec comme problématique par exemple « Comment faire échouer notre projet ? « .

Daily Scrum from Hell – Surmontez les difficultés en Stand UP

En tant que Scrum Master, nous sommes souvent face à des personnes non impliquées ou posant problème en Daily. Nous aurons beau leur dire ce que nous voulons, tant que ces personnes ne prendront pas elles-mêmes conscience de leur attitude, rien ne changera.

« Daily Scrum from Hell » est un serious game dans lequel chacun interprétera un rôle différent, allant du parfait bon élève à l’élément perturbateur par excellence, lors d’un Daily Meeting.

Règles

Avant de distribuer les cartes, prévoyez 2 tiers de cartes « équipier » et 1 tiers de carte « mauvais comportement ».

Mélangez et distribuez une carte par personne (que chacun lira en secret) puis effectuer le Daily habituel.

Les cartes « mauvais comportement » auront un objectif machiavélique à atteindre bien entendu…

blog ai3 DailyFromhell1 Daily Scrum from Hell - Surmontez les difficultés en Stand UP

Afin que les personnes ciblées par ce serious game puisse prendre conscience de leur attitude, il est préférable de leur attribuer le rôle de facilitateur afin qu’ils puissent se mettre à la place du Scrum Master (effectuez le jeu plusieurs fois si besoin sur plusieurs jours).

Une fois le Daily fort particulier haut en rires terminé, vous pouvez vous amuser à trouver les rôles de chacun. N’oubliez pas de faire conclure l’équipe et surtout le facilitateur sur les comportements qui ont eu lieu et les problèmes engendrés.

Vous pouvez télécharger les cartes ici : https://coach-agile.com/wp-content/uploads/2019/07/DAILY-SCRUM-FROM-HELL-KIT-V1.pdf.

Vous pouvez aussi en faire  des personnalisées si vous préférez cibler certains comportements ;).

Conclusion

Très bon outil qui apportera du fun à l’équipe tout en permettant d’améliorer les Stand UP à venir. Vous pouvez également vous en servir pour former des Scrum Master en devenir 😉

Coaching – Les 5 pourquoi

Lorsque l’on est face à un problème, on a tendance à chercher la solution directement sans creuser et on se retrouve à mettre un pansement sur une hémorragie interne, donc cela ne sert à rien.

La méthode des « 5 pourquoi » est souvent utilisée en coaching afin de déterminer la cause exacte d’un problème en remontant petit à petit vers la source afin de trouver la solution adaptée qui en découle.

Origines

Cette méthode a été initiée dans les années 90 par Taiichi Ohno s’appuyant sur la catégorisation des causes possibles d’un problème suivant deux thématiques :

  • Les causes symptomatiques, celles qui paraissent évidentes et identifiables rapidement (exemple XX)
  • Les causes originelles, celles qui sont la sources des causes symptomatiques auxquelles on ne pense pas au premier abord (exemple XX)

L’ingénieur Japonais mise donc sur le simple fait de rechercher la source du problème afin que celui-ci ne se reproduise pas plutôt que d’en « soigner » les conséquences.

Démarche

La démarche est simple, il suffit de poser la question « Pourquoi? » 5 fois de suite afin de remonter à la source du problème (voir moins si on trouve avant et ne pouvons plus aller en amont).

Quelques Exemples

Problème : nous avons un retard sur la livraison de nos User Stories

1er pourquoi :
« Pourquoi les US ne sont pas livrées à temps dans le Sprint? « 
Réponse : « Les développeurs n’ont pas pu les terminer » (encore les devs, ce sont des faignants ! :D)

2eme pourquoi :
« Pourquoi les développeurs n’ont pas pu les terminer ? « 
Réponse : « Ils ont commencé, mais n’ont eu les retours du PO que très tard durant le sprint »

3eme pourquoi :
« Pourquoi le PO a-t-il attendu autant de temps à tester les US ? « 
Réponse : « Parce qu’il n’a pas eu le temps de le faire avant »

4eme pourquoi :
« Pourquoi n’a-t-il pas eu le temps de le faire avant ? « 
Réponse : « Parce qu’il passe tout son temps à écrire les nouvelles US, les règles métiers étant complexes et donc n’a pas le temps de faire la recette »

Solution : Engager un testeur qui sera affecter uniquement à la recette et pourra donc faire avancer les développeurs.

Problème : Ma copine est furieuse contre moi

1er pourquoi :
« Pourquoi est-elle furieuse contre toi ? « 
Réponse : « Parce que je suis arrivée en retard à notre rendez-vous »

2eme pourquoi :
« Pourquoi es-tu arrivé en retard ? « 
Réponse : « Parce que je me suis pas réveillé ce matin »

3eme pourquoi :
« Pourquoi ne t’es-tu pas réveillé ce matin ? « 
Réponse : « Parce que j’ai geeké toute la nuit »

Solution : Quand tu as un rendez-vous avec ta copine, ne joue pas la veille et couches-toi tôt si tu ne veux pas qu’elle te quitte !

Conclusion

Il s’agit d’un excellent outil de coaching qui permet à l’équipe de trouver elle-même ses solutions tout en restant nous-même neutres.

Petit bonus, vous pouvez même l’utiliser dans le cadre perso ;).

Utiliser Klaxoon pour nos rétrospectives à distance

Que ce soit à cause du virus ou tout simplement car le télétravail devient une habitude dans nos sociétés et chez les clients, vous serez sûrement amenés un jour à effectuer une Rétrospective à distance.

Cet article s’adresse avant tout aux Scrum Master, Coach Agile, Agile Master voulant initier un board pour une rétrospective à distance via l’outil Klaxoon.

Etape 1 : Créer un board

Dans klaxoon cliquez sur New tout en bas puis Board.

blog ai3 1 Utiliser Klaxoon pour nos rétrospectives à distance

Vous aurez alors plusieurs possibilités :

  • Créer un board avec une template personnalisées (Rétrospective, Speed boat, Ice Breaker…)
  • Partir de zéro pour initier un tout nouveau board (qui peut également vous servir de template par la suite)
blog ai3 2 Utiliser Klaxoon pour nos rétrospectives à distance

Si vous désirez par exemple, utiliser un template existant, il vous suffit de cliquer dessus pour en voir l’aperçu puis sélectionner « utiliser ce template ».

blog ai3 3 Utiliser Klaxoon pour nos rétrospectives à distance

Comme vous pouvez le voir, ce type de template est aussi complété par un mode d’emploi expliquant les étapes de la rétrospective (comme tout board Klaxoon, il faut zoomer pour voir les étapes en grand ;)).

Si les templates ne vous conviennent pas, vous pouvez partir de rien et donc il vous suffit de donner un nom (voir une image) à votre Board puis cliquer sur « Créer ».

Arrivera ensuite le paramétrage de votre Board.

Etape 2 : Paramétrer votre board

blog ai3 4 Utiliser Klaxoon pour nos rétrospectives à distance

Dans l’étape 1, vous pourrez renseigner les objectifs de l’atelier (dans notre cas une rétrospective) (1) et mettre une image d’arrière-plan (2).

L’arrière-plan est très pratique pour mettre une image qui ne pourra pas être déplacée et sur laquelle on pourra coller des post-its (par exemple un speed boat).

blog ai3 5 Utiliser Klaxoon pour nos rétrospectives à distance

En étape 2, vous pouvez sélectionner le Mode (3), c’est-à-dire si l’animateur contrôle l’intégralité du board ou si les participants sont libres d’interagir avec (post-its, déplacements etc…).  Dans le cadre d’une rétrospective, il vaut mieux mettre le mode libre ;).

En étape 3, Vous pouvez activer des catégories (4) (pas de panique, c’est également configurable une fois le board initié dans les options).

Les catégories peuvent vous permettre par exemple de choisir des types de Post-its (technique, équipe, métier…).

blog ai3 6 Utiliser Klaxoon pour nos rétrospectives à distance

Et enfin en étape 4, vous pouvez activer des dimensions (5). Les dimensions servent à ajouter des informations sur les post-its comme par exemple le nom du créateur.

blog ai3 11 Utiliser Klaxoon pour nos rétrospectives à distance

Voici l’exemple d’un post-it avec une catégorie et une dimension paramétrables par les participants.

Une fois tout paramétré, vous pouvez lancer et choisir l’option « Avec un code d’accès ». Il sera ensuite demandé si les participants se connecteront via un email ou un pseudonyme, je préconise le pseudonyme.

Etape 3 : Préparer votre rétrospective

Une bonne rétrospective doit bien évidemment être préparée en amont.

Voici un petit rappel des étapes qui la composent : https://blog.ai3.fr/agilite-les-retrospectives/.

Vous pouvez donc découper vos étapes par des blocs en utilisant les formes géométriques mises à disposition ainsi que les zones de texte.

blog ai3 9 Utiliser Klaxoon pour nos rétrospectives à distance

N’oubliez pas d’ajouter les objectifs du Sprint.

blog ai3 10 Utiliser Klaxoon pour nos rétrospectives à distance

Vous pouvez également ajouter des pastilles de couleurs (forme géométrique rond) afin de procéder au Dot Voting par la suite.

blog ai3 13 Utiliser Klaxoon pour nos rétrospectives à distance

Vous pouvez également ajouter une légende quant à la rétrospective en elle-même afin de guider les participants.

blog ai3 14 Utiliser Klaxoon pour nos rétrospectives à distance

Pour rappel, vous pouvez revenir sur n’importe quel paramétrage (couleurs de post-its, catégories, dimensions …) en cliquant sur le bouton « Options ».

blog ai3 15 Utiliser Klaxoon pour nos rétrospectives à distance

Etape 4 : Partager aux participants

Afin que l’équipe puisse participer à votre atelier, il faut qu’ils aient le lien pour s’y connecter. Pour se faire, il suffit de cliquer sur le code du board en bas à gauche de l’écran et de donner le lien copié dans la fenêtre.

blog ai3 7 Utiliser Klaxoon pour nos rétrospectives à distance

Lors de leur arrivée sur le board, leur pseudonyme leur sera demandé et ils auront un récapitulatif des paramétrages de celui-ci.

blog ai3 8 Utiliser Klaxoon pour nos rétrospectives à distance

Préconisations

Attention, tout atelier se faisant à distance ne doit pas s’éterniser. Vous ne pouvez pas garantir que chaque participant ait son attention entière sur la rétro (une petite pensée pour les développeurs qui ont leur code ouvert à côté pour continuer à avancer ;)).

Mes conseils :

  • Pas plus d’1h00 voir 1h30 grand max
  • Dynamisez la réunion avec de l’humour, de la prise de parole des autres participants etc
  • Changez toujours vos types de rétrospectives pour donner du neuf et de l’engouement

Exemples de rétrospectives faisables à distance

Ice Breaker

Rétrospective

Check Out

RÉTROSPECTIVE AGILE #3 – Montgolfière

La rétrospective de la montgolfière peut un peut faire penser à celle du Speed Boat. Elle permet d’identifier les éléments qui ont poussé l’équipe vers l’accomplissement des objectifs du sprint et ceux qui l’ont, au contraire ralentis.

blog ai3 retro-2-1024x768 RÉTROSPECTIVE AGILE #3 - Montgolfière

Mise en place

  • Grande feuille ou board sur laquelle le facilitateur aura dessiné une montgolfière avec des poids, un soleil à gauche et un nuage qui souffle à droite.
  • Stylos
  • Post-its

Déroulé

1 – Chaque participant devra remplir des post-its selon deux axes :

  • Ce qui a élevé l’équipe ?(ils devront les positionner en étape 2 sur le ballon)
  • Ce qui tire l’équipe vers le bas ? (ils devront les positionner en étape 2 sur les poids)

2 – Une fois que chacun a trouvé ses idées, il les pose sur le dessin au bon endroit en expliquant ces choix.

3 – Les participants vont devoir remplir de nouveaux post-its sur les thèmes suivant :

  • Quelles sont les turbulences à venir ?(ils devront les positionner en étape 4 sur le nuage)
  • Que peut faire l’équipe pour surmonter ces turbulences ? (ils devront les positionner en étape 4 sur le soleil)

4 – Une fois que chacun a trouvé ses idées, il les pose sur le dessin au bon endroit en expliquant ces choix.

5 – L’équipe fait ensuite le point sur la situation en regroupant les post-its et en proposant des actions d’amélioration à effectuer pour le prochain sprint.

6 – Un vote est fait pour cibler quelques actions dans le lot

Avantages

  • Ludique et change du Speed-bot classique
  • Très simple à comprendre
  • L’idée de séparer la réflexion en deux phases (d’abord le passé puis le futur) permet d’avoir une recherche plus ciblée et aide à trouver des éléments plus facilement

Inconvénients

  • Reste tout de même assez basique

RÉTROSPECTIVE AGILE #2 – DIXIT

blog ai3 dixit_0-1024x279 RÉTROSPECTIVE AGILE #2 – DIXIT

Le déroulé d’une rétrospective étant de générer des idées de façon ludique, quoi que de mieux qu’un jeu de société pour y parvenir ?

Le jeu de société Dixit fait travailler notre imagination de par ses cartes  fantaisistes et nous allons nous en servir pour faire travailler la créativité de notre équipe !

Mise en place

Le Scrum Master devra se procurer une boite de jeu Dixit (ou alors  une extension ne contenant que des cartes) et disposer celles-ci sur une table, faces visibles.

Déroulé

1 – Chaque participant choisit 3 cartes (une à la fois, chacun son tour) sans donner d’explications. Mais celle-ci doit lui faire penser à quelque chose de négatif ou positif durant le Sprint passé.

2 – Chacun son tour, les participants vont alors montrer une des cartes choisies sans dire un mot.

3 – Le reste de l’équipe va ensuite essayer de deviner les raisons de son choix

4 – Si personne ne trouve au bout d’environ 30s, il donnera son explication

5 – Le facilitateur note alors au tableaux les points qui ressortent aussi bien au niveau de la véritable raison des prises de cartes que ceux sorties par déduction.

6 – On réitère sur un deuxième voir troisième par participants si besoin (si le nombre d’idées ressorties n’est pas encore assez conséquent

7 – L’équipe va ensuite regrouper les points cités qui vont ensemble et définir des actions d’amélioration pour le prochain Sprint

8 – Un vote est fait pour cibler quelques actions dans le lot

Avantages

  • Très ludique, les cartes sont très drôles et mettent à l’aise
  • Le côté abstrait des cartes permet souvent de faire émerger des choses auxquelles ont aurait pas forcément pensé

Inconvénients

  • Ce fameux côté abstrait peut en perdre quelques un en route qui n’arriveront pas à trouver de similitudes entre les faits passés et les images

Variante possible

Plutôt que de laisser choisir 3 cartes à chaque personne on peut plus cibler l’exercice en demandant spécifiquement de prendre une carte sur un fait positif passé, une sur un fait négatif et une sur une amélioration possible.

 Chacun  serait donc plus « guidé ».

Agilité : les rétrospectives

La rétrospective est une des cérémonies utilisées en Agilité (notamment dans le FrameWork SCRUM) basée sur l’amélioration continue.

Durant cet atelier, l’équipe fait le point sur ce qui a été positif ou négatif dans le sprint passé afin d’en retirer des actions d’améliorations à mettre en place pour la prochaine rétrospective.

Découpage de la rétrospective

Chaque rétrospective doit se découper en 5 phases :

1 – Ice Breaker : 5/10 min 

Très fun, pour mettre à l’aise les participants, les couper de ce qu’ils faisaient avant et leur permettre de se libérer pour communiquer pendant les autres phases.

Si nous ne sommes pas sur la première rétrospective, on fait le point sur les actions de la précédente.

2 – Recueillir les données : environ 5/10 min

On récupère autant d’informations que possible sur le Sprint passé. Durant cette phase, en général, chacun va poser ses idées sur un post-its avant de les présenter dans la phase 3.

3 – Stimuler de nouvelles idées : environ 10/20 min

Chacun présente ses post-its, on regroupe les doublons et on met l’accent sur ceux qui sont plus sensibles à analyser.

4 – Décider quoi faire : environ 10/15 min

On établir à partir des informations récupérées des actions d’améliorations ainsi que des responsables pour chacun.

Attention, mieux vaut se concentrer sur 2 ou 3 actions à entreprendre pour le prochain Sprint et  qui seront faites plutôt que plus qui ne le seront pas.

Privilégiez un vote pour le choix final.

5 – Check out : 5/10 min

On finit sur une note positive et on récupère les impressions sur la rétrospective.

Le Scrum master et la rétrospective

Attention chers Scrum Masters, votre rôle est de faire en sorte de faciliter l’atelier. Vous devez faire en sorte que tout le monde participe et les laisser s’exprimer et non effectuer le travail à leur place ;).

Une rétrospective dure environ 45 min par semaine de Sprint et nécessite un temps de préparation assez conséquent (environ une demi-journée à une journée).

L’important étant de toujours varier les styles de rétrospectives afin de ne pas ennuyer la Team et faire en sorte que l’engouement soit toujours présent à chaque fois.

Si l’ambiance est au rendez-vous, les membres de l’équipe auront plus tendances à dire ce qu’ils ont sur le cœur ;).

Rétrospective à distance

Le plus simple étant que la rétrospective se fasse en physique (Klaxoon par exemple) mais il arrive que les équipes ne puissent pas se regrouper.

Il existe plusieurs outils permettant de faire des rétrospectives en ligne. Ils se basent généralement sur le fait que le Scrum Master puisse dessiner ce qu’il veut (exemple un speed boat) et que chacun puisse affecter des Post-its virtuels à ce dessin.

Quelques liens utiles

Ice Breakers : https://blog.myagilepartner.fr/index.php/ice-breaker/

Rétrospectives : https://blog.myagilepartner.fr/index.php/fun-retrospective-agile/

Checkout : https://blog.myagilepartner.fr/index.php/check-out-check-in-agile/

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.