Illustration d'une organisation en "Silo" : l'effet Dalton

J’ai beaucoup aimé la présentation à propos du travail d’équipe de Henrik Kniberg lors de sa présentation « What’s Agile? » à l’agile tour 2009 de Grenoble :

L’esprit d’équipe ce n’est pas :

  • un travail en silo : où une à plusieurs personnes sont responsables de la production d’un sous ensemble de produit
  • un ensemble de personnes dans un open space : qui vont dans des directions différentes

Mais :

  • un ensemble d’individus qui poussent dans la même direction en même temps.

Pour illustrer la problématique du travail en silo voici une petite histoire que j’ai vue maintes fois.

Les personnages sont : Joe & William. Ils travaillent tous les deux à l’élaboration d’un même produit. Joe est responsable du module IHM et William de la partie « moteur métier ». Joe et William intègrent régulièrement leur travail sur le produit.

Un jour Joe découvre un bug! Il remue ciel et terre pour identifier le problème. Ouf, cela ne concerne pas son module d’IHM. Par professionnalisme, Joe continue d’investiguer et cible que le problème vient du module dont s’occupe William, il va même jusqu’à diagnostiquer précisément le problème et trouver une solution.

Joe va alors se confronter à plusieurs sources de perte de temps :

  • Ce n’est pas Joe qui est responsable du module « moteur métier ». Il ne peut donc pas corriger le problème lui même.
  • William est le seul à avoir une vision de l’ensemble du module.
  • Joe doit convaincre William que le problème est dans son module.
  • Joe doit expliquer à William la solution qu’il a trouvée.
  • William doit comprendre la solution que Joe a trouvée.
  • etc…

Bref je suis souvent témoin de cette pratique. Je suis déçu par tout ce temps et cette énergie gâchés. Pour moi, une organisation en silo favorise la culture de la faute et les réflexes qui vont avec au détriment de l’efficacité. L’individu est frustré car il n’a que la vision des silos qui l’entourent.

La responsabilité collective et le partage de compétences ont souvent mauvaise presse quant à l’efficacité; mais je reste persuadé que le temps et l’énergie dépensés dans la collaboration sont payants à moyen voire à court terme. Par contre le changement de culture nécessaire est parfois douloureux.

Retour d’expérience : histoire de la fonction PIPO…

On me demande souvent si les méthodes agiles sont plus performantes que les approches traditionnelles. C’est difficile de répondre à cette question mais je raconte souvent l’histoire suivante :

On avait deux produits A et B. Le produit A avait été jugé plus prioritaire que le produit B. Une partie des fonctions de A étaient réutilisables dans B.

En montant l’équipe Scrum sur le produit A, nous avions réalisé un « product charter » qui affichait les principaux jalons du produit dont le premier était un salon à Las Vegas. Les priorités des items du backlog étaient évaluées en fonction de ce salon.

A la 4ème itération, le product owner arrive en réunion de sprint planning et fait remonter la priorité d’un item qui était tout en bas du backlog pour qu’on le traite dans l’itération suivante. J’appelle cet item « la fonction PIPO » pour la suite de l’histoire 🙂.

Voici l’échange entre l’équipe et le product owner ce jour là :

Équipe : Tiens !? Pourquoi cet item remonte ? Il n’a pourtant rien à voir avec notre jalon n°1.

Product Owner : j’ai croisé « chef » qui m’a dit de vous faire implémenter cet item qui est très important pour une affaire basée sur le produit B.

Equipe : Le produit B ? Mais personne ne travaille sur ce projet. L’affaire est vraiment importante ?

Product Owner : Oui, la date est même antérieure à notre salon à Las Vegas.

En fait l’affaire du produit B était plus prioritaire que le produit A. Nous avons basculé toute l’équipe sur le produit B pour nous donner toutes les chances de réussir. Le produit B nécessitait beaucoup de travail d’intégration pour être livrable. On a eu juste assez d’itérations pour livrer le produit à l’heure et remporter l’affaire… sans la fonction PIPO !!!

Si nous n’avions pas été organisé en Scrum, nous aurions parallélisé les développements, développé la fonction PIPO et su que beaucoup plus tard qu’il fallait un gros effort pour produire le produit B. Je pense que ce jour là, cette façon de travailler a sauvé l’affaire.

Ce blog est agile !

L’objectif de ce blog étant de publier des réflexions et retours d’expériences sur la mise en place des méthodes agiles, j’ai envie d’essayer de mettre en place certaines pratiques dans la gestion de ce blog.

Voici ce que je mets en place :

  • Les utilisateurs du blog sont modélisés sur une page dédiée « Profils des utilisateurs« . Je choisis une page plutôt qu’un article car elle pourrait évoluer au cours du temps
  • Le backlog est accessible et mis à jour régulièrement ici

Plus tard  je voudrais :

  • Définir un modèle de valeur métier qui permettra de gérer les priorités des articles à publier
  • Mesurer un retour sur investissement fictif basé sur le nombre de commentaires postés sur les articles
  • Délivrer des articles toutes les semaines

En appliquant ces méthodes j’espère atteindre deux objectifs :

  • Augmenter la satisfaction utilisateur en publiant des articles pertinents
  • Donner un exemple pratique

Petite déception : un des gains qu’offre l’agilité réside dans le travail d’équipe et la communication. Comme je commence tout seul, une partie de la méthode ne peut être exploitée. Cela dit je suis prêt à faire un blog collaboratif  (faites moi part de votre envie participer dans la page feedback et suggestions).