Lessons from failure and secret to success

"Lessons from failure and secret to success" : non, ce n'est pas le titre d'un nouveau livre d'un gourou du marketing ou du management. Il s'agit d'un extrait d'une interview de Reinhold Messner. Si vous ne savez pas qui c'est, je vous laisse découvrir sur le net le palmarès incroyable d'un des plus grands montagnards de tous les temps. Ecoutez-le, ça ne dure que 3 minutes 25.

Reinhold Messner part 4: Lessons from failure from Rock & Ice on Vimeo.

En gros et très rapidement résumé, il dit que s'il a réussi ce n'est pas parce qu'il est plus fort que tout le monde, mais parce qu'il a :
- échoué de nombreuses fois (vous vous souvenez du droit à l'erreur ?)
- eu de bons partenaires
- partagé un objectif commun avec ces partenaires

Je crois que cette recette ne s'applique pas qu'à l'alpinisme...

Menuiserie agile : suite

Si vous êtes un lecteur assidu de ce blog, vous savez que je fabrique une pagaie traditionnelle de kayak, une pagaie groenlandaise. Cela m'avait inspiré un petit article sur la menuiserie agile.

Hier, j'ai travaillé à cette pagaie avec Gilles, un copain agile. Un artisan agile de ses mains. Ce matin, en me réveillant, j'ai repensé à cette journée. Voici comment nous avons travaillé.

Il a commencé à raboter la pagaie au rabot électrique. Comme je n'avais jamais utilisé cet engin, il a fait un des 4 cotés qu'il fallait tailler. En m'expliquant.

Puis j'ai fait le second. Sous le regard de Gilles, qui a corrigé mon geste et surveillé que je n'enlevais pas trop de matière, que je restais bien à plat, etc.

Nous nous sommes relayés pour les 2 derniers cotés, il m'a expliqué quelques astuces, etc. Puis idem avec le rabot à main.

Du mentorat, du "pair-raboting", quoi. 

Mais avant tout cela, qu'a-t-il fait ? Il s'est demandé comment on allait faire pour être sûrs de ne pas tailler trop. De ne pas dépasser le trait, qui était sur la tranche et qu'on ne voyait donc pas, en rabotant. Il a mis en place une sorte de test de validation, de garde fou. Une cale placée en bout de pagaie. Cette cale devait faire juste l'épaisseur voulue. Quand on rabote la cale, c'est qu'il est temps de s'arrêter... Ca a été son premier boulot : fabriquer une cale à la bonne dimension.

Produire l'outil de validation avant l'objet à créer, en quelque sorte... Amis développeurs, ça vous rappelle quelque chose ?

Une fois tout ça taillé, je considérais cette itération terminée, la suivante consistant à mesurer et tracer le profil de la pagaie. "On va se faire un thé ?". Que nenni ! Nous avons râpé, poncé et poli toute la pagaie. "Mais pourquoi faire ? Il va falloir encore la tailler dans tous les sens pour la profiler, ça ne sert à rien, de faire des finitions !". Réponse de Gilles, qui m'a laissé un rien pantois : "Toutes les petites imperfections que tu laisses, tu les retrouveras à la fin, et il sera difficile de les corriger à ce moment là". Amis développeurs, ça vous rappelle quelque chose ? (bis).

"Et en plus, tu seras plus à l'aise pour tracer la suite sur une pagaie bien lisse, bien propre". Ben oui.

Artisan développeur, ça a un vrai sens, non ?

Pratiques agiles pour tous

Suite à mon précédent article sur les méthodes agiles appliquées en dehors du développement logiciel, voici une liste de pratiques qui - d'après moi - peuvent être utilisées dans de nombreux contextes :
- Charte projet
- Story mapping, personas
- Backlog
- Pilotage par la validation
- Estimation relative, planning poker
- Itérations
- Conception au tableau blanc (quick design session)
- Carton, Conversation, Confirmation
- Binomage
- Radiateur d’informations
- “Prêt” et “Fini”
- Tâches choisies, auto-organisation
- Réunion quotidienne
- Revue
- Rétrospective
- ROTI
- Big Visible Charts
- Boite de temps (Time-boxing)
- Niko-niko
- Open space, forum ouvert
- Décision “au plus tard”
- Roue de Deming
- Perfection game
- Boite à Meuh


Tout ajout est le bienvenu...

Les méthodes agiles en dehors de l'informatique

Vaste sujet... Qui m'intéresse (voir ce qui est écrit à droite, là) et dont j'ai déjà parlé (ou dont je parle tout le temps ?) dans ce blog.
Et puis plusieurs échanges m'ont relancé sur ce sujet : une session à Agile Innovation,  et d'autres choses dont je vous reparlerai sûrement.

D'abord, ce n'est pas l'informatique qui a "inventé" l'agilité. Les origines semblent plutôt à chercher dans l'industrie dite 'lourde' (voir Lean, Toyota & co).
Mais qu'à cela ne tienne, bouclons la boucle, retournons tout ça et voyons ce qu'il est possible d'apporter à d'autres domaines.

J'ai repris le manifeste agile et les principes. Il y a des choses qui me semblent relativement faciles à transposer et d'autres moins.
Les faciles :

- privilégier les individus et les interactions plutôt que les processus et les outils,
- privilégier la collaboration avec le client plutôt que la négociation d'un contrat,
- privilégier la réponse au changement plutôt que le suivi d'un plan,

- bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail,

- la méthode la plus efficace pour transmettre l'information est une conversation en face à face,
- les gens de l'art et les développeurs doivent collaborer quotidiennement au projet
- une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité,
- la simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle,
- les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent,
- à intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens,
- les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

En résumé, tous les aspects humains : collaboration, confiance, communication et ceux liés à la qualité et la simplicité de ce que l'on réalise. Et ça peut s'adapter à tout, il me semble : création, construction, organisation d'événements, gestion de projets au sens large.

Les moins faciles :

- privilégier les logiciels qui fonctionnent plutôt que la documentation exhaustive,
- notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles,
- le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client,
- livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte
- un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet,

Un peu plus compliqué, là. Car le développement logiciel a des particularités : on peut travailler de façon incrémentale et itérative, ce qui n'est pas toujours évident dans d'autres domaines. Difficile de construire un bout de maison, d'y installer une famille pour qu'elle s'en serve et d'adapter la maison ensuite, en continuant de la construire, en plus.

Ce que l'on peut tirer de ces principes, c'est qu'il faut s'attacher aux réalisations concrètes, à la confrontation avec la réalité, et accepter le changement. Ca ne veut pas dire accepter de détruire la maison et de tout recommencer, mais ne pas rejeter le changement d'office.

Voilà pour les grandes lignes. Et dans un prochain post, j'essaierai d'identifier les pratiques agiles qui sont utilisables : standup meeting, rétrospective, etc.

Vite, un produit !

J'en ai déjà parlé plusieurs fois, y compris à Agile Grenoble : aller vite est important. Les story maps sont un très bon outil pour ça, pour identifier le "Minimum Viable Product", cher à Eric Ries (Lean Startup - un petit slideshare).

Une fois ce produit minimum identifié, il faut le réaliser et le mettre entre les mains d'utilisateurs. Et aujourd'hui, nous sommes bien outillés pour faire ça à peu de frais.

Le web regorge d'outils et d'API pour nous aider, sans tout refaire nous même. Il faut nous débarrasser de nos réflexes de développeurs, qui veulent toujours développer pour faire mieux, plus adapté, plus joli, plus 'comme-on-voudrait-que-ce-soit-pour-être-parfait'.

Un exemple : J'essaye de mettre en place sur aleaski un partage d'observations des conditions en montagne, faites par des gens de terrain : gardiens de refuge ou observateurs nivo-météo par exemple. Pas toujours facile de les convaincre et de leur faire comprendre ce que cela pourrait donner. Et pas simple pour moi de savoir si ça va fonctionner (peu de moyens techniques en montagne, peu d'internet dans les refuges, etc.)

Première étape : j'ai trouvé quelques (3) observateurs qui m'ont dit "pourquoi pas?". J'ai mis en ligne une observation fictive "en dur" (quelques lignes de javascript) pour leur montrer le résultat possible.
J'ai diffusé ça, pour avoir leur avis : "Oui, ce serait bien, mais ça va me prendre du temps, non ?". "Oui, c'est chouette, mais il n'y a pas Internet là ou je me balade".

Deuxième étape : j'ai mis en place une solution pour permettre à un observateur de s'enregistrer (c'est plus facile que de taper sur un clavier), de se localiser et d'envoyer tout ça au serveur d'aleaski. Tout ça depuis son iphone (ça tombe bien, il en a un - vous rigolez, mais n'oubliez pas de vérifier comment vos personas sont équipés).
Et tout ça avec moins de 500 lignes de code (merci les API Google). On va pouvoir désormais passer à la 3ième étape : de vraies observations, pour se rendre compte de l'intérêt suscité auprès des auditeurs potentiels.

Vous pouvez écouter Alain ici

Quand il y aura des dizaines d'observateurs et des milliers d'auditeurs, il sera temps de refaire tout ça, de développer une application spécifique sur l'iphone, de le faire fonctionner sous IE 4, etc.

Ou pas.