temps éstimé pour lire ce billet: 421 secondes

obeya

Une Obeya est une salle pour le management visuel (d’un projet, d’un programme, d’une transfo), les murs sont couverts d’indicateurs visuels. Classiquement orienté Passé vers Futur, de la droite vers la gauche.

Même si vous avez la chance comme moi de pouvoir hijacker le bureau d’un directeur pendant un mois, La version « Physique », IRL, reste lourde à maintenir en plus de trouver l’espace possible sur le long terme. Et à l’époque des équipes multi-site, donc non-colocalisé, il faut de toute façon adapter le concept.

 

Ici on va présenter une Obeya virtuelle réalisée avec RealTimeBoard, un outil de management visuel. Cela va couvrir tout le cycle d’un projet, de la vision à l’exécution pour un projet.

Dans un premier temps, passons en revue dans les différents panneaux , les murs, puis nous approfondirons certains aspects, et nous concluerons avec le retour .

 

 

la logique des panneaux

 
Commençons par présenter la logique des panneaux, par la fin, en commençant par le plus concret, le plus actionnable (le kanban du sprint ) au plus abstrait (Vision-Mission).


Dans un projet on a besoins de

  • se coordonner, de savoir « qui fait quoi, quand, » (le sprint) ,
  • et pour cela savoir en gros « quoi est fait quand », a plus grosse mailles, ( la roadmap , et la priorisation) .
  • Pour cela, on a besoins d’être clair sur le périmètre du « quoi » , et « pour qui » on le fait. ( La mission, la vision)

Cette logique a été coupée en différent panneaux, ( les murs de l « obeya ») que nous allons détailler ensuite:

Une vue d’ensemble

Le Kanban

Le Kanban
C est un kanban classique, avec trois états ( a faire, en cours, fait). Au début tous les post its sont à gauche ( à faire ) , et lorsqu’ils sont tous à droite, le sprint est fini.

 

Notons ici que ce projet (qui met en place la sécurisation d’une usine logicielle devops), n’est pas mono produit; il y a donc plusieurs produits ( et qui sont asynchrones, c’est à dire qui peuvent avancer en parallèle sans inter-dépendances ), d’ou une ligne par produit.

Le sprint est défini par l impact recherché, définit par un intitulé de scénario, et la définition of done (DoD), plus détaillée. 

 

chaque scenario aura son propre kanban. C’est plus clair ainsi ce qui reste a faire pour finir un scenario, et d’éviter les rigidités; permettant au scénario suivant de commencer pendant que le précédent se finalise.

La roadmap

Ces multiples scénarios  sont des étapes sur le « mur de la roadmap ».

 
La roadmap permet d’annoncer les lots futurs, sans entrer dans le détail, avec un séquencement reflétant les priorités.
Cela permet une communication «  à haut niveau « avec les sponsors et stake holders; qui disposeront ainsi de l’information digeste et juste suffisante pour comprendre ce qui va arriver, et dans quel ordre;

L’ impact du scénario est compréhensible, même à haut niveau, alors que le DoD demande déjà une connaissance plus technique et intime des sujets.

L’ impact visé du scénario est ventilé sur chaque « produit » ; en détaillant la Definition of Done pour chaque produit 

Un sponsors peut ainsi comprendre ce qu’il va avoir comme  impact effectif sur chaque produit , (pour un scénario).

 

 

 

Les priorités,  les scénarios, les buts  

L’ordre des « scénarios » sur la roadmap provient du « mur des priorités »

 

L’établissement des priorités permet de clarifier la « rationalité » dans l ordonnancement des scénarios (ou Epics), c’est à dire garder une cohérence lorsque l’on est face à une multitude de scenarios / EPICS/ US.


Cela reflète l’impact que l’on veut avoir, et ainsi de disposer de mots, de critères pour évaluer la valeur crée par chaque US/scenario . ( Cela crée une échelle de valeurs, en fait)

Ici, les impacts recherchés ont été exprimés par des indicateurs de sureté de fonctionnement, triés par l’ordre  d’importance recherchée pour ce projet. De la, il à été tiré une échelle de valeurs simple, conceptualisée par trois “tags” de priorités, et un slogan simple et mémorisable:

  • D’abord faut que ca  marche ( tout court) ,
  • puis que ca marche bien ,
  • et puis faire que ca marche mieux”.

et qui ont permis de faire émerger  les 3 scénarios (pour encadrer des user stories de manière cohérente). Ceci est sur le mur des “buts”, où on clarifie les impacts et buts du projet

 

Problèmes et solutions 

Les scénarios on été élaborés a partir de « requirement », au départ une liste de problématiques recensées puis  des solutions proposées .
Celles ci ont émergées suite à des décisions, technique par exemple, pour résoudre des « problèmes ».
La chaine problèmes -> decision -> solutions est documentée  simplement,  sous forme de post it, avec un code couleur, ce qui amène à une forme compacte et a une lisibilité .

Cela permet de « voir » les pensées d’un autre , littéralement. Ce qui est utile dans un travail à plusieurs, et à distance.
Cela permet aussi la traçabilités des décisions, et donc permettre à un nouveau venu de comprendre « pourquoi » on a pris telles décision ( et incidemment , de ne pas « réouvrir » encore et encore les mêmes dossiers) .
Enfin cela permet aussi de proposer plusieurs alternatives a un problème , avant un débat, et ces alternatives peuvent être préparées par plusieurs collaborateurs, en parallèle.
Et donc de preserver l’efficacité des réunions, ou on se réunit alors juste pour décider, et non dans des longues séances de (mauvais) brainstorming pour réfléchir en grand groupe. 

Le “Mur” des décisions rassemble ces décisions, une panneau par “produit”.

 

La definition du périmètre de la mission,  et de la communauté

Les problèmes ainsi solutionnés sont restreint au périmètre de la mission, qui a été clarifié par exclusion ,

 
Cette mission sert la « vision » d’une communauté, elle aussi clarifiée en nommant des acteurs-type, et en clarifiant les roles et interactions avec l’équipe.  C est le mur mission-vision

Frein , moteurs et risques

Lors du lancement, l’équipe s’est posée la question des freins et moteurs : «  qu’est ce qui pourrais nous freiner où nous faciliter la vie, entre la situation maintenant, et notre but visé”.
Regroupé ensuite en grandes familles, on s est posé la question : «  et qu est ce qu’on peut faire pour que ca n’arrive pas, ou le mitiger » . Cette étude de risque collective à permis de verbaliser les craintes sous jacentes dans l équipe, de la souder, et de mettre en oeuvre des actions de mitigations. Les « non-dits » ont ainsi leur piste d atterrissage .
Cette partie du board n’est pas actualisée avec régularité, juste lors de pivots important.

 

En Synthèse 

Voici en Synthèse, une traversée des différent murs :

  • Une action dans un kanban, s’inscrit dans un sprint, un scénario défini par l impact recherché et sa Definition of done.
  • L’enchainement des scénarios est montré par la roadmap, et les priorités dépendent des impacts recherché sur la communauté
  • Ces actions découlent des solutions à apporté a des problèmes, ceux couverts dans le périmètre de l’équipe.

 

La suite  

Ces different “murs” sont rendu possible par l’applications de  pratiques, que nous vous proposons de découvrir dans un —prochain billet, ( si il y a de la demande : et donc + et comments, si vous le désirez..- )


 

(Co-écrit par Luc Taesch et Diego d’Olievra Granja) 

Share →

Leave a Reply

Your email address will not be published. Required fields are marked *