Scrum poster

Il existe des tonnes d’illustrations de Scrum sur internet, très bien réalisées.

Mais parce que je préfère utiliser mes supports que des images dont je ne suis pas sûre de pouvoir citer correctement les sources, j’ai eu envie de faire une version perso…

N’hésitez pas à la réutiliser, j’ai mis un tout petit @elodescharmes en bas à droite et ça me suffit largement comme « copyright » 🙂

Scrum

Toute remarque sur le contenu est également la bienvenue, je pourrai faire des mises à jour si nécessaire.

Télécharger la version pdf

Et quand personne n’a envie d’être ScrumMaster ?

Vous avez peut-être déjà été confronté à cette situation… De ma courte expérience de coaching agile j’ai l’impression que ça peut arriver assez souvent finalement.

Vous avez une bonne équipe, tous les « team members » (au sens de Scrum, toutes spécialités confondues) sont compétents et motivés… Et personne n’a envie d’être le Scrum Master.

Bien sûr tout ça dépend du contexte, mais j’ai l’impression que les causes sont souvent un peu les mêmes :

  • Le rôle n’intéresse pas : quand ma passion c’est le dev, le design, l’ergonomie… je veux avant tout faire, pas être en support
  • Le rôle paraît rébarbatif : trop souvent on confond « être au service de l’équipe » avec « faire tout ce que les autres n’ont pas envie de faire et qu’il faut faire quand même ».
  • Le rôle n’est pas reconnu dans l’entreprise : méconnu, pas valorisé, voire même complètement ignoré

Romain Couturier explique ça très bien dans sa conférence « Qu’est-ce qu’un ScrumMaster » : quand Scrum arrive dans l’entreprise, il est logique de se demander comment s’en sortir avec ces nouveaux rôles et l’organisation existante.

  • Team Members, c’est facile
  • Product Owner… entre responsable produit, chef de projet, marketing, c’est pas super simple mais on devrait quand même arriver à trouver quelqu’un pour ce rôle (et souvent on se plante, mais je ferais peut-être un autre article à ce sujet ^^)
  • Mais Scrum Master ? Qui est-ce que ça peut bien être ? C’est complètement nouveau.

Ce n’est pas une fonction de production, ni une fonction décisionnaire. C’est une plutôt une fonction support. On pourrait penser aux managers, mais le changement de posture est tellement radical que j’ai du mal à l’envisager (et même avec un manager qui renonce complètement à tout pouvoir et tout contrôle sur l’équipe, encore faut-il que TOUS les membres de l’équipe le perçoivent ainsi… car les relations c’est dans les deux sens !).

Alors du coup on se retrouve avec des Scrum Masters tournants. Personnellement je n’aime pas vraiment cette pratique, tout simplement parce que se passer la patate chaude ça n’aide pas à monter en compétence sur le rôle et donc à avoir de bons Scrum Master. Forcément, quand on n’a pas envie et qu’en plus on a autre chose à faire…

Et quand ça va mal parce que on n’a pas investit le temps l’énergie et la compétence dans ce rôle, on appelle un coach agile 🙂

L’équipe en a marre. Personne ne voulait faire Scrum Master, un rôle tournant a été mis en place (par exemple), mais ça se passe mal, il y a de plus en plus de tensions, et du coup plus personne ne veut être Scrum Master.

Ce n’est qu’une proposition, mais voilà ce que j’ai tenté et qui s’est bien passé dans ce type de situation.

On suppose que l’équipe veut continuer à travailler en Scrum, ce qui dans les situations auxquelles je pense était le cas.

1. Recadrer Scrum

C’est souvent l’urgence. Alors oui, ce n’est pas du coaching agile et c’est plutôt prendre temporairement (et malheureusement partiellement si je ne suis pas à temps plein dans l’équipe) le rôle de Scrum Master.

Mais pour désamorcer les tensions, je pense qu’il faut souvent passer par là : re-clarifier les rôles, redonner du sens aux cérémonies…

2. Animer une décision collective par consentement sur un mode de fonctionnement autonome pour la suite

Ça doit être clair dès le début : en tant que coach agile, je ne resterai pas dans l’équipe, mon premier objectif est qu’on n’ait plus besoin de moi ! Je ne peux donc pas rester en tant que Scrum Master, mais je peux les aider à trouver un mode de fonctionnement autonome.

Pour cela, quand Scrum a été recadré et les tensions liées à ce rôle désamorcées, je leur propose un atelier spécifique.

Déjà, on clarifie les attentes de l’équipe vis à vis du rôle de Scrum Master.
En mode brainstorming, chacun note sur de post-its ses attentes. Pour le regroupement, j’utilise ce type de paperboard :

20171012_163502

Remarque : la première fois que je l’ai animé, je n’avais que l’axe vertical sur la criticité du besoin. Mais j’ai eu des attentes qui ne faisaient pas vraiment partie du rôle de Scrum Master… du coup je pose maintenant deux questions à l’équipe :

  • Est-ce que cette activité fait vraiment partie du rôle de Scrum Master ? (et j’en profite pour rappeler un peu ce qu’est le rôle, vis à vis de l’équipe de réalisation, du PO, et de l’organisation)
  • A quel point est-ce que vous en avez besoin ?

Une fois ce paperboard réalisé, je le laisse de côté pour le moment. Il a servi à aligner les membres de l’équipe sur leurs attentes, mais on devra peut-être y revenir…

Ensuite, je leur demande de lister les différentes possibilités d’organisation. J’avoue que là je les aide un peu avec ce que j’ai pu observer dans d’autres équipes. En gros ça donne :

  • Une personne de l’équipe prend le rôle –> –> je précise tout de suite que si cette option est sélectionnée, on continuera avec une élection sans candidats
  • Rôle tournant
  • L’équipe recrute un Scrum Master (si c’est envisageable)
  • L’équipe se réparti les tâches du Scrum Master
  • L’équipe fait appel ponctuellement à un facilitateur pour l’animation des rétros, mais se réparti les autres tâches

