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 coach’agile.

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 😉