Tag Archives: agilité

Jeudi dernier avait lieu une nouvelle édition du ScrumBeer Lille, organisée par Nord Agile et sponsorisée par Axa qui nous a accueilli dans les locaux de son Web Center. L’occasion, une nouvelle fois, de parler agilité, de partager nos expériences sur les projets et d’agrandir la communauté agile du Nord.

Une soirée sous le signe de la bière

De la bière dans les verres et sur les tables ! Après un petit discours introductif, nous voilà partis dans l’explication de l’activité de la soirée : le Beergame. Ce jeu simule la chaîne de production de la bière, depuis l’usine de fabrication jusqu’au détaillant qui livre les caisses de bières aux consommateurs finaux, en passant par le grossiste et le distributeur.

Le but de chaque acteur de cette chaîne est de minimiser ses propres coûts qui proviennent du stock et de l’en-cours (ou backlog) c’est-à-dire de toutes les commandes non honorées. Ainsi, chaque acteur doit s’occuper uniquement de son poste et ne peut pas communiquer avec ses voisins. A chaque tour, chaque acteur doit donc honorer les commandes qui lui sont faites (par les consommateurs finaux ou par un acteur de la chaîne) et essayer de prévoir la demande en faisant des commandes à son voisin.

Ah oui, dernière chose ! Pour ralentir les flux et compliquer un peu la situation, des délais sont introduits entre les entrepôts de chaque acteur et dans la transmission des commandes. Un peu comme dans la vraie vie !

Plateau Beer game

Le bullwhip effect

Si on a un détaillant un peu joueur, on se retrouve vite avec un gros pic de commandes lorsque la demande consommateurs finaux augmente légèrement, après quelques tours. Le temps que cette commande arrive à l’usine de fabrication, les commandes grossissent d’acteur en acteur et on assiste alors au phénomène du bullwhip effect. A cause des délais, les commandes gonflent et s’étalent aussi dans le temps. D’ailleurs, essayez de demander à la fin du jeu, à chaque acteur d’imaginer la demande client. Les résultats seront flagrants !

En effet, quand on est loin de la source, on ne peut pas communiquer et des comportements erratiques apparaissent. Chaque acteur commande beaucoup plus mais le temps que la commande arrive jusqu’au détaillant, des ruptures de stock se produisent, donc les acteurs commandent encore plus ! La situation devient insensée et finalement, tous les acteurs essaient d’agir localement pour résoudre un problème global. Mais au final, la qualité de service baisse grandement (le backlog grossit pour tous les acteurs) et les capacités de la chaîne ne sont plus du tout optimisées avec des coûts élevés.

 Le système induit les comportements

S’il y a une conclusion à retenir de ce jeu c’est que le système lui-même introduit les dysfonctionnements. Et pourtant, tout au long de la partie, on a l’impression que les problèmes viennent de nos voisins et on commence à les traiter de tous les noms, les jugeant incapables de prendre des décisions sensées et de bien faire la tâche qui leur est demandée. Désespoir et frustration sont le lot commun des derniers tours !

En réalité, il n’y a pas de coupable (eh oui, pour une fois le consommateur final est irréprochable et sait ce qu’il veut) mais c’est la structure du système qui est défaillante. Et les plus gros points de défaillance sont les suivants :

  • une communication entre acteurs inexistante
  • une optimisation locale (chacun essaye de minimiser ses propres coûts sans vision globale)
  • une structure qui présente de nombreux délais

En y regardant de plus près, on se rend compte rapidement que c’est à cette inefficience de l’organisation que l’agilité apporte des réponses. En réduisant au maximum les boucles de décisions et de retour, et en mettant l’accent sur la communication directe, les informations sont partagées par toutes les parties prenantes de la chaîne de valeur, les prévisions se construisent et s’affinent par l’échange et l’expérience, et finalement le rythme de tous est commun pour se concentrer sur l’essentiel : délivrer de la valeur au client final.

Encore un grand merci à Emmanuel Sciara (@esciara) et à Thomas De Clercq (@ThomasD59290) pour nous avoir fait découvrir le jeu et pour avoir animé les différents plateaux de jeux. On vous donne rendez-vous le 15 avril prochain à l’ISEN pour un nouvel évènement autour de l’agilité (un post sera bientôt publié pour vous donner l’eau à la bouche).

 

Jean-Baptiste pour Nord-Agile

 

N.B. : si vous voulez devenir des experts du BeerGame et reproduire le jeu dans votre entreprise ou chez vous, vous pouvez jeter un coup d’oeil au portail dédié au jeu et au document synthétique de l’université de Munster (en anglais) qui constitue un bon guide pour animer avec brio ce jeu.

On fait souvent le constat, nos pratiques en entreprise ne sont pas homogènes, nos expertises sont souvent réparties et peu connues, nos expérimentations et expériences ne servent souvent qu’à nous même.

Qu’elle soit technologique ou méthodologique, vient souvent l’idée de créer une communauté. Un regroupement des gens ayant « envie », travaillant dans le même domaine, mais répartis à travers différents projets, différentes équipes. Il « suffit » d’un forum, d’un blog, d’un intranet, de quelques heures par mois pour se rencontrer, partager et capitaliser !

Mais force est de constater que souvent ces communautés échouent, oui mais pourquoi ?

 

Ayant eu récemment avec Ben, l’envie de créer une communauté Agile en interne, j’ai donc  posé la question au ScrumBeer (ça tombait bienJ).

Pour répondre à cette question, par jeu, et de façon à distinguer mon contexte, nous sommes partis de la question inverse. Le côté Obscur permet parfois de mettre en avant la lumière.

La question centrale est donc devenue :             ” Comment faire échouer une communauté ? ”

comment échouer

 

Nous avons ensuite par rapport à mon contexte d’entreprise focaliser sur un axe : Manque de vision.

Pour cela nous avons abordé le concept de « Leadership Emergent ».

whywhohowwhat

 

Plutôt que de me focaliser sur les actions que j’attends de la communauté : le What, et essayer de les porter ou pire de forcer les gens à prendre ces actions, je dois me concentrer sur communiquer le « sens » de la communauté. Par exemple « Elever le niveau de maturité des équipes agiles » à détailler ensuite de façon plus mesurable.

En expliquant le sens du « Why » de façon claire et mesurable, on peut provoquer auprès des membres de la communauté « Who » une adhésion et par eux même ils chercheront comment « How » apporter des actions concrètes : « What ».

A l’initiative de cette communauté, je dois donc me concentrer non pas sur les actions concrètes que je souhaite que ces membres mettent en œuvre, mais sur le fait de transmettre le sens de son existence, de la façon la plus mesurable et concrète possible.

 

Merci Thomas