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 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 😉

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…)

Elevator Pitch

Pour définir une vision produit, la raison d’être d’une équipe, d’une entité ou d’une communauté… J’aime beaucoup utiliser des Elevator Pitch.

On trouve pas mal de techniques et de formats différents sur le net. Personnellement j’ai retenu celui-ci :

2017-10-29 21_17_51-Fichier_002 (3).png ‎- Photos.png

Je le recopie sur un paperboard pour les workshops en présentiel, ou j’utilise cette image comme image de fond sur une application de type « tableau blanc en ligne » pour les animations à distance (ce que j’essaye d’éviter, mais parfois on n’a pas le choix…).

Attention, lors de cet atelier ne sont retenus dans la version finale que les formulations précises qui sont comprises & acceptées par tous.

Comparative circles

Cet outil permet de travailler sur une stratégie produit au regard :

  • du besoin client (mais normalement si on est passé par l’étape des personae = story mapping par exemple ce sera rapide car on a déjà fait le lien avec les usages)
  • de la concurrence
  • de notre propre positionnement (en tant qu’entreprise / entité / équipe…)

On va commencer à toucher du doigt des notions de stratégie : est-ce que je dois privilégier le fait de rattraper au plus vite notre retard sur une fonctionnalité qu’un concurrent propose déjà ? Au au contraire chercher un positionnement différenciant ?

Je vous conseille cette vidéo : https://www.youtube.com/watch?v=bl5cyZlay4k

Et voici en une image la déclinaisons que j’utilise de cet outil en workshop :

Fichier_002 (2).png

Les différentes étapes de l’animation :

  • En input : une liste d’items (epics, features, user stories…) qui peuvent venir d’un brainstorming par exemple.
  • Je dessine les trois cercles
  • On commence par se concentrer sur le client. Quels sont les items qui l’intéressent ? On peut pour cela utiliser les personae si on en a fait précédemment. On délimite alors deux zones :
    • les fonctionnalités que veut le client
    • ce qu’il ne veut pas. Pas besoin de passer plus de temps sur cette zone ! Si on a plusieurs post-its dans cette zone on peut par contre prendre note pour plus tard (ou pour itérer sur le même exercice) : est-ce que nous nous adressons au bon client ? Est-ce que nous n’aurions pas intérêt à revoir notre cible marketing ?
  • On se concentre ensuite sur nos concurrents. On peut avoir préparé l’atelier avec une petite veille concurrentielle par exemple. Dans le cercle « client » (qui est le seul qui nous intéresse maintenant), on délimite alors deux zones :
    • les fonctionnalités que veut le client et que nos concurrents proposent
    • les fonctionnalités que veut le client et que nos concurrents ne proposent pas
  • On se concentre ensuite sur notre propre positionnement. Dans le cercle « client », on délimite alors 4 zones :
    • les fonctionnalités que veut le client, que nos concurrents proposent, et que nous ne faisons pas → souhaitons-nous investir pour rattraper notre retard ? Pouvons-nous le faire rapidement ?
    • les fonctionnalités que veut le client, que nos concurrents proposent, et nous aussi → c’est une zone ou la concurrence est difficile. Souhaitons-nous investir pour continuer à améliorer ces produits pour être différenciant à fonctionnalité égale ?
    • les fonctionnalités que veut le client, que nos concurrents ne proposent pas, mais nous si → nous avons un avantage dans cette zone, il s’agit de le garder !
    • les fonctionnalités que veut le client, que nos concurrents ne proposent pas, et nous non plus → c’est une zone pleine d’opportunité mais également pleine de risques… aurons-nous le courage de l’explorer ?

Le support visuel avec les trois cercle n’a qu’un objectif : amener une équipe à se poser ces questions, à discuter… et décider d’une stratégie qui soit comprise et partagée par tous.

Parcours utilisateur vs. story mapping

Bon, n’étant pas designer UX, je vais essayer de ne pas dire de bêtises. Mais c’est pas gagné ^^’

Ce post a pour objectif de faire le point sur ces deux outils, dont j’ai découvert assez récemment… qu’ils étaient différents ! (en complément du post Workshop design « de l’idée au backlog » qui en présente un contexte d’application particulier).

