Kanban et Scrum, des différences

Dans le mini-livre Scrum et Kanban, tirer le meilleur des 2, l'accent est plutôt mis sur la complémentarité des pratiques.

David Anderson, pourtant auteur d'une préface de l'ouvrage en question, pointe, dans son article Thoughts on how Kanban differs from Scrum, des différences importantes entre les 2 approches.

Anderson met en avant des contextes d'organisation qui sont plus adaptés à l'une ou à l'autre. Il écrit notamment :

If your organization has low maturity, limited capability at risk management, change management and decision making, and is riddled with specialization and defensiveness then Kanban is probably a better choice.

Les promoteurs de Kanban sont en train de le positionner comme une évolution en douceur par opposition à Scrum qui leur paraît représenter une révolution. C'est probablement excessif mais c'est une stratégie qui cherche à attirer ceux qui sont effrayés par un changement radical.

Il est vrai que certaines caractéristiques font que le passage à Scrum demande des changements importants dans les habitudes des organisations.

Comme le dit Anderson, une maturité faible en développement de logiciel rendra le passage à Scrum difficile. A l'inverse, ce sera bien plus aisé si l'organisation a une maturité élevée.

Une culture d'entreprise basée sur la confiance et l'apprentissage permanent rendra aussi les choses plus faciles.

De même, une gouvernance accommodante simplifiera la transition, alors qu'une gouvernance hiérarchique forte demandera plus d'efforts aux projets qui se lancent dans Scrum.

Les organisations qui ont un haut niveau d'innovation et développent fréquemment de nouveaux produits seront aussi mieux préparées au passage à Scrum.

Par ailleurs, deux autres caractéristiques, que je rencontre souvent dans des entreprises, sont difficilement compatibles avec du Scrum "orthodoxe" :

  1. Celles qui ont un taux de changement très élevé. En particulier, elles sont habituées à répondre dans l'urgence à des demandes des clients ou de leurs services commerciaux et marketing. Le passage à Scrum sera sûrement bénéfique pour elles, en diminuant les perturbations incessantes auxquelles sont soumises les équipes de développement. Cependant la phase transitoire peut être délicate, notamment pour les personnes dans l'environnement de l'équipe, à qui on sera amené à dire non à un changement dans l'urgence : si on suit Scrum au pied de la lettre, l'équipe n'est pas perturbée pendant le sprint et le changement sera mis dans le backlog pour être traité, au mieux, dans le sprint suivant.
  2. Celles dans lesquelles les développeurs travaillent sur plusieurs projets en même temps. Le Scrum "orthodoxe" préconise d'avoir une équipe dédiée par projet. Là aussi, aller vers moins de multi-projets pour une personne est une bonne chose, mais la transition demande du temps et nécessite d'adapter Scrum, par exemple avec un backlog contenant les stories de plusieurs projets.

En résumé, les caractéristiques suivantes, relatives à l'organisation, ont un impact sur la transition à l'agilité :

  • la culture
  • la maturité du processus de développement
  • la gouvernance
  • le niveau d'innovation
  • le taux de changement
  • le nombre de projets par personne

L'analyse du contexte des organisations peut guider vers du Scrum avec des pratiques XP, ou éventuellement du Scrum mâtiné de Kanban, ou orienter vers plus de Kanban. Comme dit Kniberg, l'ensemble Scrum + XP + Kanban constitue le triangle d'or des outils de processus et la connaissance de ces 3 approches (et de leurs pratiques) améliore considérablement les chances de succès d'une entreprise qui fait du développement de logiciel.