Accueil > Méthodes Agiles > Scrum Day Paris 2013 – Mon équipe fait son haka en Kanban style

Scrum Day Paris 2013 – Mon équipe fait son haka en Kanban style

Le Jeudi 11 Avril 2013, à Paris, j’ai participé au Scrum Day dont Objet Direct était un des sponsors. J’ai assisté à plusieurs conférences dont #OMG ; mon équipe fait son haka en Kanban style présentée par Laurent Morisseau. J’ai trouvé cette présentation instructive, je vous en livre donc un résumé.

Tout d’abord, le sujet était : Comment améliorer Scrum, ou plus précisément : Comment Kanban peut apporter un plus à la méthode Scrum. La combinaison des méthodes Kanban et Scrum est plus communément appelé ScrumBan.

La conférence commence par un constat, Scrum, comme toute les autres méthodes, présente des atouts mais possède également quelques faiblesses, on parle alors d’anti-patterns. Nous allons voir, par l’intermédiaire d’exemples, comment la méthode Kanban peut résoudre des anti-patterns Scrum. Voici les anti-patterns Scrum détaillés pendant la présentation :

  • 1 développeur = 1 story
  • 1 goulet d’étranglement
  • 1 Product Owner (PO) dépassé

Commençons donc par l’anti-pattern : 1 développeur = 1 story

Voici les symptômes de cet anti-pattern :

  • Au daily meeting, les personnes ne s’écoutent pas forcément parce qu’elles ne sont pas directement impactées/intéressées par le travail des autres. En forçant le trait, cela peut ressembler à du simple reporting.
  • Le burndown ne lèvera pas forcément d’alertes à la différence du burn up (on comptabilise le nombre de stories terminées). Il prendra la forme d’un escalier formé de grandes marches et de longues périodes où le burn up reste plat.

Quelles sont les conséquences négatives :

  • Travail individuel (pas de propriété collective du code et création de spécialistes)
  • Risque de non tenu du périmètre de sprint parce qu’il y a trop de stories à finir les derniers jours du sprint

Quelles pistes d’amélioration utiliser:

  • Donner le droit de travailler ensemble (sur la même story mais également par le biais du pair programming)
  • Limiter le nombre de story en cours (inspiré de Kanban)

Un concept important de la méthode Kanban est de définir des nombre limites d’items, par exemple, décider de ne jamais avoir plus de deux stories en cours.

Un système basé sur des contraintes est assez vertueux et peut permettre de soulever des problèmes par forcément visibles. Prenons un exemple : le fait qu’une équipe n’arrive pas à respecter le nombre maximum de story en cours peut signifier que l’équipe n’a pas envie de travailler ensemble.

Les effets attendus après la mise en place de ses axes d’amélioration sont :

  • Limiter le WIP (Work In Progress)
  • Lisser la création de valeur
  • Contraindre un processus peut aboutir à une plus grande collaboration

Poursuivons avec le second anti-pattern : 1 goulet d’étranglement

Prenons l’exemple de tests d’acceptation qui seraient vraiment long à passer. A la fin du sprint, pris par le temps, on pourrait être tenté de ne pas exécuter toute la compagne de tests et, ensuite, de faire la démonstration même si tous les tests n‘ont pas été exécutés. Nous rencontrons alors un problème, déjà présent avec la méthode du cycle en V, qui consiste à exécuter tous les tests à la fin. Ceci est une mauvaise approche parce que nous démontrons des stories qui ne sont pas complètement finies /testées.

Quelles pistes pour améliorer ce problème ?

  • Visualiser le problème, dans notre cas, ajouter une ou plusieurs colonnes à notre task board pour matérialiser cette phase de tests.
  • Sur cette phase, il faudra définir des limites hautes et basses : correspondant au nombre maximum d’items et au nombre minimum d’items. Ces limites permettent de travailler en flux tiré. Ce principe suit la théorie des contraintes.

Ces pistes s’appuient sur les concepts Kanban suivant :

  • Voir le processus terrain (concept du management visuel)
  • Rendre visible les goulets d’étranglement
  • Limiter le nombre maximum d’item par étape
  • Limiter le nombre minimum d’item par étape
  • Analyser pour mettre l’effort au bon endroit et au bon moment

Terminons avec le troisième anti-pattern : un PO dépassé

Les signes révélateurs de ce problème sont :

  • Soit le backlog de produit est beaucoup trop détaillé et contient de nombreux items fonctionnels. Le PO est donc trop en avance, la priorisation des items sera donc très complexe
  • Soit à l’inverse, le backlog de produit est trop en flux tendu. Le PO est en retard et l’équipe de développement manquera de matière et sera en attente de travail à faire.

Ces deux situations sont à éviter, il est préférable que l’avancement du backlog soit cohérent avec le rythme de l’équipe de développement.

Une façon d’améliorer cette situation consiste à afficher le backlog au mur, avec par exemple, les quatre états suivants (Stories proposées/Stories acceptées/Stories estimées/Stories prêtes). Ensuite de définir des limites pour chaque état. Par exemple, pour les limites des stories prêtes : sachant que l’équipe fait N stories par sprint, la limite inférieure est N et le nombre maximum est 2N. Grâce à ces indicateurs, nous pouvons savoir, à tout moment, si nous sommes en retard ou en avance par rapport à la préparation du prochain sprint. Si nous sommes en avance, nous allons privilégier les tests et/ou le recueil et/ou le raffinement des exigences avec le PO. Si nous sommes en retard, nous allons faire un focus sur les stories.

Quels sont les effets attendus :

  • Le backlog est en flux tiré
  • Avoir le bon nombre de stories prêtes (ni trop peu ni pas assez)
  • Avoir une meilleure visibilité sur le cycle de vie d’une story

En conclusion, nous pouvons donc voir, à travers ces exemples, que les deux méthodes sont complémentaires. L’utilisation de Kanban permet de pallier à des faiblesses de la méthode Scrum.

  1. 17/04/2013 à 00:12 | #1

    Et pour ceux qui l’ont raté, cette session sera aussi à Mix-IT 2013, dont Objet Direct est sponsor : http://www.mix-it.fr/session/145/-omg-mon-equipe-fait-son-haka-en-kanban-style-

  1. Pas encore de trackbacks


cinq + 8 =