Jusqu’à récemment, je faisais ce que j’appelais le plus souvent des « parcours utilisateurs » sans me rendre compte que c’était du « story mapping » et j’utilisais d’ailleurs allègrement les deux dénominations pour la même chose. La différence peut vous paraître évidente, je ne sais pas… en tout cas pour moi ça ne l’était pas du tout.

Voilà ce que j’en ai compris…

Parcours utilisateur

Il s’agit de creuser le parcours des personae. On arrive à une déclinaison contextuelle des éléments que l’on peut mettre dans une carte d’empathie par exemple (si cette phrase vous paraît obscure, rdv ici : Persona design).

En lisant pas mal d’articles à ce sujet j’ai trouvé plusieurs variantes de templates…

Voici celui que j’utilise :

2017-10-29 20_11_33-

Bien sûr du coup, si on a plusieurs personae on au moins un parcours utilisateur par personae. On peut même en avoir plusieurs pour un même personae. En workshop, si on a un groupe de participants important, on peut les scinder en sous-groupes avec chacun un parcours utilisateur a réaliser.

Attention, c’est riche, ça permet de bien s’approprier les personae et leur contexte mais ça prend du temps !

Story mapping

Je vous recommande l’excellente conférence d’Alexandre Boutin sur le sujet.

Autant j’ai peu utilisé les parcours utilisateurs tels que décrits ci-dessus (comme je le disais je n’ai découvert que récemment la différence avec le story mapping…) autant j’ai beaucoup utilisé le story mapping.

Voici le type de template que j’utilise, et en fait c’est un peu une adaptation car je fais une ligne par persona :

2017-10-29 20_35_04-Fichier_002 (6).png ‎- Photos

Comme le dit Alexandre dans sa conférence, je pars d’une notion d’étapes chronologiques au début de l’exercice (ça aide à se projeter dans les baskets de l’utilisateur), puis je relâche un peu cette contrainte si ça aide la réflexion. Ce n’est pas le côté chronologique qui est important, mais le fait de lister les usages…

Bien sûr, comme j’ai une ligne par persona, il y a potentiellement des doublons dans les items identifiés. Je pense que ce n’est pas grave, il est toujours assez facile de regrouper après sous un même wording pour désigner un usage commun à deux personae. Je trouve qu’il est beaucoup plus difficile de partir d’un usage unique et d’en déduire deux contextes d’usages différents pour deux personae différents…

Et vous, qu’utilisez-vous comme outils ? Story mapping ? Parcours utilisateur ? Les deux mon capitaine ?

Persona design : la carte d’identité

J’utilise très souvent des personae (je dis un persona, des personae, mais la plupart du temps je vois écris personas pour le pluriel… je ne sais pas ce qui est le plus correct ^^).

Pour le format, j’en ai expérimenté trois :

  • Une « fiche simple »
    • Qui est-il
    • Son but
    • Ses habitudes
    • Son besoin / ses attentes

Attachment-1.png

J’ai développé ce format pour un cours d’ergonomie il y a plusieurs années… et depuis il m’a plutôt bien servi, pour ce cours (mais je ne le donne plus maintenant), mais aussi en entreprise.

Je le partage donc ici, au cas où ça puisse également servir à d’autres 🙂

C’est un template plutôt détaillé, qui prend un peu de temps à la réalisation, mais qui je trouve permet vraiment de s’imaginer le persona en tant que personne à part entière.

A la base c’est un template au format électronique (pptx), mais on peut aussi l’utiliser un workshop en présentiel à condition d’avoir beaucoup de matériel type magazines à découper pour les images.

Voici le template et une version complétée avec le personnage de Tyrion (pour l’exemple ! bien sûr que ce n’est pas vraiment un persona…)

2017-10-29 11_08_55-Template persona.pptx - PowerPoint 2017-10-29 11_09_13-Template persona.pptx - PowerPoint.png

2017-10-29 11_00_22-Ergonomie_IMR2_Template persona.pptx - PowerPoint.png 2017-10-29 11_00_37-Ergonomie_IMR2_Template persona.pptx - PowerPoint

