Roadmap Canvas : prioriser les tâches et optimiser leur temps de traitement

Connaissez-vous le “syndrome du Garage” ? Cette théorie (non scientifique a priori) très bien expliquée dans l’article Everything swells To Fit Its Defined Boundaries, pose comme principe que “peu importe la taille de votre garage, il sera systématiquement rempli”. Evidemment, plus il y a de place disponible, plus il y a aura d’objets à faible utilité car vous adapterez la charge et stockerez une masse d’objets en fonction des limites fixées par l’espace du garage.

Cette théorie, à rapprocher des travaux (beaucoup plus scientifique eux) de Parkinson, illustre dans le monde du travail le principe suivant : plus nous avons de temps pour réaliser une tâche, ou un ensemble de tâches, plus ces dernières prendront du temps : “work expands so as to fill the time available for its completion ». Vous avez tous connu des expériences professionnelles (ou personnelles d’ailleurs) dans lesquelles le travail est finalisé au dernier moment comme si nous avions parfaitement estimé le temps nécessaire au début du projet : livraison de sites web, organisation d’événement, présentation pour une réunion, etc.

Ce phénomène est bien évidemment intimement liée à la notion de priorisation car nous pouvons effectivement nous “encombrer” de tâches de moindre valeur, tout comme nous pouvons stocker dans notre garage des objets inutiles.

Cela nécessite de contraindre le temps de travail afin d’inciter à la priorisation des tâches par la valeur. Ce besoin est d’autant plus prégnant dans un contexte d’innovation et de forte incertitude que cela exige de tester de nombreuses hypothèses dans une course concurrentielle parfois intense. Cette contrainte de temps ne doit pas être définie pour pressuriser les équipes et augmenter autoritairement la cadence, mais au contraire pour contraindre l’équipe à travailler de manière plus frugale, en priorisant sainement son travail afin de rejeter les tâches les moins utiles ou qui apporteront le moins de valeur.

Idéalement, dans une approche prédicitive, il suffit d’accorder le temps nécessaire à la réalisation d’une tâche pour empêcher le superflu et optimiser son temps de traitement. Malheureusement, dans une logique d’innovation, nous ne bénéficions souvent pas d’expérience similaire qui puisse rendre la durée des tâches prédictible. Par ailleurs, le contexte incertain peut également jouer sur la difficulté à estimer y compris des tâches préalablement réalisées sur des projets similaires. Enfin, comme nous le disions plus haut, il reste le sujet de la priorisation qui exige une mise à jour quasi-quotidienne et qui potentiellement demanderait une nouvelle estimation à chaque fois.

Nous connaissons tous ce problème dans nos démarches de conception de produit, de conduite de nos projets et même de suivi de nos listes de tâches personnelles. Si de nombreux outils type mapping (Trello, Wonderlist, Xmind, etc) permettent plus facilement d’organiser et de prioriser les tâches inhérentes à un produit ou un projet, ces outils n’imposent pas forcément de contraintes et de limitation permettant d’optimiser le travail dans le temps.

Nous nous sommes posés la question suivante : comment prioriser les tâches d’un business,d’un produit, d’un projet ou des tâches personnelles en :

• Imposant des échéances courtes pour ne pas laisser trop d’incertitude ou d’effet tunnel ?
• Traitant tous les sujets importants et en fixant des objectifs ?
• En priorisant et en limitant l’ambition de l’effort selon la faisabilité ?

Nous sommes partis des travaux sur les théories des files d’attente et de la Loi de Little qui pose comme postulat que le temps de traitement des tâches évolue de manière exponentielle en fonction du nombre de tâches affectés en parallèle. La Loi de Little “s’oppose aux habitudes que l’on trouve dans bon nombre d’entreprises et qui consistent de pousser en quantité le travail, en se disant que plus il y en a, plus on en sort. » Autrement dit, vous avez tout intérêt à découper un projet en plusieurs tâches et les traiter les unes après les autres plutôt que d’essayer de vous forcer à traiter le projet dans son ensemble. Cela bien évidemment oblige à prioriser pour être certain de traiter les tâches dans le bon ordre.

Nous avons donc cherché à construire un outil qui permettait de limiter les tâches dans le temps mais également de les découper par priorité. Nous voulions également conserver une logique d’itérations priorisées tout en offrant une visibilité sur l’ensemble des tâches afin de synchroniser le travail d’une équipe.

Nous avons baptisé cet outil le Product Version Grid.

Pour les experts en méthodes itératives et agiles, Version Grid peut-être compris comme un mix entre une logique Kanban (Limitation et Timeboxing des tâches en flux) et un outil comme le story mapping (Ensemble de tâches priorisées). L’objectif du Product Version Grid est de limiter la taille et la complexité des tâches (dans une logique “minimum viable”) et d’optimiser le flux de traitement en les atomisant, les priorisant par itérations. Il offre également une visibilité plus large du travail à produire afin de faciliter l’échange d’information au sein d’une équipe.

