Découvrir le manifeste agile en jouant

A Agile Grenoble, j'ai animé avec Laurence Hanot "Dis monsieur, c'est quoi être agile ?", une session pour faire découvrir l'agilité au travers de 4 jeux : un par valeur du manifeste.
L'idée vient de Vincent Daviet, qui en avait parlé à Agile Innovation Lyon. Allez visiter son blog : http://babagile.tumblr.com/. ("Un chef de projet, c'est celui qui pense qu'avec 9 femmes on fait un bébé en 1 mois", j'adore.)

Et le lendemain, à Agile Innovation, on a remis ça. On a notamment testé le jeu du "gouter d'anniversaire" que nous n'avions pas eu le temps de faire la veille.
J'avais promis de partager tout ça, c'est (enfin) fait !

Chaque jeu dure 10 minutes, suivi de 5 minutes de discussion, l'objectif étant de tout faire en 1 heure. A vous d'adapter, bien sur.

1 : Le noeud humain - Individus et interactions > Processus et outils

Le jeu le plus simple et le plus rapide à réaliser. Et il fonctionne à chaque fois !

Deux groupes (Peu importe la taille, je pense. Nous avons fait 2 groupes de 8) et un "chef". Manager, chef de projet, chef d'équipe, donnez lui le nom que vous voulez.
Pour que ça fonctionne encore mieux, faites le sortir de la pièce pendant que vous préparez le noeud.

Dans chaque groupe, faire deux rangées, les participants se font face à face. Un dessin vaut mieux qu'un long discours :

Voilà, c'est prêt. Faites entrer le chef. La consigne est la suivante :

- Groupe 1 : "Vous ne faites que ce que le chef vous dit. Pas d'initiatives, surtout ! Suivez la procédure..."
- Groupe 2 : "Débrouillez-vous."


L'objectif : dénouer le noeud sans lacher aucune main et former un cercle où tout le monde se fait face.

En général, il faut quelques secondes au groupe 2 pour réussir, tandis que le groupe 1... Arrêtez-les au bout d'un moment si vous ne voulez pas y passer une heure !

Vous pouvez corser le jeu en ajoutant un analyste, qui va rédiger un document décrivant comment défaire le noeud et qu'il va donner au chef d'équipe qui va faire exécuter ce qui est écrit.

Bref, une équipe auto-organisée, c'est plus efficace.

2 - Artistes et spécifieurs version courte - Logiciel opérationnel > Documentation exhaustive.

Faites plusieurs petits groupes (4 personnes max ?). Dans chaque groupe, il y aura des spécifieurs et des artistes. Mettre les spécifieurs et les artistes dans des pièces différentes.

