Ponts et Hiérarchies

Mark McLoughlin a donné la Keynote Red Hat, au matin du second jour du Sommet Openstack de Vancouver.
Dans l’après-midi, il a donné une session plus intimiste à propos de la gouvernance du projet Openstack.
L’idée principale est qu’avec Le nouveau modèle d’organisation Grande Tente qui va permettre l’émergence de nouveaux projets, il pourrait être temps de redéfinir les valeurs principales du projet qui permettront aux contributeurs de prendre de bonnes décisions.

Mark commença son propos par une référence à la Keynote que Eben Moglen a donné à Auckland lors de LCA 2015. Dans cette keynote, Eben Moglen explique que le modèle d’organisation hiérarchique que nous connaissons tous, est le modèle du 20ème siècle, et que les organisation du 21ème siècle seront basées sur la transparence, la participation et une collaboration non-hiérachique, comme le sont les logiciels libres.

Mark a continué son introduction avec une référence au billet de Andy Hunt, The Failure of Agile. Andy Hunt est un des rédacteur du manifeste agile, aussi on peut le prendre au sérieux comme il s’agit d’en parler. Le point principal de son article est qu’un grand nombre de personnes ont divergé de l’agile en se focalisant sur les pratiques, oubliant les valeurs et principes agiles. Ils sont focalisés sur faire de l’agile, et oublient que en fonction de son expérience, un débutant a besoin de directives claires pour comprendre comment fonctionne les choses et qu’au fur et à mesure de son expérience et du développement de ses compétences, il aura besoin de coaching, puis de support et deviendra ensuite pleinement autonome et aura adapté les pratiques initiales sur le chemin en vivant les valeurs et principes agile.

Cela m’a remémoré les auto-collants que j’avais imprimé pour une conférence :
sticker-agile-tour-2013-v2
Lorsque je les avais reçu, je m’étais dit… Humm… J’aurais du aussi barrer le « be » et le remplacer par « learn » car apprendre est réellement ce que nous faisons…

Donc Mark a proposé 4 idées principales qui pourraient devenir les principes auxquels se référeraient les contributeurs à Openstack :

divers intérêts, une vision partagée, basée sur le consensus
les individus et leurs interactions plutôt que les processus et les outils
le leadership au travers de l’autonomisation, l’empathie et la confiance
toute les avancées doivent ultimement provenir d’itération de bas en haut

Je vous encourage à regarder son intervention pour en savoir plus.

Richard et l’Open Source…

rms-bwConnaissez-vous cette personne ?

Il s’agit de Richard Stallman, l’initiateur du mouvement du logiciel libre (le mouvement gnu  fête ses 30 ans cette année).

J’utilise cette photo de Richard Stallman dans une présentation que j’ai donnée à plusieurs occasions (AgileTour Brussels, Open World Forum, French Scrum User Group…). Cette présentation est intitulée : « The Agile and Open Source Way« .

Lorsque l’image de Richard Stallman s’affiche, je demande aux participants si ils connaissent cette personne. En fonction de l’auditoire, le nombre de mains levées est variable. J’explique alors pourquoi Richard Stallman n’apprécierait probablement pas d’être associé à une présentation parlant « Open Source » et j’encourage les participants à lire l’excellent article : « Why Open Source misses the point of Free Software » ou en français : « Pourquoi l’« open source » passe à coté du problème que soulève le logiciel libre« . Pour résumer, on pourrait dire que l’Open Source s’intéresse aux avantages pratiques que procure les 4 libertés (qualité, fiabilité, performance…), en mettant de coté les valeurs morales du logiciel libre.

J’utilise cela pour établir un parallèle avec ce qui se produit depuis la publication du manifeste agile en 2001. Certains s’intéressent aux valeurs et principes du manifeste agile, d’autres à certaines pratiques des méthodes agiles, permettant la satisfaction des utilisateurs, une meilleure qualité, une meilleure prédictibilité…

La différence que l’on pourrait faire entre « Faire de l’agile » et « Être agile ».

 

Merci à Pascal de m’avoir fait remarquer que la présentation publiée ne permettait pas de comprendre cela et nécessitait une clarification sur les intentions.