Consultez nos archives

L’une des équipes pour lesquelles j’agis à titre de Scrum Master a un volet opérationnel. Comment cette division opérationnelle fonctionne-t-elle dans une équipe Scrum, vous demandez-vous? Simple : ça ne fonctionne pas. Quand j’ai commencé à travailler avec cette équipe, le service de promotion courriel (ou comme nous préférons l’appeler, Weapons of Mass Conversions, ou WMC), nous avons essayé ardemment d’utiliser le cadre Scrum pour gérer toute l’équipe. Nous nous sommes rapidement aperçus que d’essayer d’utiliser Scrum pour toute notre équipe était l’équivalent d’essayer d’adapter un carré pour un trou rond. L’équipe WMC est composée de 2 développeurs, 1 intégrateur, 1 designer, 1 responsable des promotions courriel marketing, 1 spécialiste en envoi de courriels, un propriétaire de produit et un Scrum Master.

Notre but est de promouvoir nos produits à travers des campagnes de courriels marketing. La semaine dernière seulement, nous avons envoyé plus de 15,5 millions de courriels à nos clients. Réaliser un tel exploit sur une base hebdomadaire n’est pas facile. Nous travaillons avec une plate-forme très perfectionnée, entièrement personnalisée, bâtie par notre équipe de développement (DEVS) qui travaille de concert avec notre division opérationnelle (OPS) hautement qualifiée. Les équipes OPS et DEVS sont donc inséparables. L’équipe OPS s’appuie sur la plate-forme technologique que les DEVS ont bâtie et continuent à bâtir pour l’envoi de nos campagnes courriel, ce qui signifie que les membres de l’équipe OPS sont en fait des parties prenantes pour la plupart des items du carnet de produit sur lesquels l’équipe DEV travaille. Ceci est plutôt intéressant d’un point de vue Agile/Scrum. Sans surprise, Scrum a très bien fonctionné pour la gestion de nos DEVS, mais l’atteinte des mêmes résultats n’était pas facile pour le groupe des OPS. Nous savions que DEV et OPS devaient travailler très étroitement ensemble afin d’atteindre nos objectifs, mais il a été de plus en plus évident pour nous que nous ne pouvions pas utiliser Scrum pour la gestion de toute l’équipe.

Nous avons donc décidé d’utiliser Kanban pour gérer les OPS. Kanban est un métaprocessus qui permet à l’équipe de mesurer et de gérer le flux de travail en se basant sur des politiques explicites afin d’améliorer la collaboration et d’identifier avec précision les goulots d’étranglement dans ses processus. Nous avons commencé avec un tableau Kanban au mur pour faire le test. Ce fut un cauchemar absolu; l’image des membres de l’équipe se tenant devant le tableau maugréant devant la quantité d’ajouts à leur flux de travail régulier, avec des piles de cartes de travail dans leurs mains, restera toujours gravée dans mon cerveau. Le cycle de vie d’un élément de travail sur notre tableau Kanban est extrêmement faible : de 5 à 15 minutes. Résultat : l’équipe gère de multiples détails sans importance au lieu mettre son énergie dans ses flux de travail. En rétrospective, il était assez comique de voir combien anti-Agile cette première expérience était réellement. Il s’agissait en fait de la définition-même de perte de temps.

Ainsi, nous sommes retournés à la planche à dessin… littéralement. C’est comme ça que l’on est censé trouver notre chaîne de valeur, non? En dessinant des trucs sur un tableau. Cool. Nous avons re-cartographié notre flux de travail. Au cours de ces réunions, il est devenu évident que je n’avais pas entièrement démontré ce que Kanban pourrait faire pour l’équipe – être plus collaboratifs et plus efficaces, travailler plus intelligemment, et non plus dur. J’ai réalisé que j’avais commis une erreur dans mon approche initiale. J’ai incorrectement supposé que la valeur de Kanban serait évidente pour l’équipe. Ce que je n’ai pas pris en compte, c’est que l’équipe OPS avait déjà son propre flux de travail, qu’ils géraient d’une façon spécifique et quand nous avons ajouté Kanban au mélange, l’équipe a simplement ajouté Kanban comme une couche administrative au-dessus de leur flux de travail existant. Pourquoi? Parce que je n’avais pas réussi à introduire correctement Kanban à l’équipe, et par conséquent, ils ne pouvaient pas voir sa valeur, et y adhérer. Cette prise de conscience a pesé lourdement sur mon âme Agile. Donc, un soir, en regardant les épisodes enregistrés de Big Bang Theory avec ma femme, j’ai commencé à planifier mon flux de travail Kanban 2.0 (ou 3.0 si vous incluez le tableau au mur) et mon argumentaire de vente pour l’équipe WMC OPS. J’ai décidé que j’allais utiliser le jeu des points pour prouver à l’équipe OPS que Kanban était aussi cool que facile.

kanban2.0

Le plan Kanban 2.0

Il y a quelques mois, lors du Agile Tour Montréal 2012, j’ai participé à un atelier Kanban où le jeu des points était présenté. Ce jeu constitue une simulation d’un scénario de flux de production Kanban. Consultez ce document pour plus de détails : http://www.netobjectives.com/resources/articles/the-dot-game.

Je trouve que l’exercice fait un travail phénoménal pour ce qui est d’exposer le but et la valeur du Kanban de façon pratique, facile à comprendre et amusante. Je savais que le jeu des points serait critique afin de démontrer la valeur de Kanban pour l’équipe OPS, et je recommande fortement cette activité pour obtenir l’adhésion de toute équipe qui essaie de mettre en place un Kanban. La réponse de l’équipe OPS a été extrêmement positive. De nombreux membres de l’équipe ont affirmé qu’ils sentent maintenant qu’ils ont une bien meilleure compréhension de ce que Kanban est et comment ils peuvent l’utiliser à leur avantage.

C’était vraiment incroyable de voir à quelle vitesse l’équipe a amélioré son organisation générale et ses processus après seulement trois itérations de simulations de 5 minutes. L’équipe a rapidement reconnu à quel point la mise en place d’une limite de travail en cours réduisait la taille des lots de travail et leur a permis « d’arrêter de commencer et de commencer à finir » (un de mes clichés Kanban préférés que je ne pouvais m’empêcher d’injecter dans ce blogue). Le jeu des points a aidé l’équipe à comprendre l’importance d’avoir des politiques explicites, de la visualisation et des métriques, les fondements de Kanban. Et avoir l’occasion de réfléchir après chaque itération du jeu a provoqué un réel kaizen : l’équipe a développé une meilleure vue d’ensemble de son environnement de travail et des changements qu’ils pourraient apporter pour l’améliorer. Finalement, l’équipe a réalisé la nécessité de trouver un équilibre entre la demande et la capacité.

Vraiment? Ce simple exercice a enseigné tout cela à l’équipe? Oui, tout à fait, et l’équipe en récolte encore les fruits au moment où j’écris ceci. Du point de vue Agile, je pense que l’expérience de l’équipe avec nos deux premiers (échec) Kanaban a contribué au succès que nous avons avec Kanban aujourd’hui. Nous avons essayé, ça n’a pas fonctionné. Nous avons fait des ajustements et essayé à nouveau. Une des premières choses que j’ai apprises au sujet d’Agile est de ne pas avoir peur d’essayer et d’échouer, tant que vous apprenez de vos erreurs et que vous vous en servez pour vous améliorer!

WMCTEAM

L’équipe WMC

Par Sean Steacy
ScrumMaster

Comments

comments