Et voici le fichier : Template persona

Qu’en pensez-vous ?

 

L’agilité zen

zenthings

Vous avez peut-être déjà vu cette liste, il en existe quelques variantes à 10 ou 12 items en général. J’ai retenu la version ci-dessus tout simplement pour son aspect coloré 🙂

Ça ne vous rappelle rien ?

Do one think at a time, Do it slowly and deliberately
Focus, l’une des valeurs de Scrum, ou les limites Kanban, trouver un rythme durable…

Do it completely
Quand c’est ce n’est pas done, ce n’est pas « done » 🙂

Think about what is necessary, Do less, Live simply
Principe 10 : « La simplicité – c’est-à-dire l’art de minimiser la  quantité de travail inutile – est essentielle. »
Keep it simple.
Less is more.

Put space between things, Develop rituals, Designate time for certain things
Toutes les cérémonies Scrum en sont des exemples !

Smile and serve others
Ne dit-on pas que le ScrumMaster est un « Servant Leader » ?

Make cleaning and cooking become meditation
Développer des routines, « Focus »…

Devote time to sitting
Hummm… j’adorerais tester quelques minutes de méditation avant les daily par exemple, pour démarrer la journée en pleine conscience et sans stress inutile 😉 A tester ?


Qu’en pensez-vous ?

Beaucoup disent encore que l’agilité sert à aller « plus vite ». Faire « plus », au lieu de faire « mieux ». Je dis souvent que dans nos métiers, il n’y a (presque) rien d’urgent, il n’y a que des gens pressés. Si seulement nous arrivions à être un peu plus « zen »… peut-être serions-nous alors naturellement plus « agiles » 🙂

Agile Tour Rennes 2017

Hier j’étais à l’Agile Tour Rennes.

Pour moi un Agile Tour, c’est un peu comme me replonger la tête dans la marmite de potion magique. C’est intense, ça réchauffe, ça booste en connaissance et en énergie et j’en ressors un peu « shootée » !

Comme tous les ans, il a été très difficile de choisir parmi toutes les conférences et ateliers proposés… Au final, voilà quel a été mon programme :

Keynote « Changer le monde une conversation à la fois » de Gery Derbier

20171014_144417

Ce que j’en retiens :

  • La recherche d’équilibre entre deux formes de logique/langage, sans jugement a priori sur l’une ou d’autre
  • Icebreaker / mise en pratique à l’échelle d’un amphi (ci-dessous ce que j’en ai retenu, dsl si ce n’est pas exactement ça…)
    • demander à votre voisin de vous raconter un moment « pétillant » pour lui, où il s’est senti fier
    • lui dire ce qui vous a impressionné dans ce qu’il vient de dire, mettre en évidence les qualités
    • lui demander : si ces qualités devaient être encore plus fortes chez toi, à quoi ton entourage pourrait le voir ? Quels en seraient les signes visibles ?
  • Idée d’animation : essayer de donner collectivement un nom à un problème difficile. Exemple : « mauvaise pression » = « Gargamel »
  • Idée de question à poser après une conférence ou formation : « suppose que cette conférence/formation ait été utile pour toi, à quoi le verrais-tu dans les prochains jours ? »

Conférence « Le design thinking et l’UX pour les PO » de Matthieu Gioani

J’en retiens une confirmation utile et rassurante de ce que j’ai appris/découvert/déduis sur ce terrain  :

  • Le PO fait face à trois challenges pour lequels l’aide d’un UX designer est précieuse (ou développer des compétences d’UX design chez le PO)
    • Réaliser
    • Fédérer
    • Anticiper
  • Tous les mêmes de l’équipe et en particulier le PO peuvent / doivent connaître, s’inspirer ou utiliser les bonnes pratiques du Design Thinking / UX design
    • Interview utilisateurs
    • Parcours utilisateurs (attention, c’est différent du story mapping)
    • Prototypage ultra-rapide
    • Tests utilisateurs
    • Design sprints
  • Sur le positionnement des différents rôles :
    • L’UX designer fait partie des parties prenantes (parfois nombreuses) qui ont des attentes / idées / recommandations pour la conception du produit
    • Le seul décisionnaire reste le Product Owner
    • L’UX designer intervient donc plutôt en amont, en collaboration avec le Product Owner pour définir / consolider / développer la Vision et le Backlog
    • L’UI designer intervient lui plutôt dans la mêler pour la réalisation graphique des interfaces
    • Même si les rôles UX designer et IU designer sont portés par la même personne, ils sont différents

