Scrum : les avantages et les inconvénients
Chaque méthodologie comporte des avantages et des inconvénients. Scrum est une méthodologie Agile qui a recours à de petites équipes collaborant dans des périodes de développement courtes (sprints) pour livrer des logiciels de travail à la fin de chaque sprint jalonné. La structure Scrum réduit délibérément le processus de planification, en se concentrant sur le développement rapide de logiciels de travail, répartis en petits morceaux. Voici quelques-uns des avantages de la méthode Scrum :
- Améliorer la planification : Scrum surmonte le problème des besoins opérationnels complexes, difficiles à comprendre, et qui rendent la planification ardue. L’approche Scrum par rapport à l’évaluation des besoins consiste à les diviser en éléments consommables, rapidement développés.
- Réduire l’impact des erreurs : les erreurs commises dans un modèle Scrum sont rapidement retravaillées et réparées dans le prochain.
- Améliorer la communication : les réunions quotidiennes garantissent la bonne visibilité des mises à jour de statut (progression et retards). En effet, la gestion du développement peut se réduire à l’utilisation d’un tableau de tâches, dans lequel le backlog sprint est répertorié dans un tableau avec des colonnes indiquant le statut.
- Augmenter la productivité : les réunions quotidiennes augmentent la productivité de l’équipe.
- Créer de meilleures relations avec les clients : la nature itérative de la méthode Scrum signifie que l’implication et les commentaires des clients sont importants. Ainsi, l’équipe est plus consciente des besoins des clients et, à son tour, peut être plus réactive à ces besoins.
- Améliorer les logiciels : le changement n’est pas une interruption, mais un moyen d’améliorer la valeur du logiciel.
À l’inverse, voici quelques-uns des inconvénients de la méthode Scrum :
- Le fluage de la portée se produit : sans une fin définie du projet, le fluage de la portée devient un véritable problème, d’autant plus que le changement se fait très volontiers. Les parties prenantes sont souvent tentées d’ajouter de plus en plus de fonctionnalités.
- La méthode n’est pas l’idéal pour les grandes équipes : Scrum fonctionne mieux avec une petite équipe.
- Les membres inexpérimentés de l’équipe peuvent devenir un handicap : le succès de la mise en œuvre de la méthode Scrum dépend de la capacité des membres de l’équipe à estimer le temps de développement.
- La structure s’adapte mal aux micromanagers : Scrum fonctionne mieux lorsque le Scrum Master peut compter sur l’équipe sans être trop directif. La méthodologie Scrum concerne des individus qui gèrent leur travail ensemble, sans recevoir de supervision stricte.
- Le roulement du personnel peut être extrêmement négatif : la petite taille de l’équipe et la courte durée des périodes de développement peuvent être difficiles.
- La gestion de la qualité est plus difficile : les membres de l’équipe effectuent tous les tests, mais les tests de régression sont parfois laissés de côté et les tests unitaires qui en résultent sont les seuls tests effectués.
Guide de la gestion de projets
Votre guichet unique pour la gestion de projets
Prêt à tirer le meilleur parti de vos efforts de gestion de projet ? Consultez notre guide complet de la gestion de projet pour obtenir des conseils, des bonnes pratiques et des ressources gratuites afin de gérer votre travail plus efficacement.
Qu’est-ce que la méthodologie Kanban ?
La méthodologie Kanban, développée par Taiichi Ohno, ingénieur chez Toyota, est une méthode servant à gérer et améliorer progressivement la prestation de services au fil du temps. La méthode Kanban comporte trois principes directeurs :
- Commencez par ce que vous faites maintenant.
- Acceptez de poursuivre des changements progressifs et évolutifs.
- Respectez le processus, les rôles, les responsabilités et les fonctions actuels.
Il existe cinq propriétés principales de la méthode Kanban :
- visualiser le flux de travail
- limiter le travail en cours (Work in progress ou WIP)
- gérer le flux
- expliciter les politiques de gestion et de processus
- méthode Kaizen, ou amélioration continue, (utilisation de modèles et de la méthode scientifique)
Kanban : les avantages et les inconvénients
Tout comme la méthode Scrum, Kanban présente des avantages et des inconvénients. Voici quelques-uns des avantages de la méthode Kanban :
- Améliorer l’allocation des ressources : le WIP est limité, de sorte que de nouveaux travaux sont intégrés à l’équipe au fur et à mesure que les ressources deviennent disponibles.
- Simplifier la gestion de projet : le tableau Kanban fournit une visualisation en un coup d’œil de l’état de tout le travail, ce qui facilite la gestion de projet.
- Réduire les interruptions : le changement est moins radical parce que vous travaillez avec les processus que vous avez et que vous les améliorez au fil du temps.
- Prendre des décisions plus éclairées : la visualisation du flux de travail facilite la compréhension du déroulement ainsi que les décisions concernant les changements.
Voici quelques-uns des inconvénients de la méthode Kanban :
- Les tableaux Kanban doivent être à jour : un tableau Kanban obsolète peut causer de gros problèmes. La méthode Kanban compte sur les membres de l’équipe pour tout tenir à jour, et sans les réunions quotidiennes de Scrum, cela peut être plus difficile à faire.
- Un tableau Kanban peut devenir trop complexe : des éléments ou des processus trop nombreux, suivis sur un tableau Kanban, peuvent semer la confusion et rendre difficiles les mises à jour précises.
- Le manque d’échéances : sans périodes de développement, l’équipe peut prendre du retard.
Scrum et Kanban : en quoi ils diffèrent
Les stratégies Scrum et Kanban sont très différentes. Il peut sembler impossible de les concilier. La méthode Scrum dispose d’un ensemble de rôles prescrits, y compris le Scrum Master, le Product Owner et les parties prenantes. À l’inverse, Kanban n’a pas de rôles prescrits. Scrum et Kanban sont tous deux considérés comme des systèmes « pull », ce qui signifie que les membres de l’équipe retirent les fonctionnalités du backlog à mesure qu’il est possible de travailler sur elles. D’un autre côté, le backlog étant séparé en « lot », Scrum est alors un système « push », dans lequel un ensemble de fonctionnalités sont attribuées à l’équipe au début du sprint. Indéniablement, Kanban est considéré comme un système basé sur le « pull » dans lequel les fonctionnalités sont continuellement extraites du backlog si nécessaire.
La méthode Scrum exige une réunion quotidienne et plusieurs réunions au cours du projet. Par exemple, lors de la démonstration qui présentera le logiciel au client afin de recueillir des commentaires. La structure Kanban ne comporte pas de réunions requises.
La différence la plus frappante entre les méthodologies Scrum et Kanban est que Kanban fonctionne sans période de développement, tandis que Scrum est limité par la durée du sprint. Il n’y a pas de début ou de fin défini, mais plutôt un flux de travail continu, chaque développement réussi étant suivi par le début de nouveaux développements.
Bien que la structure Scrum soit censée être facile et flexible, certaines équipes de développement la trouvent trop rigide pour leur entreprise agile. Mais ils trouvent Kanban à la fois trop laxiste. Le Scrumban est né de l’association des méthodes Scrum et Kanban : la rigidité de la méthodologie Scrum combinée à une structure Kanban plus clémente. C’est devenu une méthode parfaite pour de nombreuses organisations agiles.
Méthodologie Scrumban : le meilleur des deux systèmes
Le Scrumban a été introduit par Corey Ladas, un passionné de méthodologie de développement de logiciels, dans son livre Scrumban: Essays on Kanban Systems for Lean Software Development. Il affirme que la méthode Scrumban a été créée comme moyen de transition pour qu’une équipe de développement passe de la méthodologie Scrum au Lean (qui s’appuie sur un flux de construction, de mesure, d’apprentissage pour l’amélioration continue et se concentre uniquement sur ce qui apporte de la valeur aux clients) ou à la méthode Kanban. Bien que l’intention initiale fût de remplacer le modèle Scrum, Scrumban est devenu une méthodologie à part entière, combinant des éléments de Scrum et de Kanban. Pour décider de remplacer la méthodologie Scrum ou Kanban par la stratégie Scrumban, vous devez tenir compte des besoins environnementaux et organisationnels.
Scrumban est la méthode la plus utilisée dans les projets de développement et de maintenance. En pratique, les équipes de développement et de maintenance ont besoin de compétences similaires. Les équipes de développement ont besoin d’un moyen de gérer l’ensemble de leur processus de développement, tandis que les équipes de maintenance doivent être en mesure d’effectuer des mises à jour et des réparations sur des logiciels défectueux.
Comparaison des méthodes Scrumban et Scrum
- Itérations : l’itération est la caractéristique déterminante de la méthode Scrum. Le modèle Scrumban adopte l’approche Kanban du flux de travail continu, les itérations étant facultatives.
- Rôles d’équipe : la méthodologie Scrum comporte des rôles définis et les membres de l’équipe de développement portent tous le chapeau du projet de développement. Le Scrumban n’exige que des rôles si cela est nécessaire.
- Visualisation : la structure Scrum peut avoir recours à un tableau, mais dépend principalement des backlogs et des diagrammes burndown. La méthode Scrumban, comme Kanban, dépend du tableau Scrumban pour maintenir la visibilité du travail.
- Réunions : les méthodologies Scrum et Scrumban exigent l’organisation de réunions quotidiennes, mais il n’y a pas de réunions de planification de sprint ou de lancement et de rétrospectives dans le Scrumban. Le Scrumban adopte la planification à la demande.
- Estimation : les équipes Scrum doivent estimer (souvent à l’aide du système de planification bucket et des story points) le temps nécessaire au travail pour respecter les engagements dans un sprint, tandis que le Scrumban n’a pas de contrainte de temps. Au lieu de cela, l’estimation devient apparente au fil du temps, au fur et à mesure que l’équipe accomplit plus de tâches.
- WIP : le travail en cours du modèle Scrum est entièrement défini par le backlog sprint et prévu au début de chaque sprint. L’équipe Scrumban limite le travail en cours aux ressources disponibles.
- Changement : le changement est vu d’un bon œil dans la méthode Scrum, car il est possible d’y répondre et de le planifier dans le sprint suivant, mais dans la méthode Scrumban, le changement est traité instantanément. L’absence de sprints et de backlogs signifie qu’il n’y a pas de limites quant au moment où les tâches peuvent être introduites. Le changement est une question de ressources disponibles pour pouvoir le prendre en charge.
- Gel des fonctionnalités : bien que le modèle Scrumban réponde instantanément au changement, il y a une limite. Cette méthode adopte le gel des fonctionnalités, un délai où les changements ou les fonctionnalités supplémentaires ne peuvent pas être ajoutés parce que la date limite du projet approche.
- Triage : étant donné que la méthode Scrumban n’adopte pas l’estimation, l’étape du triage est essentielle. À l’approche de la date limite d’un projet, le triage permet au chef de projet de terminer le travail sur des fonctionnalités moins importantes afin de terminer les fonctionnalités essentielles dans les temps.
Comparaison des méthodes Scrumban et Kaban
- Rôles des équipes : le modèle Kanban n’a pas de rôles prescrits, mais dans la méthodologie Scrumban, les équipes sont définies et il peut y avoir des rôles requis.
- Réunions : la méthode Kanban ne nécessite pas l’organisation de réunions, alors que la méthodologie Scrumban se compose de réunions quotidiennes. Les réunions quotidiennes aident à maintenir la collaboration entre les membres de l’équipe et à surmonter les obstacles à la progression. De plus, bien que la méthode Kanban concerne un processus en évolution, il n’y a pas de réunions prescrites pour examiner l’évolution ou les améliorations proposées. La stratégie Scrumban a recours à des post-mortem qui permettent à l’équipe de travailler sur des améliorations des processus et aux membres de l’équipe de partager ce qu’ils ont appris du travail.
- Indicateurs : les stratégies Kanban et Scrumban comptent toutes deux sur la mesure du délai et du temps de cycle (parfois utilisés de façon interchangeable) comme métrique clé. Cette mesure estime le temps moyen nécessaire pour accomplir une tâche spécifique. Le délai est ce que le client voit entre le moment où une demande est faite jusqu’à la livraison. Le temps de cycle est le temps entre le début du travail et la livraison.
Quel est le meilleur environnement pour introduire la méthodologie Scrumban ?
Vous vous demandez peut-être quel environnement est le meilleur pour introduire la méthodologie Scrumban. Comme pour toutes les méthodologies, Scrumban ne convient pas à tous les environnements ou toutes les cultures. Si votre organisation est parfaitement adaptée à la méthode Scrum, c’est-à-dire de nombreux membres expérimentés, des clients qui souhaitent participer au processus de développement, une compréhension claire des récits utilisateur, et que votre culture d’entreprise met l’accent sur la gestion de projet et les échéances définies, vous voudrez peut-être vous en tenir à cette structure. Si vous travaillez principalement dans un environnement de maintenance dans lequel le nouveau développement ne représente qu’une petite partie des activités de l’équipe, que le travail est en cours, qu’il est important de retirer des tâches si besoin, et qu’il n’y a pas de projet défini pour des clients spécifiques, vous voudrez peut-être vous en tenir au modèle Kanban.
Le meilleur moment pour mettre en œuvre le modèle Scrumban est quand :
- un projet comporte beaucoup de changements inattendus dans les user stories ainsi qu’une refonte des priorités ;
- vous souhaitez ajouter des fonctionnalités pull au processus de développement Scrum ;
- la méthode Scrum a échoué en raison d’un certain nombre de problèmes ou parce qu’il n’y a pas assez de ressources pour répondre aux contraintes de temps de cette méthodologie ;
- le travail est axé sur les événements, comme le service d’assistance, où les priorités changent constamment ;
- l’équipe se concentre entièrement sur l’ajout de fonctionnalités et la prise en charge d’un produit existant ;
- la méthode Scrum est utilisée par votre équipe de développement, mais certains principes du Kanban vous intéressent ;
- vous trouvez qu’une partie de la rigidité de la méthode Scrum limite la capacité de votre équipe à s’adapter au changement ;
- vous passez à la structure Kanban, mais que vous devez apporter de petits changements méthodologiques afin de limiter les perturbations.
Votre équipe (et sa façon de réagir face à la méthode) aura toujours le dernier mot concernant l’adoption de la méthodologie Scrumban. La stratégie Scrum fonctionne bien pour les équipes qui aiment les structures plus définies et qui veulent connaître le travail à faire le lendemain. Le principal avantage de la méthodologie Scrumban est la fluidité du modèle. En fin de compte, comme pour toute méthodologie de développement, l’adhésion de l’entreprise et de l’équipe déterminera le succès.
Pourquoi Smartsheet est un outil efficace pour adopter la méthode Scrumban
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.