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 !