Il n'existe pas de solution miracle lorsqu'il vous faut choisir un framework Agile pour votre équipe Agile. Que vous utilisiez Kanban, Scrum ou une combinaison des deux, comme Scrumban et Kanplan, Agile est un processus d'équipe. Chaque équipe doit déterminer le framework qui fonctionne pour pouvoir planifier, suivre et livrer des logiciels exceptionnels.
Scrumban, Kanban et Scrum
Kanban vise à donner aux membres de l'équipe une quantité suffisante de travail pour exploiter pleinement ses capacités. Les équipes utilisant Kanban bénéficient d'une planification flexible, d'objectifs plus clairs et d'une transparence totale, étant donné que tout ce qui apparaît sur le tableau a une priorité absolue. C'est là-dessus que les développeurs travaillent. Kanban est idéal pour les équipes opérationnelles axées sur une livraison continue avec évolution des priorités.
En revanche, Scrum divise le travail en une série d'itérations de longueur fixe appelées sprints ; tout ce qui est planifié pour un sprint est la priorité absolue de l'équipe (par exemple, une fonctionnalité ou un groupe de fonctionnalités). Les équipes produit disposant d'une feuille de route claire et de blocs de travail prioritaires bénéficient généralement le plus de Scrum.
Mais votre équipe aurait peut-être davantage intérêt à utiliser une combinaison de Scrum et de Kanban ? Ou peut-être souhaite-t-elle migrer de Scrum vers Kanban ? Si cette situation vous rappelle quelque chose, la solution est Scrumban. Cette méthodologie mixte se manifeste de différentes manières, mais les tendances les plus courantes parmi les équipes Scrumban impliquent l'utilisation de sprints avec un backlog Scrum, et les limites WIP avec le temps de cycle Kanban. (Remarque : le temps de cycle est la durée nécessaire pour qu'une tâche parcourt le workflow d'une équipe.)
Qu'en est-il des équipes qui ne veulent pas travailler de manière itérative, mais qui souhaitent quand même pouvoir préparer le backlog ? Kanplan (ou la fonctionnalité backlog de Kanban) dans Jira peut être la solution.
Qu'est-ce que Kanplan ?
Kanplan constitue une méthodologie mixte pour le développement Agile. À l'instar de Scrumban, elle combine les fonctionnalités de Scrum et de Kanban. Kanplan est idéale pour les équipes qui souhaitent pouvoir préparer le backlog, mais ne veulent pas travailler dans des sprints.
Pourquoi Kanban est une base et non un framework strict
L'équipe d'ingénierie de build d'Atlassian est responsable de la plateforme utilisée pour développer, tester et livrer les logiciels Atlassian. Les développeurs sont tributaires de la fiabilité de l'infrastructure et de la rapidité de l'intégration continue. Il y a quatre ans, on parlait de quelque 21 000 builds par mois. Aujourd'hui, ce chiffre dépasse les 150 000 par mois.
Cette capacité à évoluer peut être attribuée à la croissance de l'équipe, au passage de Subversion à Git, aux tests automatisés et à un élément moins évident : la décision de migrer de Scrum vers Kanban. La nature du travail d'ingénierie de build (pensez aux demandes ponctuelles, aux incidents, au travail d'innovation) ne cadrait pas bien avec un framework Scrum. L'équipe a donc décidé d'introduire Scrumban, qui a rapidement été remplacé par Kanban, car l'équipe n'aimait pas travailler avec des sprints. Toutefois, il s'avère que Kanban n'était pas non plus la solution attendue. Comme beaucoup d'autres, l'équipe a essayé de le faire fonctionner. Elle est passée d'un tableau à plusieurs (un tableau d'ingénieurs expérimentés, un tableau de tâches de projet, etc.), le tout avec différents workflows. Mais sa plus grande difficulté avec tous ces tableaux ? Le « terrain vague » (comme l'a décrit l'un des membres de l'équipe) des tickets non triés qui devaient être préparés pour être traités. Une fois dans la colonne En cours, l'équipe était prête, mais sa colonne À faire méritait vraiment son qualificatif de « terrain vague ».
Transformez votre liste de tâches en un backlog
Notre équipe d'ingénierie de build a tenté de batailler contre sa liste de choses à faire, longue et désorganisée, en organisant des stand-ups quotidiens et des réunions de planification hebdomadaires. Mais ce dont l'équipe avait vraiment besoin, c'était d'un backlog, pas de plus de réunions.
Comme les tableaux Kanban ne disposent généralement pas de fonctionnalités de backlog, les gestionnaires de produit, les responsables du développement et les responsables d'équipe utilisent les tickets de la première colonne pour la planification. À mesure que cette liste s'allonge, il devient difficile de voir et de prioriser les tickets. L'équipe d'ingénierie de build a divisé ses tableaux en fonction de différents domaines de travail, mais son tableau combiné était toujours surchargé (beaucoup de défilement nécessaire).
Ainsi, au lieu d'essayer de trouver différentes façons de réorganiser l'équipe et les tableaux ou de réinventer la roue, l'équipe Jira a décidé d'intégrer les backlogs à Kanban. La fonctionnalité Kanplan introduit un backlog à colonnes étendues où les tickets sont présentés dans une liste. Ainsi, le tableau Kanban est divisé en deux écrans distincts ; le backlog pour la « préparation » et le tableau Kanban dans lequel l'équipe d'ingénierie peut sélectionner et déplacer des tâches dans le workflow.
Cette fonctionnalité est similaire au backlog d'un tableau Scrum dans Jira. Par exemple, lorsque vous cliquez sur l'icône de backlog dans la barre latérale, vous êtes dirigé vers une large colonne de tickets de backlog. Après avoir préparé votre backlog, vous pouvez faire un glisser-déposer des tickets à la prochaine étape de votre flux de travail.
Cette combinaison de l'écran de backlog de Scrum et du tableau Kanban en un tableau Agile fonctionne comme un backlog de tableau Scrum. Lorsque vous cliquez sur un ticket, la vue détaillée de ce ticket d'affiche. Les vues précises, comme la vue détaillée du ticket, permettent à chaque membre de l'équipe de réaliser des tâches plus rapidement en réduisant les distractions.
Enfin, les équipes non Scrum qui utilisent des epics et des versions pré-attribuées pour organiser leurs livraisons peuvent bénéficier d'outils disponibles dans les tableaux Scrum, notamment Afficher les tickets ou Édition rapide. Cette dernière fonctionnalité permet aux gestionnaires de produit, aux responsables du développement et à toute autre personne travaillant en mode Planification, de pouvoir gérer efficacement les epics et les versions.
Vous souhaitez ajouter un backlog à votre tableau Kanban ?
Suivez ce tutoriel pour activer un backlog dans votre projet Kanban :
Comme l'a dit un client, Kanplan est censé vous apporter « le meilleur des deux mondes ». Vous pouvez déplacer des tableaux sans avoir de sprint en cours et entrer des tâches dans un backlog pour vous aider à mieux planifier. Cela élimine les problèmes de « terrain vague » rencontrés par l'équipe d'ingénierie de build d'Atlassian, tout en fournissant aux équipes Kanban un mode de planification (auparavant inexistant). En outre, cela guide également les équipes qui n'ont pas l'impression que Kanban, Scrum ou Scrumban leur fournissent les bases dont elles ont besoin pour réaliser leur travail.
En ouvrant le mode de planification dans un tableau Kanban, les équipes nouvelles et anciennes peuvent chercher différentes façons de faire fonctionner ce framework Agile au lieu d'essayer de suivre des bonnes pratiques peut-être inappropriées dans leur cas. Rappelez-vous : le développement Agile est une amélioration continue par rapport aux bonnes pratiques.