Ensuite, j’anime une prise de décision collective par consentement, on retient l’option pour laquelle il reste le moins d’objections (sachant bien sûr que j’insiste sur le côté expérimental, quelle que soit la décision prise il faudra en discuter aux prochaines rétros pour la valider ou non).

Dans le cas où l’équipe se réparti les tâches (dernière et avant-dernière option), on reprend alors le paperboard précédent pour décider de qui fait quoi.

Au final, je ne l’aurais pas cru au premier abord, mais cette option de se répartir les tâches a l’air de plutôt bien fonctionner…  Je pense qu’il y a trois raisons à ça :

  • ça limite la charge de travail : on peut prendre la tâche de l’animation des rétros uniquement par exemple et se concentrer la plus grande partie de son temps sur son rôle de Team Member ou Product Owner
  • c’est issu d’une réflexion collective et chacun a eu l’occasion de se positionner sur les tâches qui lui plaisaient le plus
  • ça permet quand même la montée en compétence, même partielle : celui ou celle qui a pris l’animation du sprint planning par exemple va être de plus en plus à l’aise d’itération en itération dans ce rôle. Et c’est pareil pour tous les autres rôles (animation, organisation logistique des cérémonies, gardien des règles Scrum et des valeurs agiles… c’est en général ce type de tâches qui ressortent)

Pour moi c’est une vraie surprise mais pour les deux équipes que je connais et qui ont choisi cette option ça a l’air de leur convenir et de bien fonctionner… alors pourquoi pas !

Et vous, comment gérez-vous cette situation ?

Estimations

Les estimations agiles

Déjà, pourquoi ne pas estimer en hommes*jour ?… PARCE QUE !!!
Allez, on lit cet excellent article, et on passe à la suite 🙂 : La malédiction du jour homme

Bon. maintenant que ça c’est fait, du coup, comment on fait des estimations agiles ?

En général dans les équipes agiles on a besoin d’estimer deux choses :

  • la valeur business d’un item
  • la complexité technique d’un item

La priorité d’un item est déduite de ces deux estimations.

NB : Je vois souvent la notion de priorité confondue avec la notion de valeur business (j’ai entendu « priorité business »). Pour moi ce n’est pas une bonne pratique et c’est symptomatique d’un product owner qui priorise son backlog seul (sans impliquer l’équipe de réalisation). Bref. Fin de la disgression.

On veut des estimations simples, rapides, relatives.

fichier_0021.png

Si je prends la pomme dans une main, ce serait compliqué d’estimer combien de grammes elle pèse. Même chose pour l’orange. Mais si je prends la pomme dans une main et l’orange dans l’autre, c’est assez facile de dire laquelle est la plus lourde… Et c’est tout ce que j’ai besoin de savoir pour prioriser !

J’ai essayé de lister ici différentes techniques… Est-ce que vous en connaissez d’autres ?

T-shirt sizes

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur. Mais concrètement je ne l’ai utilisé que pour les complexités techniques.

C’est très simple, très connu. Concrètement pendant un workshop je divise un paperboard en 6 parties.

  • XS
  • X
  • M
  • L
  • XL
  • NSP

Point de vigilance : essayer d’avoir une vraie répartition des items, pas tout en M…

Estimation line

Cette technique peut être utilisé pour les estimations de complexité comme pour les estimations de valeur (et je l’ai déjà utilisée dans les deux cas ^^).

Sur une grande table ou sur un mur : demander aux participants de simplement classer les items (epics / features / user stories) du plus simple au plus complexe (ou du moins de valeur au plus de valeur).

Interdit d’en mettre deux au même niveau ! (vous allez voir, c’est toujours difficile ^^)

On se met ensuite d’accord sur où placer les limites entre des groupes d’items et on fait la correspondance avec Fibonacci (ou des T-shirt size). Et hop, emballé c’est pesé, voilà une manière très rapide d’estimer 🙂

2017-10-29 13_45_10-IMG_0101.PNG ‎- Photos.png

Buy a feature

Cet atelier peut permettre d’estimer rapidement la valeur business des features.

Pour le détail du déroulé : GIYF 🙂
… Notamment cet article avec plein de déclinaisons possibles de l’atelier : http://blog.xebia.fr/2014/08/20/les-differents-usages-de-buy-a-feature/

Quand on utilise une atelier « buy a feature » pour estimer des valeurs business, la question à poser aux participants est : « Imaginez que vous êtes tel ou tel client. Combien seriez-vous payer pour avoir cette fonctionnalité ? »

C’est mieux si on a fait des personae avant, on peut demander aux participants d’essayer de les incarner lors de cet atelier.

Complexity / value matrix

Si on veut aller encore plus vite sur les estimations (en comme il ne s’agit pas d’une session de backlog grooming mais bien d’un workshop d’initialisation, je pense que c’est tout à fait acceptable), on peut utiliser une matrice complexité / valeur.
Personnellement, je trouve cet atelier très efficace et je crois que c’est l’option que je retiens le plus souvent.

Pour le détail du déroulé : GIYF 🙂

Quand je l’anime, je suis assez stricte sur les règles :

  • d’abord le PO (ou équivalent) présente l’item
  • ensuite le PO, représentant marketing ou représentants clients  (premier groupe) le placent en hauteur dans la matrice
  • ensuite l’équipe de réalisation (deuxième groupe) le placent à gauche ou à droite.
  • s’il y a discussion / débat, j’ai toujours ces deux règles :
    • le premier groupe ne peut déplacer les post-its que verticalement
    • le deuxième groupe ne peut déplacer les post-its que horizontalement

Fichier_002 (4).png

Planning poker

