L’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 1, 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 conclurons 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 besoin de :
- se coordonner, de savoir « qui fait quoi, quand, » (le sprint),
- et pour cela savoir en gros « quoi est fait quand », à 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
C’est un kanban classique, avec trois états (à 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’où une ligne par produit.
Le sprint est défini par l’impact recherché, défini par un intitulé de scénario, et la définition of done (DoD), plus détaillée.
Chaque scénario aura son propre kanban. Cela clarifie ce qui reste à faire pour finir un scénario, et permet d’éviter les rigidités, permettant au scénario suivant de commencer pendant que le précédent se termine.
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 sponsor 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 scénarios / 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/scénario (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 là, il a été tiré une échelle de valeurs simple, conceptualisée par trois « tags » de priorités, et un slogan simple et mémorisable :
- D’abord il faut que ça marche (tout court),
- puis que ça marche bien,
- et puis faire que ça marche mieux.
Ils ont permis de faire émerger les trois 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 « requirements », 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 chaîne problèmes ⇒ décision ⇒ solutions est documentée simplement, sous forme de post-its, avec un code couleur, ce qui amène à une forme compacte et à 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é des décisions, et donc permettre à un nouveau venu de comprendre « pourquoi » on a pris telle décision (et incidemment, de ne pas « réouvrir » encore et encore les mêmes dossiers).
Enfin cela permet aussi de proposer plusieurs alternatives à un problème, avant un débat, et ces alternatives peuvent être préparées par plusieurs collaborateurs, en parallèle.
Et donc de préserver l’efficacité des réunions, où l’on se réunit désormais juste pour décider, et non pour des longues séances de (mauvais) brainstorming afin de réfléchir en grand groupe.
Le « mur » des décisions rassemble ces décisions, une panneau par « produit ».
La définition du périmètre de la mission, et de la communauté
Les problèmes ainsi solutionnés sont restreints 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 rôles 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 ou nous faciliter la vie, entre la situation actuelle et notre but ? ».
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 œuvre 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 importants.
En Synthèse
Voici en Synthèse, une traversée des différents 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’enchaînement des scénarios est montré par la roadmap, et les priorités dépendent des impacts recherchés sur la communauté.
- De ces actions découlent des solutions à apporter à des problèmes, ceux couverts dans le périmètre de l’équipe.
La suite
Ces différents « murs » sont rendus possibles par l’application 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)
