Le Backlog de produit est cette liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit. C’est le véritable fil rouge d’un projet Agile Scrum.
Vous qui suivez ce blog, vous connaissez peut être déjà les caractéristiques majeures (D.E.E.P.) d’un bon backlog ?
Malheureusement, on peut constater que parmi les équipes travaillant dans un mode Agile, encore peu de backlogs de produit répondent aujourd’hui à ces critères de qualité!
Étonnamment (ou pas), la question de l’outil permettant de gérer ce backlog suscite souvent plus d’intérêt… Outils dédiés, payants ou non, Excel, Google spreadsheet mais aussi Sharepoint, Jira voire même QualityCenter (si si je vous assure…)… quel outil choisir? Mais, c’est oublié assez vite, une autre caractéristique du Backlog de produit qui pour moi demeure essentielle: sa dimension physique.
Mon Backlog de produit est avant tout PHYSIQUE
Disposer d’une version physique (postits ou bristols sur un mur) du Backlog de produit, visible et accessible en permanence, est tout simplement indispensable. Accompagné de sa courbe, le BurnUp, c’est selon moi un élément clé du radiateur d’informations.
Des bénéfices bien réels…
Le backlog de produit « physique » :
- offre aux yeux de tous (Equipe ou non) une vraie visibilité sur l’avancement du produit: ce qu’on fait, ce qu’on a fait et surtout le chemin restant à parcourir.
La vison du produit nous donne le cap ; le backlog de produit guide nos pas.
- est un signal fort de transparence (valeur forte de l’Agilité), mais aussi la marque d’une vraie volonté d’ouverture et de recherche de collaboration et de feedback
- permet aussi, en plus du produit partiel livré à chaque sprint, de DONNER DU SENS au travail de l’équipe. Proposer & afficher un but, une ambition est une source de motivation et d’engagement désormais reconnue. Le backlog de produit en tant que fil rouge du projet, vient concrétiser tout cela.
- Donne enfin la vue globale, cette « big picture » que CHAQUE MEMBRE DE L’EQUIPE ATTEND, et qu’aucun outil virtuel ne peut à ce jour remplacer.
L’esprit Agile et quelques prérequis
Le coût de création, notamment d’écriture, est un faux-problème (car l’ensemble prendra au final très peu de temps). Toutefois, l’efficacité du backlog de produit physique nécessite:
- Que celui-ci soit affiché, au sein du radiateur d’informations, là où l’Equipe travaille et donc évidemment pas très loin du Product Owner
- Que celui-ci soit partagé et qu’il devienne un élément de discussion entre l’Equipe et le Product Owner. Le backlog de produit physique doit devenir un véritable point de rencontre
- Que celui-ci soit «bichonné» et mis à jour en continu: laisser un backlog de produit à l’abandon dans un coin du mur n’est pas acceptable, c’est le signe que quelque ne va pas.
Trois conditions qui se travaillent au fil des sprints.
Vous l’aurez compris: le backlog de produit, moi j’en suis Fan !
Evidemment, les versions électroniques des backlog de produit restent INDISPENSABLES pour les équipes distribuées évoluant dans des contextes distants. Pourtant, y compris dans ces contextes, il faut savoir revenir à plus de simplicité, et redonner l’outil sa vraie place, c’est à dire « rendre les processus plus efficients et faciliter le travail des personnes ».
L’outil doit rester source de valeur, et ne doit pas ni devenir une contrainte ni une forme de gaspillage.
Bonjour jean-claude,
Moi aussi je suis fan de backlog, pourtant, je constate que le Backlog « papier » commence à disparaitre de plus en plus.
La plupart les bloggeurs Agile ne parlent que de cela, pourtant, la plupart des grandes entreprises qui pratiquent Agile l’on abandonné. J’ai pu le constater après une récente discussion avec plusieurs PO.
Un client d’une grosse parisienne m’a dit récemment, « cela va à l’encontre de la politique écologique de la société avec tout ce gaspillage de papier… » 🙂
De plus, beaucoup de société en open Space (ce qui est mon cas) n’ont plus de place pour mettre des backlog et des sprint en mode radiateur papier.
J’ai récemment abandonné le mode papier pour passer à l’outil informatique (peu de place sur les mur dans un contexte Open Space). Dans notre cas, nous utilisons un logiciel Open Source, Redmine avec le plugin Backlog, le backlog est accessible à tous depuis l’outil. Premier constat, seul le PO et SM continue de le regarder…
J’ai ouvert le sujet lors d’une rétro, l’équipe m’a indiqué « le backlog produit ne nous intéresse pas… », même en mode post-it.
L’agilité est en constante augmentation au sein des entreprises, penses tu que le backlog en mode papier a encore une pérennité avec le besoin d’industrialisation des entreprises ? et en quoi cela est important que les équipes puissent voir le BP tout les jours devant eux ?
Yannick
Sans affichage, pas de management visuel. La matérialisation sur un affichage commun est essentiel : tout le monde voit en permanence où en est l’équipe. Dans l’équipe même les plus aguerris reconnaissent le mérite incitatif et responsabilisant de l’affichage en plus de la simple prise de conscience de l’ampleur de ce qu’il y a à faire. Certains systèmes d’affichages sur écran permettent d’avoir cette dimension visuelle.
Alors pourquoi physique en plus. Parce que l’appropriation est meilleure : nous utilisons notre sens tactile, prendre un post-it et le faire avancer dans une colonne c’est aussi matérialiser physiquement le progrès. Voir le backlog c’est pouvoir se pencher dessus immédiatement sans avoir à passer par on ne sait quel intermédiaire technologique pour y accéder.
Alors oui ce n’est pas simple d’avoir un backlog, un radiateur d’information physique mais le sacrifier c’est sacrifier une partie des avantages induits du management visuel.
Dommage !
Bonjour ,
Merci François pour cette éclairage sur le management visuel, je l’avais déjà lu dans Lean sur le regroupant des informations qualitatives et quantitatives simples.
La question qui me vient, c’est comment interessé les développeurs à ce tableau, quand on remarque que une équipes fait juste bouger ses taches et retourne à son activité ?
Comment gérer ses tableaux dans des espaces qui ne sont pas adaptés pour poser des tableau en Kanban ?
Merci pour ce retour
Yannick
@François: Je n’aurais pas pu mieux répondre; tout est dit…
@Yannick: On a tendance à oublier les principes forts de l’agilité rappelés par François, ainsi que la notion d’EFFORTS préalables à la démarche.
C’est donc une question d’efforts et de convictions. Je dirais que dans un contexte purement colocalisé la question ne devrait même pas se poser. Le Product backlog doit être sous la responsabilité d’un Product Owner investi et disponible, et doit être partagé et compris par l’Equipe.
Estce le cas ?
La problématique est différente dans les contextes distants pour lesquels l’usage d’un outil électronique de gestion de backlog est nécessaire (outil simple et au service de l’activité)
Bonjour jean-claude,
Je suis aussi de ton avis sur le retour de François, c’est un très bon rappel sur le management visuel.
Pour revenir à tes questions, nous n’avons aucun problème sur le PB, il est très bien fait, estimé avec les priorités, les story sont INVEST, nous avons les critères de satisfaction. Tous va bien de ce côté là. Il est géré par le PO, il est accessible à tous.
Toutefois, il n’est plus sous une forme papier. Un logiciel propose la même visualisation que le format papier, avec une simulation de post-it que l’on peut bouger avec la souris. Des écrans sont installées dans les salles pour l’afficher.
Le problème que je soulevais, c’est l’absence d’intérêt des équipes pour le backlog et le Kanban. Il bouge les tâches et hop s’en vont. Il y aussi la problématique de l’espace. Nous avons un open space de 20 développeurs, avec 4 projets. A part le plafond, je ne sais pas ou mettre le radiateurs…
Je pense que je vais reprendre l’idée de François et proposer une présentation sur le management visuel. Pour montrer l’intérêt de l’affichage visuel
Merci et bonne journée.
Yannick
Deux REX :
– nous avons acheté un tableau blanc à roulette = 2 murs mobiles de plus. Bon, il faut pas se prendre les pieds dedans mais faute de murs cachés par les armoires et faute de vitres disponibles, nous avons géré la crise de cette façon. L’idée du plafond ne nous est pas encore venue mais qui sait, si les chaises se transforment en relax ce sera peut-être bien
– le coach lean passe dans l’open space et demande à voir le management visuel. Avec le MV dans l’ordinateur, il y a déjà un moment de panique à remettre la main sur ce foutu MV ! On y arrive quand même puis le coach fait venir d’autres personnes de l’équipe (après tout le MV est fait pour être partagé) : nouvelle panique à se serrer derrière l’écran. Et dernière couche : questions et suggestions sur le MV, si on faisait ci ou çà ? Alors là pas de doute, l’ordinateur ne suit plus la capacité de prototypage du papier et du crayon offerte par un management visuel physique
Développer l’intérêt pour le MV Physique c’est certainement développer la communication et l’animation qu’il y a autour : autour d’un écran ce n’est pas facile, tout le monde est hypnotisé par l’écran et a peu tendance à se regarder (l’essentiel de la comm passe dans le non verbal donc si on ne se regarde pas ?). Avec un ordinateur, l’actualisation est trop rapide, on constate et on n’ancre pas le progrès … ou l’amélioration à apporter (c’est déjà fait !) d’une certaine façon on déresponsabilise; prendre le temps (timeboxé of course) de déplacer manuellement un post-it, d’ajouter manuellement une mention sur un post-it (par exemple une retard, sans chercher à fustiger, une croix suffit, mais ce foutu retard est bien là pas caché dans une machine ou affiché de façon simpliste du fait des limites de fonctionnalités d’un soft de gestion de Scrum), d’ajouter manuellement un sujet dans l’impediment list c’est rendre concret le sujet.
Pour finir, une des meilleures façons de sensibiliser au physique c’est soit de comprendre l’attrait des gens pour le virtuel et de discuter avec eux des circonstances où ils préfèrent le physique (peut-être un pb de génération Y ?) et voir si une transposition est possible en contexte professionnel; soit de montrer les limites du virtuel par rapport au physique : un management visuel donne une direction claire et met en évidence les problèmes. Donc si à un moment donné le projet perd sa direction et ne voit pas les problèmes c’est que le MV en place n’est pas suffisant et là peut-être parce qu’il n’est pas physique (cf capacité de prototypage et ajustement du papier).
C’est un travail de longue haleine mais le « Ah ! » est au bout du chemin quand on voit une équipe autour d’un MV en train de toucher, de s’approprier et d’agir sur le projet. Ca vaut vraiment le coup !
Merci pour cet échange c’est très intéressant.