Bien sûr, il y a le classique planning poker. Il peut être utilisé pour tous type d’estimations, complexité technique, valeur business…

Pour le détail du déroulé : GIYF 🙂

Il se différencie des techniques ci-dessus car il est plus long, amène des discussion et des débats beaucoup plus riches. De ce fait, je préfère ne pas l’utiliser à l’initialisation d’un backlog (quand on a vraiment beaucoup d’items à estimer), mais plutôt en backlog grooming quand il y a peu d’estimations à faire et qu’on veut aller plus dans le détail. En général on a estimé et priorisé le backlog grosse maille avec les autres techniques, et on « n’investit » dans un planning poker que pour les user stories complexes (on a besoin de discuter pour aligner nos vision sur le quoi et le comment), et/ou les user stories très court terme (pour le(s) prochain(s) sprint(s)).

Conseil : prévoir de quoi noter les choix techniques ou les précisions fonctionnelles qui émergent des discussions sur planning poker.

Point de vigilance : le planning poker implique une obligation de converger vers une estimation unique. Ne pas oublier le risque d’incertitude (notamment quand il y a divergence importante entre les estimations initiales).

Lean Kanban France 2017, mes notes et quelques photos

It was my first visit to Lean Kanban event. Great experience! Here are some photos and quotes I want to remember…

Nota Bene: most of the conferences I chose were in english, then most my notes are in english, then most of this post is in english. But not all, it’s a mix because I hate to translate. Sorry about that!

Beating Uncertaincy (Adam Wu)

We live in an uncertain world… yet we hate uncertainty.
We want to remain uncertain about our engagement… yet we want others to be certain to us.

Management by certainty thinking: “no defect!” can work for complicated systems… for a while. But it leads to always more control, policies… that drags down the lead time! Certainty thinking is not adapted to complex systems.

We need to manage uncertainty at the organization level. Organize teams matching you value stream(s).

Goal communication more than goal assignment.

Lead time is a good KPI for leaders. Make them shift their focus: make leaders focus about the flow efficiency!

Quelques photos :

Ce diaporama nécessite JavaScript.

Design sprints at scale (Tomomi Sasaki)

Mind-blowing design sprints: key factors for success, joy and happiness

  • Cross-discipline
  • No hierarchy
  • Vision
  • Everybody sketches
  • Safe space
  • Decisions are made in the room
  • Designed experience (workshop <> meeting)

Design sprint examples and feedbacks? Go to https://sprintstories.com/ !

At scale, some things can be stretched, some others cannot, it would break the experience. Back to the WHY of design sprints, not mimicking a methodology!

Tips for bi-language design sprints:

  • Co-facilitators
  • Instructions in both languages
  • Lead with English (or the language everyone understands)
  • Diverge (have subgroup workshops) in mother tongue
  • Converge (share results) in common language

“At scale” example: 70 participants, 6 sprint masters, several month of planning!

When do we sprint?

  • Product discovery
  • Big challenges
  • Create a momentum

Best quote of the day :

20171130_135854.jpg

Kanban Metrics (Stéphane Wojewoda)

Key metrics:

  • Cumulated Flow Diagram
  • Number of items blocked
  • Cycle time

CFD valuable uses cases examples:

  • Estimate end date
  • Value in stock à cost of delay

Essential prerequisite: STABLE TEAM!!!

Ce diaporama nécessite JavaScript.

C’est quoi la data ? (Adrien Gardou, Léo Beaucourt)

3 définitions possibles et complémentaires d’un projet Big Data :

  • 3V
    • Volume (quantité d’objets à traiter, ce n’est pas une question d’espace disque !)
    • Vélocité (afficher l’information avant qu’une nouvelle vague de données arrive)
    • Variété
  • La complexité des données traitées dépassent l’entendement humain
  • Processus de création d’information / valeur à partir des données disponibles

20171130_091949.jpg

Modèles mentaux (Thierry Montulé)

Référence : “La Cinquième Discipline” de Peter Senge

Disciplines / conditions pour devenir une organization apprenante

  • Partager la vision
  • Personal Mastery
    • Clarifier ce qui est important pour moi
    • Créer une image du futur anticipé
    • Apprendre à voir la réalité plus clairement
    • S’engager sur la vérité
  • Team learning
    • Workshops, rétrospectives…
  • System Thinking
    • Passer de « C’est la faute du système » à « tout le monde fait partie du système »
  • Modèles mentaux
    • Gérer, manager ma manière de percevoir le monde, d’interagir avec les autres, de prendre des décisions. C’est ce qui conditionne notre réalité.
    • Prendre conscience des biais de perception : pré-supposés, généralisations, simplifications, raccourcis, sélection d’informations, représentation partielle, confirmation (l’équilibre que nous construisons va en permanence s’auto-valider)

Les problèmes d’aujourd’hui sont les solutions d’hier.

Nos organisations sont le produit de notre pensée et de nos interactions. Il faut travailler sur les modèles mentaux d’entreprise. Quand on balaye un escalier en commence par le haut.

Le bingo des « killer phrases » :

20171129_143010.jpg

Complexitools (Niels Pflaeging)

Funny game about McGregor’s theory X/Y

  • Everyone has two post-its (yellow and blue for example)
  • On the yellow post-it write X or Y whenever you think you are
  • Shuffle yellow post-its within the audience
  • On the blue post-it, write the % of X persons in your organization (guestimation)
  • Shuffle blue post-its within the audience
  • Look at the post-its you have (everybody should have a yellow and a blue)
  • Rise yellow post-its with X
  • Rise blue post-its with 0% (or less than 10%)
  • What do you think?

Theory X people don’t exist. Everyone is Y, but some behave like X. Why? Because of the system they’re in. When there is a problem, we tend to look for someone to blame, but 95% of the time it’s a system problem.

20171129_121434.jpg

Swearing, nudity and other vulnerable positions (John Le Drew)