Le principe : vous montrez aux spécifieurs un dessin, ils doivent écrire des instructions pour que les artistes (qui n'ont pas vu le dessin) le réalisent. Et interdiction de se parler.

Ce jeu est habituellement réalisé en faisant plusieurs itérations, avec rétrospective entre chaque. Et il dure longtemps.

Ici, nous allons le faire en 10 minutes.

Pour la moitié des groupes, scénario classique : ils ont 10 minutes pour rédiger les instructions et dessiner. Souvent, les artistes ne reçoivent les instructions que 2 minutes avant la fin, et ils n'y comprennent rien...

Pour l'autre moitié : ils ont aussi 10 minutes au total, mais ils peuvent faire plusieurs aller-retours : ils rédigent une partie, la donnent aux artistes. Puis ils récupèrent le dessin réalisé et ils ont le droit d'annoter celui-ci. Attention, ils n'ont pas le droit de dessiner, ils peuvent juste écrire et faire des flèches. Ensuite, ils rapportent le dessin annoté et d'autres instructions aux artistes, qui recommencent le dessin.
Et ainsi de suite...

Il faut un dessin facile à dessiner, mais difficile à expliquer. Du genre de celui-ci :

Nous avons pas mal discuté après ce jeu, c'était très intéressant, les participants avaient ressenti beaucoup de choses.

3 - Le goûter d'anniversaire - Collaboration avec le client > Négociation d'un contrat

Nous n'avons pas eu le temps de faire faire ce jeu. Mais nous l'avons testé à Agile Innovation, et c'était intéressant, même si ça reste à améliorer.

Principe : vous (l'animateur) avez besoin d'un prestataire pour organiser le goûter d'anniversaire de votre fils qui a 10 ans et qui veut inviter une dizaine de copains.

Ce que vous demandez au prestataire de prendre en charge :

- Les invitations
- Le plan d'accès
- Les achats
- La décoration
- Le(s) gateau(x)
- Une chasse au trésor
- Un plan B : des jeux d'intérieur en cas de mauvais temps

Deux groupes :
- le premier peut vous poser une seule question (puis vous partez)
- le second peut échanger avec vous (le client) durant toute la durée du jeu (vous vous asseyez à leur table).

Ils ont 10 minutes pour vous donner un devis détaillé.

Nous avons testé ce jeu 2 fois seulement, mais les 2 fois :
- les joueurs du groupe 2 ont très peu impliqué le client (vous), ils ont très peu profité de sa présence.
- le groupe 1 a fourni un devis largement supérieur au groupe 2

J'avais déjà utilisé ce jeu pour présenter le planning poker, il s'y prête bien car il y a plein d'interprétations différentes et des compétences diverses ("le gateau, on l'achète ou on le fait ?").

4 - Marshmallow challenge - Adaptation au changement > Suivi d'un plan

Le classique marshmallow challenge, mais en 10 minutes seulement. Pas de temps de préparation, vous distribuez le matériel à chaque groupe et en avant !

Où est le changement et le plan ? La plupart du temps, il y a une chose qui ne se passe pas comme prévu. Il y a un truc qui n'a pas la caractéristique prévue.



Cette session a visiblement été appréciée, cf. le ROTI :

Voilà, testez et faites nous part de vos expériences !

La métaphore de l'ampoule

L'entreprise X

L'entreprise A(gile)

Agilité et culture française : argh...

L'année dernière, j'avais publié un article sur la distance hiérarchique, et la publication aujourd'hui par Jean-Michel Legrand et Eric Le Merdy de Valtech de leur présentation "Et si l'agilité commençait finalement par Kanban ?" me remet tout ça en tête et me donne envie de le partager avec vous.

Geert Hofstede a travaillé sur les différences de culture entre les pays, et sur l'impact que cela a sur le monde du travail.

Il distingue 5 critères :

- La distance hiérarchique (PDI)
- L'individualisme et le collectivisme (IDV)
- La dimension masculine/féminine (MAS)
- Le contrôle de l'incertitude (UAI)
- L'orientation court terme/long terme (LTO)

Il y a de grandes différences entre les pays (vous pouvez voir tout ça sur son site). J'ai pris l'exemple des USA et du Danemark, pour comparer avec la France :

Pour faire bref, en France nous avons :
- une forte distance hiérarchique
- une forte volonté de contrôler, d'éviter les incertitudes. Nous avons un des plus hauts scores sur ce critère !

Ce qu'en dit Geert Hofstede :

Sur la distance hiérarchique :
"With a score of 68, France scores high on the scale of the PDI. It is therefore a society in which inequalities are accepted. Hierarchy is needed if not existential; the superiors may have privileges and are often inaccessible.
The power is highly centralized in France, as well as Paris centralizes administrations, transports etc.
In management, the attitude towards managers is more formal, the information flow is hierarchical. The way information is controlled is even associated with power, therefore unequally distributed."
Sur l'incertitude :
"At 86 France has one the highest scores on the UAI Index. Certainty is often reached through academic work and concepts that can respond for the need of detail, context, and background. Teachings and trainings are more deductive. In management structure, rules and security are welcome and if lacking, it creates stress. Therefore planning is favored, some level of expertise welcome, when change policies on the other hand are considered stressful."


Voici un des schémas de Jean-Michel Legrand et Eric Le Merdy :

Tout ça n'est pas facile à concilier avec l'agilité qui à tendance à minimiser l'importance de la hiérarchie et des procédures et qui favorise l'empirique face au prédictif (voir mon article "Tout prévoir ou composer avec l'incertitude ?" qui parle d'agilité, d'avalanches et de tremblements de terre).

L'agilité en France, difficile :-(

Agile Tour Marseille 2012

Ce que j'ai ramené d'Agile Tour Marseille, qui s'est déroulé hier :

Comme d'habitude dans ce genre d'évènement, plein d'énergie positive, d'entrain, d'enthousiasme. Rien que pour ça, ça vaut la peine d'y aller !

Un regret : moins de 100 personnes présentes, c'est vraiment peu pour une ville de la taille de Marseille... A comparer aux 500 personnes habituellement présentes à Grenoble ! Les marseillais moins réceptifs à l'agilité ?

Bonnes synthèses de Thomas Lissajoux sur le management visuel d'une part et sur les changements culturels apportés par l'agilité, d'autre part. Quelques notes :

Plein les yeux !!! - Développer le management visuel
Pour "rendre évident" et partager l'info. Il faut que l'information affichée soit
- facile à comprendre,
- visible pour tous,
- interactive et facile à modifier ou au moins à commenter

Mais d'abord, pensez à l'intention : qu'est ce que vous voulez mettre en évidence, rendre visible ? et pourquoi ?

Ensuite, soyez créatifs !

"Le management visuel, c'est une fenêtre sur le fonctionnement du système". C'est aussi un "espace de compréhension commune".


Transitions agiles - culture du changement ou changement de culture ?

"La culture, c'est tout ce qu'on fait sans le dire".

Les changements culturels liés à l'agilité, créateurs de tension :

prédictif / empirique

spécialisation / coordination

responsabilité individuelle / collective

orienté coûts / résultats

conformité / expérimentation

N'oubliez pas vos développeurs ! 
Xavier Nopre a bien résumé les pratiques et outils d'ingénierie indispensables.

Je ne vous fait pas de résumé, pour en savoir plus allez le voir à Agile Grenoble en novembre !


Le développement piloté par les tests
Quand à moi, j'ai parlé du TDD pour expliquer à ceux qui débutent pourquoi il faut en faire.  Ma présentation est accessible, mais sans le code Javascript associé, sorry...

Merci aux organisateurs et rendez vous à Grenoble !

Tout prévoir ou composer avec l'incertitude ?

L'été est fini, il serait temps que je publie quelque chose sur ce blog...
Et ça tombe bien, j'ai entendu des choses très intéressantes à l'International Snow Science Workshop d'Anchorage il y a une dizaine de jours.

A ma grande surprise, je n'ai pas été le seul à parler agilité puisque Grant Statham (Parks Canada Agency) m'a précédé.

Grant Statham, à propos du système de prévision Canadien

Mais surtout, j'ai pu constater des similitudes entre l'agilité et l'orientation prise par certains responsables de la sécurité en montagne. J'explique.

Jusqu'à maintenant, l'essentiel des efforts a porté sur la prévision, la prédiction des avalanches. Où et quand vont-elles se déclencher ? La Science s'est penché sur le problème, on a étudié et modélisé. Et hop, le tour est joué, il n'y a plus qu'à dire au Modèle quand est-ce qu'il a neigé, quelle température il a fait et d'où le vent a soufflé et on obtient une carte des avalanches qui vont se produire demain, en fonction de l'itinéraire choisi.

Euh... non, ça c'est dans nos rêves.

Car en fait, ça ne fonctionne pas. On ne sait pas prévoir précisément les avalanches. Et on est en train de s'en rendre compte. De s'apercevoir que La Science "classique", celle des maths et de la physique, ne peut pas tout...
Un peu comme dans le monde du développement logiciel, où l'on croit savoir prédire les fonctionnalités nécessaires, les performances que l'on obtiendra et le temps qu'il va falloir pour développer.

Mais non, ça ne marche pas. Il n'y a pas de recette, simple ou compliquée, pour prévoir cela. Que ce soit pour les avalanches ou pour le développement, il y a trop de paramètres et parmi eux - les plus complexes peut-être - des facteurs humains...

Mais alors, comment faire ? Il faut apprendre à composer avec l'incertitude et à diminuer celle-ci au fur et à mesure que l'on dispose d'informations. D'informations sur la situation actuelle, au moment et à l'endroit où l'on est - ou bien sur le projet sur lequel on travaille. Et pas de généralisation ! Les scientifiques des avalanches parlent de variabilité spatiale. Dans l'informatique, on dit que chaque projet est différent (Vous ne le dites pas ? Vous devriez...)

Comment composer avec l'incertitude ? Par exemple, en travaillant avec la vélocité (indication de ce qu'une équipe a été capable de réaliser jusqu'ici) et non avec des estimations en jours/homme faites on ne sait trop comment (enfin si, on sait bien comment). Ou encore en modifiant son itinéraire (son plan, quoi) en fonction des changements ou de nouvelles informations.

Ce qui devient alors primordial, ce n'est plus Le Modèle, mais la collecte d'informations sur la situation actuelle et la communication de celles-ci à tous ceux qui sont impliqués. Et la prise de conscience de l'incertitude. Un homme averti en vaut deux.

Il n'y a pas que les avalanches et le développement logiciel qui sont concernés, d'ailleurs. Il semblerait que certains sismologues ont renoncé il y a peu à prédire les tremblements de terre (merci Ievgueni pour l'info). Et qu'ils mettent désormais l'accent sur la détection et la diffusion de l'information en temps réel.

Etre averti au plus tôt des problèmes pour pouvoir réagir et limiter leurs conséquences...





Et encore merci à Alain et www.data-avalanche.org de m'avoir permis d'être à Anchorage !

Tout a changé # 2

Les organisations et les hommes ont changé. Ou plutôt les hommes changent, et les organisations ne peuvent pas l'ignorer et continuer comme si tout était comme avant.

La prise de conscience du rôle que chacun peut et souhaite jouer au sein de l'entreprise, le besoin de réaliser des choses dont on puisse être fier, le refus de la médiocrité qu'on essaye de nous imposer, tout cela se concrétise par de multiples initiatives : le nombre d'évènements réunissant des développeurs ne cesse d'augmenter (ainsi que leur fréquentation) : Agile [lisez ici le nom de votre ville], Mix-It, Devoxx, JUG, etc.

On y parle technique, mais on y parle aussi qualité du travail, création d'entreprise, fierté, etc. Le mouvement Craftsmanship est un autre exemple.

Une bonne illustration de tout ça, en 5 minutes : "La voie du programmeur", par Jean-Baptiste Dusseault.

Et les organisations dans tout ça ? Beaucoup se sentent dépassées. Ou pire, ignorent ces changements.
Elles sont encore dans un mode pyramidal traditionnel, même si elles s'en défendent parfois.

Comment prendre en compte ces changements ? L'entreprise a besoin d'être révolutionnée.

De la même façon que - dans d'autres secteurs - les producteurs se rapprochent des consommateurs et suppriment les intermédiaires pour le plus grand bénéfice des deux, les développeurs et les utilisateurs doivent travailler ensemble, et de façon autonome.

Ce qui ne marche pas :

Ce qui marche :

La pyramide traditionnelle doit être inversée et les développeurs-producteurs doivent collaborer avec les utilisateurs-consommateurs.

Et le management ? Il doit être au service de ceux qui créent le produit (développeurs et utilisateurs). Il doit les soutenir, les former, les aider, lever les obstacles, bref : leur faciliter la vie ! (et non leur compliquer...).

Tout a changé # 1

Et ça va continuer...

Le monde du développement informatique est en pleine révolution. Ce qui se passe en ce moment n'est pas juste un des changements habituels dans ce milieu.
En tout cas, c'est mon avis. Pourquoi ?
Parce que tout a changé :
- les hommes et les organisations : les structures pyramidales s'essoufflent, place à la souplesse !
- les méthodes : il faut aller vite et être bon. Et être prêt à changer en permanence.
- les technologies : fini les réseaux d'ordinateurs relié à un serveur d'un coté et Internet de l'autre. Nouveaux terminaux, cloud, internet des objets, où sont les traditionnels ordinateurs ?

Cet article est - je l'espère - le premier mais pas le dernier consacré à ce sujet. Il y a beaucoup à dire.

Un exemple : avant il y avait 2 mondes : les ingénieurs et les développeurs web. Les premiers fiers de leurs connaissances en architectures ou en assembleur, qui évitaient le javascript et qui - bien sûr - connaissaient HTML et CSS (c'est pour mettre de la couleur, non ?). Les seconds considérés par des bidouilleurs par les premiers, et qui trouvaient que devoir compiler un fichier avant de l'utiliser ou décider une fois pour toute du type d'une variable, c'est lourdingue.

Et maintenant : ces deux mondes sont en train de fusionner.
Une application (on ne dit plus logiciel, vous avez remarqué ?) est forcément sur le web. Et quelle est une des compétences clés ? Comprendre la façon dont un navigateur dispose les éléments HTML dans le flux à l'aide du CSS associé. Oups... mais ils n'y comprennent rien, les ingénieurs, à ça.
Un site web ne peut plus être une page de pub. Il doit être intelligent, utiliser plein de données, permettre à tous de collaborer, etc. Et il faut une application mobile ? Ecrite en quoi ? Ouhlala mais c'est compliqué ça ! Maitriser HTML et CSS, faire un peu de JQuery ne suffit plus.

Je vous le dis, ma bonne dame, ça n'est plus comme avant...

Holoptisme !?

Un peu dur, comme nom. Mais si l'agilité ou l'intelligence collective vous intéresse, vous devez savoir ce qu'est l'holoptisme !

Heureusement Jean-François Noubel (www.thetransitioner.org) l'explique très bien :


Jean-François Noubel : "C'est quoi l'Holoptisme ?" from Christophe Ducamp on Vimeo.

Alors, vous êtes plutôt holoptisme ou panoptisme ?

Et je vous conseille d'ailleurs de lire "Intelligence collective, la révolution invisible" du même Jean-François Noubel (une quarantaine de pages, en français, vous allez y arriver, non ?)

Extraits de ce document (qui date de 2004) :


"Les organisations fortement hiérarchisées sont évidemment celles qui opposent la plus farouche
résistance à la philosophie de l'Intelligence Collective, attachées qu'elles sont à leur corporalité
fondée sur les territoires et le contrôle. La seule question de la "participation" (concertation,
collégialité, consensus, transversalité, communautés de pratique…) induit un sentiment de perte
de pouvoir de ceux qui le possèdent, ainsi qu'une remise en cause de leur légitimité d'expert, ce
qui aboutit souvent à des actes manqués lorsque les politiques d'évolution vers plus d'intelligence
collective s'avèrent ambitieuses sur le papier."

Et je vous laisse découvrir ce qu'il dit sur la monnaie ou la démocratie.

Agilité à la télé !

Ca n'est pas si fréquent, alors ça mérite d'être signalé : on a parlé agilité à la télé ! Bravo OCTO !

J'avais écrit sur Great place to work en juin 2011 ?, vous vous souvenez ?

Là ça n'est pas sur mon blog, c'est sur France 2, le 07/02/2012 :

The End of Management, Allan Murray

Cet article d'Allan Murray est très intéressant. Bon, je sais, il est un peu long et en anglais. Mais ça vaut le coup, vraiment.

Je ne connaissais pas Allan Murray, il semble que ce soit un monsieur reconnu et important... Pas un gauchiste anarchiste révolutionnaire illuminé, quoi. Et s'il dit que le management, et au-delà, les entreprises, vont sur leur fin, il doit avoir quelques arguments.

Quelques idées que j'ai glanées dans son article et les réflexions qu'elles m'ont inspirées :
Les entreprises telles que nous les connaissons - où management est le maître mot - n'ont pas toujours existé ! Il s'agit d'une innovation du XXième siècle, qui pourrait bien disparaître au XXIième.
Pourquoi ? Parce qu'elles ne sont pas adaptées aux conditions actuelles (globalisation, innovation rapide, concurrence acharnée).
Par le passé, les entreprises "leader" ont manqué les innovations de rupture (micro-informatique, photo numérique, téléphonie mobile, etc.) pas à cause d'un mauvais management, mais au contraire parce qu'elles appliquaient à la lettre les principes d'une bonne gouvernance d'entreprise - comme on dit aujourd'hui. Les innovations sont venues de gens ou d'organisations en rupture avec tout ça.

"Corporations are bureaucracies and managers are bureaucrats".

Ce qui a mené à la création de grandes entreprises n'est plus nécessaire aujourd'hui, c'est même un handicap.

"Even the most starry-eyed techno-enthusiasts have a hard time imagining, say, a Boeing 787 built by "mass collaboration." Still, the trends here are big and undeniable."
Nous ne sommes qu'au début de la collaboration de masse et une nouvelle forme d'organisation est à inventer. A moins qu'elle soit en train de naître, sans que l'on s'en rende vraiment compte ?

"The new model will have to instill in workers the kind of drive and creativity and innovative spirit more commonly found among entrepreneurs. It will have to push power and decision-making down the organization as much as possible, rather than leave it concentrated at the top. Traditional bureaucratic structures will have to be replaced with something more like ad-hoc teams of peers, who come together to tackle individual projects, and then disband."
Oui ! Des organisations souples et temporaires, adaptées !

Je rejoins tout à fait cet article sur cet aspect : des hommes indépendants qui se regroupent pour un projet donné, s'organisent de la façon la plus adaptée au contexte, et partent vers d'autres horizons ensuite. Des collaborations selon les affinités, les opportunités. Des relations adulte-adulte et non parent-enfant, comme il y en a tant dans nos entreprises. Pas d'organigramme, de tableaux de bords, de réunions de management, d'entretiens, de plans quinquennaux, de procédures que personne ne lit...

Vite ! "The old methods won't last much longer."