Lorsque vous mettez en place les méthodes agiles Scrum ou Kanban de gestion de projets, peu importe l'outil que vous utilisez. Ce qui compte, c'est la qualité de la collaboration en équipe et, surtout, la création de valeur pour vos clients.
Cela dit, un bon outil aide les membres de l'équipe à visualiser facilement tous les détails du développement d'un produit, afin que tous puissent se concentrer sur la résolution de problèmes complexes à chaque sprint.
Trello est un outil Kanban idéal pour gérer les sprints car il permet aux équipes d'être constamment à jour. Et les fonctionnalités de Trello n'entravent pas la collaboration en équipe comme cela pourrait être le cas avec des outils plus complexes.
Bien que vous puissiez utiliser Trello comme bon vous semble, tester différentes approches sera peut-être nécessaires afin de trouver ce qui convient le mieux à votre équipe.
J'ai rencontré des centaines d'équipes qui utilisaient Trello pour leurs méthodes agiles Scrum et Kanban lors de la création de tableaux de bord agiles Corrello. À partir de mes conversations avec ces équipes (qui étaient soit de taille réduite mais en pleine croissance, soit de grande taille et très bien structurées), j'ai pu mettre au jour quelques pratiques courantes.
Jetons un coup d'œil à la manière dont équipes agiles utilisent Trello.
Revoyons les bases : configurer votre tableau
Soyons sûrs d'être sur la même longueur d'onde quant aux éléments fondamentaux avant d'examiner des problèmes plus complexes :
Le tableau Scrum / Kanban
Les éléments clés d’un simple tableau Scrum pour les équipes de développement de logiciels sont les suivants :
- Une liste de backlog pour le Sprint. Celle-ci est pleine en début de sprint et vide (espérons-le !) à la fin du sprint😊.
- Une ou plusieurs listes "Projets en cours". Dans la capture d'écran ci-dessus, nous avons "Développement“, "Révision de code“ et "Test“, mais vous devez faire correspondre ces listes à votre processus spécifique. Au-delà de la liste "En cours", il est utile de diviser votre processus de développement en plusieurs listes afin de mieux accompagner l'évolution des tâches du projet.
- Une liste "Terminé" contenant tout le travail déjà accompli (un petit rappel de tout ce que vous avez accompli!).
Un exemple de tableau Kanban Trello simple ressemblerait à peu près au tableau de Sprint ci-dessus, mais à la place du Backlog de Sprint, vous avez simplement une liste "Prêt pour le développement" à l'extrême gauche.
Les tâches à effectuer sont placées dans la liste "Prêt pour le développement" lorsque la programmation peut débuter, et les cartes sont classées par ordre de priorité de haut en bas.
Lorsque l'équipe peut assumer la responsabilité de nouvelles tâches, les cartes sont déplacées depuis la liste "Prêt pour le développement" vers les listes suivantes jusqu'à leur finalisation. 🚀
Prêt/e pour ... encore plus de listes !
L'exemple de tableau Kanban Trello ci-dessus permet aux équipes de suivre les cartes en attente, qui se démarquent des tâches sur lesquelles les équipes travaillent activement.
Cela permet à vos équipes d'être encore plus agiles ! Car s'il vous faut cinq jours pour venir à bout d'une carte, est-ce que cela veut dire que vous avez travaillé cinq jours sans interruption sur cette tâche? Ou existe-t-il des temps morts entre les différentes étapes du processus ? Donc... Si vous pouviez réduire les temps d'attente, le travail pourrait être effectué plus rapidement sans que personne ne travaille davantage ! (Pardon ?) Reprenons notre exemple de tableau Kanban Trello:
Ici, nous pouvons voir trois cartes dans la liste "Développement" et une seule carte dans la liste "Test". Il existe également deux cartes dans la liste "Prêt pour la révision de code". Lorsque vous examinez le tableau avec votre équipe, vous pouvez discuter pour savoir pourquoi personne n’a encore traité l’une des cartes de la liste "Prêt pour la révision de code" avant de s'attaquer à une carte de la liste "Développement".
Les listes "Prêt pour..." vous aident à savoir si les cartes sont en attente et, surtout, à montrer à l'équipe que les cartes sont disponibles pour la prochaine étape du processus, mais qu'elles ne sont pas traitées. De cette façon, l'équipe peut agir et finaliser des tâches plus rapidement (sans travailler plus). Ces listes "Prêt pour..." peuvent également contribuer à montrer les lacunes.
Dans le tableau Kanban ci-dessus, une fois que la carte de la liste "Test" sera traitée, il n'y aura plus aucun test en cours par exemple. Si le tableau était plus simple (avec moins de listes), peut-être que vous ne vous rendriez pas compte des lacunes car certaines cartes stagneraient dans la liste "Révision de code" sans qu'aucune ligne de code n'ait été effectivement révisée.
N'oubliez pas que les listes "Prêt pour..." font presque doubler le nombre de vos listes de votre tableau Kanban. Peut-être que vous ne souhaitez pas configurer autant d'étapes, mais si vous pensez que cela peut être utile, rien de plus facile que de tester cette méthode et d'archiver les listes dont vous ne voulez plus vous servir plus tard. La structure de liste flexible de Trello rend tout cela très simple. Vous pouvez également mettre en place des listes "Prêt pour..." pour les étapes de votre processus qui, selon vous, en ont le plus besoin (selon mon expérience, il s'agit toujours de la "révision de code"😉).
Archiver les tâches terminées
Les deux tableaux ci-dessus ont une seule liste "Terminé", ce qui suggère quelques méthodes agiles de travail pour décider d'archiver ou non des éléments :
- Ne pas archiver ou supprimer des cartes de la liste "Terminé" ; nous en aurons toujours besoin un jour ! ❌
- Archivez-les régulièrement dès que quelqu'un "en a assez de les voir." (Les longues listes sont souvent peu pratiques.) 🗃
- Archivez les listes "Terminé" chaque semaine (mais rappelez-vous : vous risquez de perdre la trace de ce qui vient tout juste d'être terminé). 😬
Parmi les habitudes les plus fréquentes des équipes de travail, on retrouve:
- Une liste "Terminé" pour chaque sprint / semaine / mois selon les préférences de l'équipe. Avec ce modèle, vous créez une nouvelle liste "Terminé" chaque semaine et renommez l'ancienne "Terminé - Semaine du 08 au 14 octobre". Ces listes se déplacent progressivement vers la droite et peuvent être archivées dès qu'elles ne sont plus nécessaires.
- Un tableau complet dédié aux cartes archivées que vous souhaitez garder. Le tableau s'articule autour de listes pour chaque sprint ou chaque semaine. Les cartes de la liste "Terminé" sont ensuite déplacées régulièrement vers le tableau des archives. Cela permet d'avoir un tableau principal un peu plus organisé et de garder un historique complet de ce qui a été fait et quand.
L'une ou l'autre de ces méthodes agiles est un excellent moyen de garder un historique facilement consultable de ce qui a été fait précédemment, tout en maintenant le principal tableau Kanban de l'équipe bien organisé.
La description des cartes
Je me suis aperçu que de nombreuses équipes préfèrent détailler le briefing directement dans la description de la carte plutôt que d'ajouter un Google Docs en pièce jointe. Utiliser le système Markdown offre de nombreuses options pour formater votre description. En règle générale, si la description devient trop grande, cela signifie qu'il vaut mieux diviser l'information en deux cartes distinctes.
Les liens sont utilisés pour apporter des explications complémentaires sous forme de wireframe, maquettes d'interface utilisateur et autres détails qui ne peuvent pas être documentés par écrit.
Modèles de checklists
La révision de code est souvent gérée à l'aide de checklists. Les équipes agiles créent un modèle de checklist qui peut être répliqué à chaque utilisation. Cette checklist est copiée sur les cartes voulues à l’aide de la fonction "Copier des éléments de" lorsque la checklist est ajoutée.
Si vous souhaitez que certaines checklists soient systématiquement incluses dans certaines cartes, utiliser des modèles de checklist est une bonne solution. Assurez-vous que tous les membres de l'équipe utilisent la version la plus récente de la checklist quand ils l'ajouteront à leur carte.
Utiliser les images de couverture pour un tableau "Projet/Objectifs" macro
Il peut être nécessaire pour certaines équipes d'offrir une vue globale d'un projet avec des personnes extérieures à l'équipe. Alors qu'un tableau bien rempli peut vite souffrir d'une surcharge visuelle si toutes les cartes ont une image de couverture, c'est au contraire un excellent moyen de rendre votre tableau visuel lorsqu'il contient peu de cartes.
Certaines équipes vont encore plus loin et utilisent également ce type d'approche dans des tableaux qui permettent de gérer les prochains projets de leur équipe. Si vous voulez en savoir plus à ce sujet, découvrez un exemple ici et une explication de comment utiliser ce tableau là.
Utiliser des étiquettes sans perdre la tête
Il est courant que les étiquettes soient utilisées à tort et à travers, comme si chaque carte devait être accompagnée par une ribambelle d'étiquettes. Est-ce une "tâche"? Une "sous-tâche"? Une "tâche d'interface utilisateur" ? Une "amélioration de l'interface utilisateur"? Une "amélioration du backend"? Ou je-sais-pas-quoi-encore? Peu importe !
Parfois, un niveau de détail important est requis, mais ce n'est pas la meilleure façon de faire le premier pas. Et pour reprendre les mots de John Gall :
"On constate invariablement qu'un système complexe qui fonctionne vient d'un système simple qui a fonctionné. Un système complexe conçu à partir de zéro ne fonctionne jamais et on ne peut pas le corriger pour le faire fonctionner."
Commençons donc avec un système simple constitué de une à trois étiquettes :
- Bug
- Bloqué
- Urgent (si vous en avez besoin)
L'étiquette de "Bug" est rouge pour s'assurer qu'elle se démarque sur le tableau. Si vous ne faites pas partie d'une équipe de développement, il existe probablement une classification similaire que vous pouvez adapter et adopter pour étiqueter vos cartes.
"Bloqué" signifie que l'équipe est incapable de passer à l'étape suivante. Utiliser une étiquette orange dans ce type de situation plutôt que de mettre toutes les cartes bloquées "en quarantaine" dans une liste séparée permet de visualiser à quelles listes les cartes bloquées appartiennent. De cette manière, vous pouvez voir si les cartes bloquées sont associées à un goulot d'étranglement dans une partie de votre processus afin de l'optimiser. C'est l'une des raisons pour lesquelles il est judicieux de ne pas se limiter à une seule liste "Projets en cours", mais à la subdiviser en plusieurs listes pour un niveau plus fin d'accompagnement de l'avancement des tâches.
L'étiquette "Urgent" peut être utile si l'équipe doit faire face à des tâches ou projets urgents. Vous pouvez alors visualiser le nombre de demandes urgentes de votre tableau et l'étiquette est un bon rappel visuel qui permet à votre équipe de garder un œil sur les priorités.
Astuce : vous pouvez rapidement ajouter des étiquettes aux cartes en survolant celles-ci avec la souris et en appuyant sur la touche associé au numéro de l'étiquette. Par exemple, l'étiquette de bug rouge ci-dessus correspond au numéro "4".
Création de tâches simples
Lorsqu'il s'agit de diviser les cartes en tâches plus simples, deux approches semblent fonctionner à long terme:
Utiliser des checklists
C’est l’endroit idéal pour lister les tâches d'un projet.
Utiliser Markdown permet de rendre ces checklists très claires, avec des titres en gras et des tâches secondaires. Si besoin, vous pouvez ajouter plusieurs checklists pour mieux organiser les tâches. Cependant, si vous êtes dans ce cas, il serait peut-être temps de...
Créer plusieurs cartes si besoin
Si une carte est trop grande, divisez le travail en deux ou plusieurs cartes séparées. Au fil du temps, votre équipe aura probablement une idée de ce qui rend une carte «trop grande» et sera capable de créer plusieurs cartes plutôt qu'une seule pour le développement d'un important projet.
Les équipes Scrum utilisent souvent la mesure de vélocité, qui permet d'avoir une moyenne du nombre de Story Points par Sprint. Une règle que les équipes agiles adoptent couramment est de ne pas créer de cartes plus grandes que la moitié de leur vélocité dans un même Sprint. Cela peut être une mesure utile lorsqu'une carte doit être divisée. Et si vous avez du mal à définir clairement ce qui doit être fait à l'aide d'une seule carte, cela veut sans doute dire que la tâche mériterait d'être divisée en plusieurs tâches.
Préparer votre équipe pour les épopées (Epics)
Tout comme les tâches simples, les épopées (ou les missions, peu importe le nom que vous leurs donnez) servent à regrouper des cartes avec une vision haut niveau. J'ai observé trois approches qui fonctionnent bien :
1. Utiliser des étiquettes
C'est probablement l'approche la plus fréquemment utilisée. Des étiquettes sont créées pour chaque épopée et attribuées aux cartes. Les étiquettes se déplacent avec les cartes lorsque celles-ci sont copiées ou déplacées d'un tableau à l'autre. De cette façon, il est facile de voir quelles cartes font partie d’une épopée et quel est le travail accompli par rapport à ce qui reste à faire.
Nous voyons ici cette approche avec toutes les étiquettes épopées en noir, mais vous pouvez bien sûr choisir le code couleur qui vous convient😊.
2. Utiliser les listes
Une autre approche consiste à établir une liste pour chaque Épopée à venir. Le problème est que vous perdez la relation avec l'Épopée une fois que la carte a quitté la liste. Si vous travaillez sur une seule ou un petit nombre d'Épopées à la fois, ce n'est pas nécessairement un problème car tout le monde sait quelles Épopées sont en cours de traitement. Toutefois, si tout cela prête à confusion, il peut être préférable de vous en tenir aux étiquettes, ou alors...
3. Utilisez le Power-Up Hello Epics
Le Power-Up de gestion des Épopées le plus populaire que j'ai rencontré est Hello Epics, qui vous permet de configurer des cartes comme Épopées et d'y joindre d'autres cartes. Cela vaut vraiment la peine de tester ce Power-Up si vous cherchez une solution pour gérer vos épopées!
Modèles de gestion des versions / produits pour votre backlog
Il existe différentes approches pour organiser votre backlog. La meilleure approche pour votre équipe est généralement dictée par la taille de l’équipe elle-même et le nombre de produits sur lesquels vous travaillez. Voici quelques unes des méthodes les plus utilisées.
Liste unique de backlog
Cette approche est généralement utilisée par les petites équipes qui travaillent sur un seul tableau Trello.
Souvent, c'est de cette manière que les équipes agiles commencent à gérer leur backlog sur leur Kanban dans Trello. Une liste unique "Backlog" se situe à la gauche de votre tableau. Les cartes sont classées par ordre décroissant de priorité. Cette liste peut être complémentée d'une seconde liste "À évaluer" afin que n'importe qui puisse y ajouter une suggestion ou un rapport de bug, que le responsable pourra (ou non) prioriser en la déplaçant judicieusement dans la liste de backlog.
Listes de versions ou d'étapes
Cette méthode est généralement utilisée par les équipes travaillant sur un seul tableau Trello Kanban avec un produit en développement.
Cela consiste en général à ajouter des listes représentant les étapes à venir ou les versions :
Nous avons ici deux listes de backlog pour les deux étapes à venir : "v1" et "v2". Ici, lorsque toutes les cartes de la v1 sont terminées, cette étape (ou version si vous préférez) est terminée. Cela peut être un bon moyen d'aider les équipes à gérer l'ampleur du travail à mesure que les projets grandissent. Mais comment définir ce qui appartient à la V1 et ce qui se rapporte à la V2?
Bien qu'il puisse être pratique de tout avoir à portée de clique dans un seul tableau, à un moment donné vous risquez de devoir évoluer vers un...
Tableau de gestion de produit
Ce type de tableau est plutôt utilisé par des équipes importantes qui travaillent sur plusieurs tableaux Trello Kanban ou par des équipes qui gèrent des produits complexes par leur taille.
La méthode utilisée est similaire aux listes d'étape vues ci-dessus, mais chaque liste dispose de son propre tableau. Étant donné que ce tableau est surtout utilisé par les Propriétaires de produits ou les Chefs de produits, il peut être géré avec moins d'attention. Cela permet d’ajouter des listes de commentaires, d’idées, de suggestions d’Épopées sans déranger les équipes, qui peuvent de leur côté préserver leur tableau principal.
Des listes complètes ou des cartes individuelles peuvent ensuite être envoyées aux tableaux des équipes concernées quand elles sont prêtes. Cela permet une planification claire des tâches au niveau des tableaux de chaque équipe. Par ailleurs, votre tableau de gestion de produit permet de gérer la distribution de tâches pour l'ensemble de vos équipes.
Des Power-Ups qui facilitent l'implémentation de votre méthode agile Kanban
Il y a maintenant plus de 100 Power-Ups pour Trello ! Si vous n'y avez pas encore jeté un coup d'œil, faites-le, ça vaut le détour. Voici quelques exemples de Power-Ups pour les équipes qui utilisent une méthode agile Kanban sur Trello :
- Outils de méthode Agile : Story Points, limites WIP (Work In Progress - travail en cours) et bien plus encore (gratuit)
- Corrello : tableaux de bord pour les équipes Scrum et Kanban avec Burndowns (graphiques d'avancement), CFD (Cumulative Flow Diagram), Temps de cycle et bien plus encore
- Hello Epics : mentionné ci-dessus, relations parent/enfant pour vos cartes Trello
Faite avancer votre équipe agile
Tout est dit !
En utilisant les approches ci-dessus, j'ai vu des équipes de quelques individus évoluer au-delà de 100 personnes dans leur parcours agile avec une certaine tranquillité. Et souvenez-vous : ce qui vient avant toute chose, avant même les outils, c'est l'équipe !
Traduit et adapté affectueusement par Claire Laribe.
Faites-nous part de vos commentaires. Retrouvez-nous sur Twitter (trello) ou écrivez-nous à [email protected]
À lire également : 5 étapes pour améliorer vos rétrospectives agiles
Faites-nous part de vos commentaires! Retrouvez-nous sur Twitter (@trello)!