If I had to choose only one conference for the whole event, it would be this one.
John Le Drew (@antz29) is a wonderful speaker, and his experience on this subject is amazing.

Here are some insights :

Psychological safety definition proposition :

20171129_111754.jpg

See Google’s Five dynamics of team effectiveness

Screen-Shot-2016-07-07-at-10.39.31-AM.png

Psychological safety is related to our fear to be perceived negatively:

  • About our competence
  • About our situation awareness
  • About our attitude (fear to be told we are negative)

In organizations, some people can be “energy black holes”. They have been confronted with an unsafe environment and they decided to stay… and now they REALLY stay!

About remote teams:

  • Good news, you work with humans, they are creative, they can adapt
  • Bad news, you work with humans, they need to connect !

We cannot punish a mistake (no one decides to do a mistake), we only punish the initiative to try / do something.

Tip about pair programming :

  • Pairing an introvert + introvert is fine
  • Pairing an introvert + extravert can is fine too
  • Pairing extravert + extravert can be… at least difficult!

In problem solving meeting, we should have an “improvisation theater” mindset. The icebreaker “storyline” can help.

  • One person starts a story (one sentence) and places himself at the beginning of the line
  • Another person ends the story (one sentence) and places himself at the end of the line. The story ending may have no connection at all with the beginning
  • One by one, the other participants will complete the story (chronological order) and the physical line, one sentence each. The idea is to reach the pre-defined end!

Curiosity over judgement. Entering into judgement negates the ability to connect.

In stress casing causing low engagement, or low engagement causing stress?

Psychological safety is #1 indicator of effective teams!

Acculturation agile, une mini formation-atelier en 2h

Voici un exemple d’atelier d’acculturation à l’agilité réalisé en temps très contraint… 2h uniquement !

Qu’en pensez-vous ? N’hésitez pas à me faire des commentaires, et surtout n’hésitez pas à vous en inspirer si vous pensez que ce type de déroulé peut vous être utile dans votre contexte 🙂

La demande

  • Objectif : acculturation de l’agilité, si possible avec de la mise en pratique
  • Participants : managers
  • Logistique : 2h, 2 salles côte à côte (pour l’atelier)

Déroulé

IMG_0114.JPG

Au début, collecte des attentes (espace ATTENTES sur le paperboard). A la fin de chaque partie, point rapide sur les attentes (on passe en DONE celles qui sont remplies, éventuellement on ajoute les attentes correspondant à de nouveaux questionnements).

Contenu théorique

  • Agilité, les bases
    • Valeurs
    • Principes
    • Démarche empirique
    • Equipes agiles
    • Boucles de feedback
    • Rythme
    • Vision
    • Amélioration continue
    • Management visuel
  • Scrum
    • Rôles
    • Cérémonies
    • Artefacts

Atelier : lego copycats

 

 

Feedbacks

Un moment instructif et fun tout à la fois 🙂

Vous nous avez donné la chance de pouvoir commencer à aller derrière les mots valise et appréhender la richesse de ces modes d’interaction.
Let’s move on !

 

Changement de paradigme : du déterminisme à l’empirisme, pourquoi la pilule rouge de doit pas nous empêcher de continuer à utiliser la matrice

« C’est quoi l’agilité ? » Je pense que nous avons tous un peu notre réponse à cette question. Pour ma part, je concentre ma réponse autour de 2 points :

  • Ce sont des valeurs et des principes, RTFM (Read The Fucking Manifesto ^^)
  • C’est un changement de paradigme, du déterminisme à l’empirisme

Pour présenter les valeurs et les principes c’est facile. J’utilise le manifeste agile bien sûr, j’essaye de donner au moins un exemple concret par valeur, et aussi par principe si j’ai un peu de temps.

C’est un peu moins « prémâché » pour présenter le changement de paradigme. Et souvent, j’ai cette question : « Mais si on adopte une approche empirique, ça veut dire qu’on ne planifie et qu’on n’anticipe plus rien ? C’est l’anarchie ? »
Non. Je pense que c’est beaucoup plus complexe que ça.

Je soumets donc cette petite réflexion sur le sujet à l’intelligence collective pour avoir votre feedback et si possible tenter de l’améliorer !

Introduction

En « mode waterfall / cycle en V », dans un monde déterministe, nous essayions d’accumuler des connaissances pour prévoir l’avenir (planification des projets), avant de nous lancer dans la réalisation.

En « mode agile », dans un monde empirique, nous commençons par expérimenter, faire, réaliser, et c’est ainsi que nous gagnons les connaissances. Ces connaissance sont à la fois les connaissances liées au produit (nous le découvrons et l’adaptons au fur et à mesure en fonction des feedbacks clients), et les connaissances liées à l’équipe (dont notre capacité à produire).

Support visuel et discours associé

Je représente ça en général grâces aux triangles (scope-time-cost) que les managers de projet/produit connaissent bien.

Fichier_002

Le discours associé à cette illustration :

Triangle de gauche :