Conférence « Au secours, mon chef m’a demandé de passer au DevOps » de Antony Guilloteau

J’y allais pour essayer de trouver quelques clés pour m’aider à accompagner des équipes qui veulent passer en devops. Je sais ce qu’est le devops, mais je me suis souvent demandé : en tant que coach agile, par où commencer l’accompagnement vers cet objectif ? De ce point de vue, voici ce que j’ai retenu de la conférence :

  • 3 grandes étapes dans la mise en place d’une démarche devops
    • Regarder ce qui prend du temps (pas cité en conférence, mais j’y vois du Value Stream Mapping par exemple…)
    • Intégrer les ops, binômer (j’imagine pouvoir utiliser des techniques similaires par rapport au lancement d’un projet Scrum par exemple où il faut rapprocher les interlocuteurs métier et business avec l’équipe)
    • Amélioration continue
  • Pas mal de points de vigilance à avoir : attention aux régressions techniques, développer avec al cible, monitorer, attention à la stabilité du produit, quel service minimum si tout plante, etc…
  • Une réflexion très intéressante sur les limites de la pluridisciplinarité, et faire attention à ne pas devenir moins compétentes à force de vouloir développer la multi-compétence

Keynote « Libérer l’entreprise de son patron… pour plus de performance » d’Alexandre Gérard

Je connaissais l’histoire et je l’avais déjà vu en conférence, mais Alexandre Gérard est un très bon orateur et c’est toujours un plaisir.

Standing ovation bien méritée à la fin de la keynote ! \o/

Atelier « WSJF : quésaco ? » avec Thierry Conter

Je retiens que cette technique (utilisée dans SAFe pour la priorisation des Epics) permet notamment de prendre en compte l’aspect « réduction de risques » dans la priorisation. Il n’y a pas que ça, mais c’est surtout ce point qui m’intéresse.

Dans un backlog, les items techniques type « migration de solution », « refactoring », « études » (ou spikes)… ont parfois du mal à être priorisés par les Product Owners. Et à leur décharge ces éléments qui sont important d’un point de vue réduction de risque technique, préparation de l’avenir, vision long terme… sont évalués comme les autres en terme de valeur business et complexité, ce qui ne reflète pas forcément ce qu’ils apportent vraiment au produit.

Grâce à cette technique (ou en l’adaptant un peu), en ajoutant une dimension « réduction de risque » à l’évaluation des items, la priorisation de ces items pourrait être facilitée (et pas uniquement au doigt mouillé, parce que l’équipe de réalisation pousse une gueulante ou qu’on ne peut pas faire autrement car on a attendu d’être au pied du mur…)

Retour d’expérience « Top 7 des rétrospectives les plus insolites, la 10 va vous étonner ! » de Morgan Gautier

20171014_144500

Et hop, pourquoi ne pas repartir avec quelques idées d’animation de rértos en plus, on n’en n’a jamais assez 🙂 Sur les 11 présentées, il y en a 5 que je n’ai jamais testées.

Pourquoi pas une petite rétro star wars en fin d’année, ça collera avec l’actualité cinématographique 🙂

En en plus…

+ plein de retrouvailles chaleureuses, quelques rencontres, un peu de trop de café, un très bon buffet à midi et des goodies sympa (spéciale dédicace à la KoKan qui se creuse la tête pour proposer des goodies originaux et « écolo » : l’année dernière une graine à planter, cette année une pomme marquée de leur logo mais tout à fait comestible et juteuse… bravo pour cette démarche !)

J’aurais adoré pouvoir faire la journée du samedi avec mes enfants (j’ai testé l’année dernière et c’était vraiment top), mais des contraintes familiales en ont décidé autrement… L’année prochaine peut-être ? 😉