Depuis des années, beaucoup considèrent Scrum comme le point de départ pour se lancer dans l’agilité. A un tel point que Scrum et l’agilité sont très souvent confondus. La popularité et l’adoption massive de Scrum en ont fait le choix de mise en œuvre de l’agilité par défaut pour beaucoup de sociétés. Cependant, avec la récente percée de la méthode Kanban, celui-ci commence à apparaitre pour certains comme le futur de l’agilité.
Abby Fichtner est récemment arrivée à la conclusion que Kanban était le nouveau Scrum :
C’est sans doute à cause de tout le temps que je passe avec des startups, mais malgré que je valorise les avantages qu’apporte Scrum par le biais de l’auto-organisation des équipes et les retours utilisateurs en continu, je ne peux pas m'empêcher de penser que Kanban constitue l’étape suivante dans l’agilité, nous apportant plus de flexibilité et permettant de mieux capitaliser sur les leçons apprises du Lean.
Le plus gros problème identifié par Abby avec Scrum est la limitation des sprints dans le temps.
Avec les startups, Les sprints sont souvent trop longs. Quand les sprints sont trop longs, les releases deviennent peu fréquentes, l’équipe est obligée d’attendre trop longtemps avant de pouvoir s’adapter aux changements des besoins du client. Ce qui est inefficace puisque cela signifie que l’on continu d’avancer avec des informations qui sont potentiellement périmées. D’un autre côté, si le sprint est trop court, les grosses fonctionnalités doivent être découpées arbitrairement en petites tâches, ce qui n’est pas utile du point de vue des clients et qui peux leur rendre obscure ce sur quoi travaille l’équipe.
Abby indique que vu que Kanban n’a pas de sprint et au lieu de ça compte sur le fait de limiter le travail en cours (Work In Progress), deux choses se produisent lorsqu’une fonctionnalité est complétée :
- La fonctionnalité est immédiatement disponible pour une mise en production (Ce qui peut être un objectif en soi)
- L’équipe peut entamer n’importe quelle autre tâche plus prioritaire, même une qu’elle découvrirait le jour même.
On obtient ainsi plus de retours utilisateurs avec la possibilité de les prendre en compte plus rapidement.
Erwin Verweij n’a pas le même point de vue. A propos de Scrum, il dit :
[L’équipe] peut décider comment faire le travail du mieux possible. Il n’y a plus de pression. Elle évalue la charge de travail et on obtient une vision claire de ce qui peut être fait ou non. La plupart des responsables de projet aiment avoir le contrôle. Perdre ce contrôle, même si ce n’ait qu’une illusion, leur donne l’impression de négliger le process.
En Kanban, on leur redonne ce contrôle. La visualisation du workflow est comprise et apprécié des responsables de projets. Kanban ne permet pas de déduire quoique ce soit sur la vitesse de réalisation ou sur ce qui peut être fait dans un temps donné. Donc les responsables recommencent à forcer pour inclure des fonctionnalités
Il y a un gros risque que rien ne change. Les responsables de projet peuvent maintenir la pression et continuer à pousser les évolutions. Ils peuvent retrouver leurs habitudes du cycle en V d’autant qu’il est possible de découper le projet en colonnes (conception, développement, test etc.)
Lisa Crispin, a commencé par Scrum, puis est passé à des pratiques du Lean, Kanban, et XP :
Ce qui a fait que nous soyons une excellente équipe c’est notre véritable capacité à nous auto-organiser. Toutes les deux semaines nous avons une rétrospective et nous voulons vraiment nous améliorer
Je pense que c’est essentiel, pour une entreprise qui se préoccupe de la qualité, de laisser l’équipe de développement définir ce qu’ils doivent faire pour produire des logiciels de la meilleur qualité possible.
Derek Huether ajoute :
Je pense que plus de sociétés devrait savoir que Kanban est une alternative viable à Scrum. Mais tant que nous continuons de permettre à nos équipes de conserver un bon rythme, et d'éviter tant que se peut le côté cérémonieux, je n'ai que très peu de doutes sur le fait que Kanban détrône Scrum en tant qu’approche de prédilection.
George Dinwiddie aborde les points communs entre les deux méthodes :
Kanban se concentre sur la limitation du travail en cours et suggère un temps de cycle court et une cadence régulière. Scrum se focalise sur de courtes itérations et une cadence régulière pour limiter, au final, le travail en cours. Lorsque les deux méthodes sont appliquées correctement, on obtient le même résultat.
Abby conclue :
Je reste convaincu que Scrum comportent d’excellentes idées comme l’auto organisation et les retours utilisateurs en continu. Tout n’est pas à jeter avec l’eau du bain. Mais ces concepts restent valables dans une organisation Kanban.
Kanban est-il l’étape suivante de Scrum ?