En management de projet/produit classique, nous passons beaucoup de temps à essayer de déterminer très précisément le scope, ce afin d’en déduire un time (planning) et un cost (budget) précis et le plus fiable possible.
Nous commençons ensuite la réalisation. Et tout se passerait bien s’il n’y avait aucun changement, aucun risque, aucune incertitude sur le produit à réaliser, ni aucune incertitude sur la capacité de l’équipe à le produire. C’est impossible, à moins d’être dans une bulle étanche, d’avoir fait le produit une première fois pour être sûr que c’est le bon, et d’avoir des robots à la place d’humains dans les équipes… et encore !
Il y a donc des changements par rapport à ce qui a été planifié. C’est inévitable. Ces changements vont impacter les dimensions scope time et cost, et donc notre planification. Mais quand les trois dimensions sont fixées, par un contrat par exemple, ou par un engagement pris en comité de jalon ou de pilotage… comment faire ? Il reste une dimension dont nous n’avons pas parlé. La qualité. Et malheureusement… c’est souvent la qualité qui est impactée dans les projets « waterfall » quand une équipe est obligée de faire face à un changement tout en étant pieds et poings liés dans ce triangle figé.
Bien sûr ce n’est pas du management de projet « correct ». Il existe le mécanisme des « changes requests » et je suis convaincue que le rôle d’un bon project manager n’est pas de préserver coûte que coûte la planification, mais bien de gérer ces « change requests » de manière à faire évoluer le triangle scope-time-cost tout en le gardant sous contrôle. Mais cette « théorie » est peu compatible avec notre culture réfractaire au risque et qui cherche à tout prix l’engagement ferme et définitif (oh combien illusoire) pour se rassurer (à ce sujet, je renvoie à la théorie des dimensions culturelles de Geert Hofstede, c’est passionnant)… et parfois tout simplement inapplicable de par la dérive administrative qu’elle engendre face à des changements trop fréquents.
Bref. Ce n’est pas simple.

Triangle de droite :

En mode agile maintenant. Nous commençons par définir une vision. Une vision ce ne sont pas du tout des spécifications ! C’est ce que l’on a au lancement du projet/produit comme idée de ce que l’on veut réaliser. Elle peut se limiter à un elevator pitch par exemple.
Ensuite, on fixe les dimensions time et cost. C’est « facile » : pour quand voulons-nous une première version de notre produit, combien d’argent sommes-nous prêts à investir au regard de sa proposition de valeur (qui doit être claire dans la vision) ?
A partir de là, on commence à réaliser. Et pendant toute la réalisation, notre variable d’ajustement sera la dimension scope par les mécanismes de gestion du product backlog, alimenté par les boucles de feedback.
La contrepartie à cette flexibilité sur le scope est la rigueur sur la qualité : la qualité n’est plus une variable d’ajustement.
Cela signifie aussi avoir le courage d’arrêter un projet/produit si nous découvrons (toujours par les boucles de feedback) que nous faisons fausse route… Notion de droit à l’erreur etc etc.
Bref… ce n’est pas simple non plus !!! Mais peut-être plus adapté pour certains projets/produits et dans tous les cas plus réaliste et transparent. Nous reconnaissons les incertitudes, regardons les risques en face et c’est la seule manière de s’ouvrir également aux opportunités (la version « positive » des risques) .

Insister sur la bascule

Ce n’est pas qu’un nouveau process, une nouvelle manière de gérer les projets. Et c’est pour ça que passer d’un processus jalonnés à l’application de Scrum ne suffit pas à être agile. Découper des spécifications détaillées pour les donner bouchée par bouchée à l’équipe au fur et à mesure des itérations tout en vérifiant qu’on respecte bien les engagements scope-time-cost, ce n’est pas être agile !

Passer d’un mode déterministe à un mode empirique, c’est un vrai changement culturel. Philosophique.

Petit tour sur la page wikipédia « Empirisme » :

L’empirisme désigne un ensemble de théories philosophiques qui font de l’expérience sensible l’origine de toute connaissance ou croyance et de tout plaisir esthétique. L’empirisme s’oppose en particulier à l’innéisme et plus généralement au rationalisme « nativiste » pour lesquels nous disposerions de connaissances, idées ou principes avant toute expérience.

… Et il peut être aussi difficile de « passer de l’autre côté » que de faire marche arrière.

pill

This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.

[Morpheus, Matrix]

Mixer les deux approches ?

Si ce changement de paradigme est une bascule, est-ce qu’il est possible d’avoir une approche « mixte » ?

Je pense que oui. En fait, je pense qu’il faut trouver le bon compromis entre le 100% déterministe qui paralyse (je veux absolument tout prévoir avant de faire le premier pas) et le 100% empirique qui peut être anxiogène (essayez de marchez les yeux bandés sans avoir préalablement visualisé votre parcours…)

Pour faire le lien avec les techniques de management de projet/produit, je rapproche ça du management des risques/opportunités : il faut trouver le bon compromis car sans prise de risque, rien de nouveau et un bon management des risques ne veut pas dire chercher à les éviter à tout prix !

Je pense que ce compromis dépend : du produit, de l’équipe, du contexte, et de la phase dans laquelle nous sommes.

Rapport aux méthodes (en tout cas celles que je connais un peu ^^)

  • Scrum est une proposition qui fait un compromis entre empirisme et déterminisme. L’approche est globalement empirique à l’échelle du développement du produit, mais les sprints sont déterministes.
  • XP serait un peu plus empirique que Scrum (itérations plus courtes, possibilité de prendre en compte des changements pendant les itérations).
  • Kanban (et le mode flux continu vs. itérations) serait le plus empirique

PS : un jour il faudra que je fasse un retour d’expérience complet sur un de mes anciens projets pour lequel nous avons fait la première release en mode « classique jalonné », la deuxième en Scrum et la troisième en Kanban…

Quand j’entends parler de mode « hybride », j’ai l’impression que l’on cherche une autre proposition de framework entre le « mode classique » et Scrum, donc a priori plus déterministe que Scrum mais en pouvant intégrer du changement en cours de réalisation… pourquoi pas.

Première valeur agile :

Les individus et leurs interactions plus que les processus et les outils