Le fonctionnement de la Version Grid est très simple :

1. Sur la première ligne vous devez lister l’ensemble des principales valeurs de votre produit. Il est important de rester très macro. Par exemple, pour une application, vous indiquerez les grands services offerts aux utilisateurs, mais également les autres éléments de valeur inhérents au produit (Identité visuelle, staffing, serveurs, licences, techno, partenariats, CRM, Régie Pub, Logistique, etc). En général, vous vous appuierez sur une Business Model Canvas ou un Lean Canvas préalable pour identifier toutes les besoins de votre produit. Dans le cas d’un objet, vous indiquerez les principales fonctions mais également les autres éléments indispensables (packaging, logistique, design, etc).
2. Une fois ces éléments identifiés, vous les organiserez de gauche à droite en les triant de manière progressive soit en fonction d’un parcours utilisateurs ou client, soit en fonction d’une priorisation autre qui guidera vos premiers pas.
3. Ensuite, vous déterminez les principaux jalons de vos différentes versions en ayant plusieurs impératifs en tête :

• Une version s’entend comme une nouvelle offre mise sur le marché. L’objectif est de récupérer des feedbacks utilisateurs pour chacune.
• Essayer de multiplier les versions. L’objectif est de multiplier les opportunités de feedbacks et améliorer le produit.
• Essayer de réduire au maximum les délais d’une version. L’objectif est de récupérer les feedbacks le plus rapidement possible mais aussi d’obliger les équipes à prioriser leurs efforts.

4. Il ne vous reste plus qu’à remplir les cases en vous forçant à faire rentrer pour chaque version un élément “minimum viable” permettant de couvrir la valeur identifiée.

Pour nous, cet outil entre dans le cadre méthodologique nécessaire à un travail collaboratif et agile efficace. En effet, les méthodes permettant de tirer le plus de valeur d’une équipe qui doit travailler ensemble par itérations, doivent reposer sur 3 principes indispensables :

• Communiquer ==> expliciter régulièrement l’ensemble du travail à fournir aux autres membres de l’équipe, car seul un partage de l’ensemble de l’information permet à chacun de contribuer à bon escient sur le projet ou le produit. Ce principe guide la plupart des artefacts créés dans la méthode par exemple (Daily meeting, Retro, Demo, Sprint Planning, etc)
• Visualiser ==> valoriser visuellement l’ensemble du travail à fournir pour le partager avec l’ensemble de l’équipe, car représenter graphiquement une idée, un concept, une stratégie permet d’aligner l’ensemble de l’équipe au contraire des documents écrits. D’une part ces derniers ne hiérarchisent et n’organisent que difficilement l’information de manière logique, mais d’autre part, ils ne favorisent pas une compréhension identique et commune à toute l’équipe. Par ailleurs, une mise en forme visuelle permet de récupérer plus facilement des feedbacks.
• Raconter ==> montrer l’enchaînement de l’ensemble des étapes — passées, présentes et futures — pour mettre en valeur une histoire cohérente et commune à toute l’équipe, car il est primordial de comprendre l’histoire que les membres sont en train de vivre ensemble. Cette condition est elle aussi indispensable pour synchroniser les contributions de chacun, gagner en efficacité dans le travail collaboratif et surtout progresser d’itérations en itérations en gardant une trajectoire (histoire) cohérente.

Les Version Grids sont des outils de management visuels de l’encours et des priorités. Ce sont des grilles de tâches organisées et timeboxées par versions minimum. Elles peuvent être déclinées en 3 usages :

• Product Version Grid ==> établir la roadmap macro des versions d’un produit
• System Version Grid ==> établir la roadmap d’un Product System (ensemble de Produits ou de chantiers) afin de synchroniser les travaux de chaque équipe autonome et dessiner une trajectoire commune
• Project Version Grid ==> lister des tâches d’un projet organisé en itérations régulières (partager un état d’avancement régulier avec toute l’équipe)
• Personal Version Grid ==> Liste de tâches et roadmap personnelles

Bien entendu, ces grilles se cultivent et doivent être mises à jour régulièrement pour les éléments horizontaux et à la fin de chaque version pour les éléments verticaux. Ce travail doit être partagé avec l’ensemble de l’équipe.

Au final, si nous devions résumer et prioriser en relevant les 3 principaux avantages d’une approche par Version Grid :

• Elle permet à la fois de concentrer l’énergie sur un nombre d’items priorisés (afin de supprimer les points d’efforts non prioritaires)
• Elle permet aussi de limiter et timeboxer l’effort afin de contraindre à livrer régulièrement le travail (afin d’éviter les effets tunnels et favoriser la frugalité)
• Elle permet de partager aux autres équipiers et collaborateurs les roadmaps et les listes de tâches (afin de recevoir plus facilement des feedbacks et ajuster les contributions des différents collaborateurs)