Nous devons adapter les process et des outils, du moment que c’est fait pour de bonnes raisons et en connaissance de cause (petit lien vers l’excellentissime conférence de Claude Aubry « Scrum ? mon scrotum ! » sur les dérives de Scrum, dont l’adaptation du process pour de mauvaises raisons (genre : « nan, mais on a arrêté les daily… trop contraignant… et puis l’agilité c’est d’adapter les process, non ? »).

Alors adaptons-nous (et faisons-le correctement) et trouvons le bon compromis entre empirisme et déterminisme en fonction du produit, de l’équipe, du contexte, du moment.

Nous avons pris conscience que notre ancien monde de prévisions et d’engagements n’est qu’une matrice fictive dans laquelle nous nous réfugions par peur du changement, des risques et de l’échec. Nous avons pris la pilule rouge, suivi le lapin blanc dans la réalité, le concret, l’expérimentation.
Et pourtant, ne nous interdisons pas d’utiliser les possibilités de la matrice quand celles-ci peuvent nous servir !

07202682-photo-matrix.jpg

La prise de conscience est indispensable et irréversible. Après le reste… ce ne sont que des processus et des outils ! 🙂

Workshop design « de l’idée au backlog »

A part les rétrospectives, je crois que c’est le type d’animation que l’on m’a le plus demandée depuis que je suis « coachagile ».

Au fur et à mesure, j’ai développé une liste de phases et d’ateliers (non-exhaustive !!!) qui me permet de gagner du temps en préparation.

Cet article a pour objectif de partager cette liste d’ateliers, en espérant que ce qui me fait gagner du temps vous en fera gagner aussi…
J’espère aussi avoir en commentaires d’autres proposition d’animations qui me permettront de compléter ma boite à outils, donc n’hésitez pas !

Cadrage de la demande

Cette demande peut être indépendante, ou faire partie d’un accompagnement plus long, peu importe.

Voici quelques éléments de cadrage qui me semblent assez récurrents pour ce type de demande : Workshop design « de l’idée au backlog » : éléments de cadrage

Guide d’animation

Ah, enfin. On rentre dans le vif du sujet ! Notez bien que tout ça est complètement à adapter en fonction du contexte. Je vais d’ailleurs parler de beaucoup plus d’outils que ce que vous pouvez utiliser en un ou deux journées de workshop, et certains sont redondants. A vous de faire votre choix en fonction de votre contexte !
De plus, cette liste est bien sûr non-exhaustive (les possibilités sont infinies) et je j’espère bien avoir le courage (et tout simplement la présence d’esprit) de continuer à l’alimenter de temps en temps 😉

Dans les grandes lignes, j’utilise les étapes suivantes pour ce type de workshop :

  1. Icebreaker
  2. Partage des inputs, purge des idées, brainstorming
  3. Se mettre dans la peau de l’utilisateur
  4. Définir notre stratégie
  5. Définir une vision globale
  6. Backlog design : avoir une vue d’ensemble, estimer, prioriser
  7. Checkout

Phase 1. Icebreaker

Je pioche dans les animations courtes centrées :

  • soit sur l’écoute active : « ceci est… », « shake your names », « comptez jusqu’à 10″…
  • soit sur la notion de vision globale : « 1 image dixit et 1 mot au sujet du produit », « vache et spécifieurs »…

Je ne détaille pas ici chaque jeu car il en existe plein et je ne pense pas que ça apporte beaucoup de valeur… mais n’hésitez pas à me contacter si vous voulez des infos 🙂

Phase 2. Partage des inputs, purge des idées, brainstorming

S’il y a des documents d’input

S’il y a beaucoup d’inputs, je laisse un peu de temps aux personnes impliquées pour les présenter très rapidement avec un timebox de 5 ou 10 minutes par personne / input à présenter par exemple.

Le timebox est important et le discours de l’animateur aussi. Il ne s’agit pas ici d’imposer une vision top-down, mais de partager et profiter des réflexions qui ont eu lieu en amont sur le sujet. Ce sont des éléments dont les participants prennent connaissance, qu’ils peuvent réutiliser… ou pas.

Purger les idées

Les participants sont certainement venus avec des idées en tête. C’est le bon moment pour les faire s’exprimer, sous forme de brainstorming simple par exemple.

Ex : à quoi ressemblera notre futur produit ? Quelles seront ses fonctionnalités ? → réflexion individuelle, regroupement

Si on veut aller plus loin : faire appel à la créativité

Éventuellement, poursuivre le brainstorming pour aller plus loin que les premières idées et faire appel à la créativité. On peut alors utiliser les techniques de brainstorming telles que l’association, l’inversion, le voyage dans le temps, les super pouvoirs, les consultants virtuels, une analyse SWOT…

Phase 3. Se mettre dans la peau de l’utilisateur

Il est temps de se recentrer sur notre utilisateur.

Pour cela, on peut utiliser des personaeC’est le moyens le plus efficace que je connaisse pour rapprocher l’équipe des utilisateurs, quand on n’a pas des utilisateurs finaux sous la main (c’est à dire *presque* tout le temps…).

Concrètement, je demande au groupe quels sont les 2 ou 3 profils utilisateurs principaux (je peux aussi l’avoir préparé en amont) et je les fais travailler en sous-groupes pour créer les personae correspondants.

Parcours utilisateur et/ou story mapping

Dans ce type de workshop j’utilise surtout le story mapping car ça me permet de passer de manière très naturelle de l’étape « personae » aux étapes suivants plus centrées sur les fonctionnalités.

Quand on a fait un brainstorming avant, on peut s’en inspirer et replacer les idées du brainstorming dans le story mapping. Et souvent il y a encore de nouvelles idées qui vont émerger à cette étape.

4. Définir notre stratégie (facultatif)

Alors, on a maintenant des personae et plein d’idées de features / stories. On peut se dire que c’est très bien, mais qu’il va falloir challenger un peu tout ça au regard de ce que fait la concurrence par exemple.

Pour cela on peut utiliser l’outil comparative circles.

5. Définir une vision globale

On a plein d’idées, on connaît notre utilisateur. On a peut-être déjà commencé à trier un peu tout ça notamment en regardant ce que font les autres et quelle est notre stratégie concurrentielle. Normalement à ce stade, un vision produit commence à émerger.

Il est question ici de confronter les imaginaires de chacun pour faire émerger une vision commune.

Pour ça on peut utiliser par exemple l’atelier Product Box (attention, il faut du matériel : boites en carton – les boites d’archive montées à l’envers pour ne pas voir les écritures fonctionnent bien – feutres, papier de couleur, colle, scotch, magazines…).

On peut aussi utiliser un Elevator Pitch.

6. Backlog design : avoir une vue d’ensemble, estimer, prioriser

Et voilà… on a une vision produit, nos personae, plein d’idées de fonctionnalités pertinentes, un peu de stratégie concurrentielle… il faut enfin concrétiser et c’est parti pour le backlog design !

6.1 Avoir une vue d’ensemble

Déjà, on va essayer d’avoir une vision globale un peu logique de tous ces items (epics, features, user stories…) qui nous viennent des phases de brainstorming, parcours utilisateur, story mapping. Il faut ordonnancer un peu tout ça, ça va aider à la discussion pour la suite.

Pour cela, on peut utiliser l’atelier Prune the product tree.

Pour le détail du déroulé : GIYF 🙂

Je l’utilise de cette manière :

  • les racines représentent les pré-requis (sans ça les devs ne peuvent pas commencer)
  • le tronc représentant la rampe technique (cf. design sprint, toute ce qui est nécessaire pour pouvoir avoir l’équivalent du premier « hello world »)
  • Les premières branches sont nos epics
  • Les epics se subdivisent en features
  • les feuilles sont les user stories

6.2 Estimer

Il faut ensuite estimer et prioriser. Dans un workshop de ce type, je n’ai jamais utilisé de planning poker. Je trouve ça trop long, là on ne veut pas du détail, on veut estimer très grosse maille et rapidement un ensemble d’items qui peut être assez important.

J’utilise donc des estimations T-shirt size ou points Fibonacci, avec des animations de ce type :

  • « estimation line » (pour la complexité technique et la valeur business)
  • « buy a feature » (pour la valeur business)
  • « complexity / value matrix » (pour faire la complexité technique et la valeur business en même temps dans un même atelier)

6.3 Prioriser / release planning

Si j’ai le temps, je trouve très efficace de terminer ce type de workshop par une activité de type release planning, avec un outil de management visuel du backlog permettant une vue d’ensemble.

J’appelle-ça le « backlog wall« .

 

7. Checkout

ROTI, perfection game, fun/value matrix… bref, tous les outils habituels pour collecter du feedback après une atelier/workshop/séminaire/formation/conférence…

Conclusion

En me lançant dans la rédaction de cet article, je me n’étais pas rendue compte qu’il allait être aussi long. Là où je ne pensais faire qu’une liste de nom d’ateliers, je me suis un peu laissée emporter…

Voici donc une tentative de représentation synthétique :

IMG_0103

Ensuite, il faut faire son marché 🙂

Par exemple, un ensemble cohérent pourrait être :

  • icebreaker : 1 image
  • purge simple
  • personae (fiche simple)
  • story mapping
  • elevator pitch
  • prune the product tree
  • complexity / value matrix
  • backlog wall
  • perfection game

Une dernière chose : on ne traite ici que de la « rampe fonctionnelle » nécessaire au lancement d’un projet, d’une release… pas de la « rampe technique » ni de la « rampe organisationnelle » qui peuvent aussi faire l’objet d’animations, séparément ou en complément si on a la chance de pouvoir réunir tout le monde pendant plusieurs jours.

Et vous ? Quels ateliers utilisez-vous pour ce type de workshop ? J’aimerais bien compléter ce panorama au fur et à mesure, lister le plus de techniques possible pour trouver LA bonne en fonction du contexte et coller au plus près des besoins des équipes !

Et si cet article vous a aidé, n’hésitez pas aussi à me le dire 🙂

Workshop design « de l’idée au backlog » : éléments de cadrage

Le cadrage d’une animation est toujours contextuel et il n’y a pas de réponse unique, mais pour ce type de workshop que l’on m’a souvent demandé il me semble qu’il y a quand même un dénominateur commun intéressant.

Je le partage ici comme complément à ce post → Workshop design : de l’idée au backlog

La demande : cadrage 7P

J’utilise l’outil 7P pour cadrer mes animations. Le 7P se remplit avec le client au cas par cas, c’est toujours du sur-mesure ! Je vais juste reprendre ici les grandes lignes de ce type de demande « en général » (sachant que dans la vraie vie il n’y a que des cas particuliers 😉 )

Purpose

Le « client » a une idée ou une thématique, parfois un cahier des charges, quelques études marketing amont (*)

A partir de ces inputs (idée, cahier des charges…), il/elle voudrait impliquer l’équipe (et parfois des parties prenantes externes) dans la coconstruction d’une première version du backlog produit. L’objectif est double :

  • profiter de la richesses des échanges et de l’expérience de chacun
  • maximiser l’implication, la motivation, la cohésion

(*) Il peut il y avoir des documents plus ou moins détaillés, mais il faut au moins une idée de départ et une ou plusieurs personnes qui la portent (le product owner n’est peut-être pas encore identifié).
Dans le cas où un cahier des charges détaillé est fourni, je m’assure qu’il est acceptable que le contenu soit challengé et remis en cause, sinon ce type de workshop n’est pas adapté…

People

En général le participants sont les personnes à origine de l’idée, les contributeurs qui ont pu travailler dessus précédemment, les membres de l’équipe (existante ou pressentie), des parties prenantes pertinentes (cf. la matrice power/interest pour l’analyse des parties prenantes).

La toute première fois que j’ai animé ce type de workshop il n’y avait que peu de participants. Depuis j’ai tendance à challenger le demandeur pour essayer d’élargir la liste des participants (tout en s’assurant de la pertinence des personnes sur le sujet). A partir du moment où une personne va avoir des attentes ou un pouvoir important vis à vis du projet/produit, j’encourage à au moins lui proposer de participer.

Product

En général : une toute première version de backlog.

Process

C’est l’objet de ce post → Workshop design : de l’idée au backlog

Preparation

A titre indicatif… on reste sur du très light, pas besoin vraiment de préparation amont pour les participants.

  • Cadrage de la demande
  • Liste des invités
  • Invitations
  • Partager les documents d’inputs s’il y en a (specs, études…) avec tous les participants au moins 1 semaine avant
  • Guide d’animation, parfois à faire valider par le demandeur / sponsor pour les gros workshops
  • Logistique : date, salle, café, matériel d’animation…

Selon mon expérience le tout prend au moins 2 semaine minimum, souvent plutôt 4 à 6 semaines. Ce n’est pas un workshop que l’on peut organiser dans l’urgence, ne serait-ce que pour avoir la disponibilité des personnes pertinentes !

Practical concerns

Vous avez besoin :

  • d’espace : une grande salle avec des tables que vous pouvez déplacer, des paperboards, de la place au mur…
  • de temps : à moins d’1 journée dédiée, je ne sais pas faire ce type de workshop… (ou alors il faut le découper et le faire en plusieurs fois)

Pitfalls

A mon avis les risques récurrents de ce type de workshop sont :

  • la dérive en temps du guide d’animation : tous les participants veulent l’espace nécessaire pour exprimer et défendre leurs idées (ce qui peut être sans fin face aux idées des autres). Si vous ne recadrez pas en permanence, il y a de fortes chances pour que 3 jours après vous y soyez encore !
    • ne pas hésiter à prévenir les participants en début de workshop qu’ils vont ressentir de la frustration
    • discuter avant des modes de prises de décision collective au cas où il n’y ait pas consensus (voir cet excellent article sur l’excellent blog de Claude Aubry : Techniques de prise de décision : expériences)
    • relativiser : ce n’est qu’un workshop, nous avons le droit de laisser des questions ouvertes pour un travail ultérieur (prévoir un parking lot).
  • les spécifications (ou liste de requirements) non négociables
    • à vraiment bien cadrer avant le workshop… et a challenger au regard de l’adoption d’une démarche agile ou pas pour le projet/produit
  • et pour finir (j’ai eu le cas deux fois) : le(s) participants designers/ergo UX qui ont leur idée très arrêtée sur comment faire, quels étapes et outils suivre et qui vont challenger, voir refuser le guide d’animation du workshop (ce n’est pas du tout une généralité ! mais ça peut arriver 🙂 )
    • dans l’idéal, préparer le workshop avec eux, car ils peuvent beaucoup apporter
    • bien recadrer l’objectif du workshop : si la demande est d’avoir une première version du backlog, nous devrons aborder la partie « solution » dans le temps imparti, même s’ils ont le sentiment de ne pas avoir assez exploré la problématique, fait d’enquête terrain etc etc.
      • pour parler avec le vocabulaire d’un outil particulier (le double diamant) même s’il n’y a pas eu beaucoup d’études ou recherche amont, nous ne pouvons pas rester au niveau du premier diamant, nous devons passer du temps sur le deuxième diamant.

Voilà pour les éléments qui me semblent assez récurrents 😉

Backlog wall

Alors, je ne suis pas sûre que ça s’appelle comme ça. C’est ce que j’utilisais quand j’étais PO et ce que j’ai continué à utiliser avec les équipes que j’accompagne aujourd’hui, mais je n’ai pas retrouvé la référence… Je suis sûre de ne pas l’avoir inventé en tout cas. Si quelqu’un connaît le nom exact de cet atelier, je suis preneuse !

Ce n’est pas très compliqué : on input on a des items estimés à la louche (avec des animations de type « estimations line », « complexity / value matrix »…) et il faut faire notre release planning et peupler nos sprints.

A court terme (deux prochains sprints par exemple), on va retrouver des éléments de type story, sinon ce sera plutôt des features ou des epics.

Sur un grand mur, je mets les epics en ligne en haut du plus prioritaire au moins prioritaire, puis en dessous les features quand elles sont identifiées.

En dessous, je fais une ligne par sprint.

Ensuite, on complète le tableau avec les stories connues à ce jour. On met également les items plus gros, avec un tag pour se rappeler qu’il faut les détailler en grooming.

Puisqu’on a les estimations de complexité grosse maille, il faut essayer de rester sur un total par ligne uniforme et acceptable par l’équipe (sachant que ça reste bien sûr du doigt mouillé pour l’instant car on n’a pas encore de vélocité).

On peut également identifier les dépendances, il ne faut pas de dépendance sur une même ligne.

Fichier_002 (5).png

(Lorsque j’étais PO, il y a eu une période où un mur de mon bureau était entièrement utilisé pour cet affichage, et dans les faits c’était mon outil de travail principal. Plus à jour que dans Mingle, je dois l’avouer…)

J’ai déjà essayé de le faire dans l’autre sens à la demande d’une équipe (epics en vertical, ligne de temps en horizontal) mais j’ai trouvé ça moins bien pour deux raisons :

  • le tableau est plus modulaire en horizontal qu’en vertical (il est en général plus facile de rajouter une colonne qu’une ligne tout simplement parce qu’à un moment ça va être trop bas et il y a le sol). Hors le scope est notre variable d’ajustement, pas le temps, et le nombre de sprints est en général fixe.
  • quand on le fait en workshop, on a souvent fait avant un story mapping donc en gardant le fonctionnel en horizontal c’est la même logique d’un atelier à l’autre, et c’est plus confortable pour les participants plutôt que d’avoir à inverser.

Qui saura retrouver le nom original de représentation visuelle d’un backlog ? (parce que j’ai cherché avec les mots dont je me souvenais et je n’ai rien trouvé 😦 Ou alors c’est que avec le temps je l’ai trop adapté à ma sauce…)