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.

Story Map : commentaires et exemple

Voilà, comme promis, une version plus complète de ma présentation sur le story mapping. Avec mes commentaires et un exemple.

Story map : objectif feed back (version longue)

Ma story map finale comporte une 'erreur' : le contenu de la première itération n'est pas optimal, à vous de jouer ! Faites vos commentaires, corrigez, critiquez, suggérez !

Merci !

Agile Grenoble : bilan #2

Quelques extraits que j'ai pu glaner au cours de ces 2 jours (Agile Grenoble et Agile Innovation) :

- La conception, ça se fait après le développement et ça s'appelle du refactoring. Voir la présentation de Laurent Bossavit, de l'Institut Agile.

- Le backlog produit dans Excel, en liste : on n'y comprend rien, sauf si on l'a écrit soi-même. Mack Adams.

- Si on demande qui va gagner, c'est que quelqu'un va perdre.  Mack Adams, encore.

- Un musicien ne passe pas sa vie en concert, il s'entraîne la plupart du temps. Et un développeur qui passe sa vie à produire, il s'entraîne quand ? Thierry Cros.

- La valeur : un système complexe, piloté par le "why" (voir Karl Scotland : "Les gens n'achètent pas ce que vous faites mais pourquoi vous le faites"),  ce qui lui donne du sens. Signé : les participants à la session "Qu'est ce que la valeur", avec Rémi Sanlaville.

Session Open Space sur le TDD en JavaScript, avec Jean-Michel Garnier

C'était vraiment bien (surtout Agile Innovation !), des rencontres très intéressantes, tout ça est très stimulant, vivement la prochaine fois !

Agile Grenoble : bilan #1

J'ai animé avec Laurence Hanot l'atelier "Story map : objectif feed-back". Ci-dessous la présentation que nous avons utilisée (merci à Céline pour les jolis post-its !)

Story map : objectif feed-back

Merci à Laurence de son aide, et merci à tout le staff d'Agile Grenoble !

Je suis plutôt content de cette première expérience d'intervention dans une manifestation agile, c'était intéressant et instructif. Bon, 55 minutes c'est trop court pour ce type d'atelier, un Kata aurait été plus adapté. Et puis nous étions nombreux... Je vais publier prochainement ici un peu plus d'infos sur ce que j'ai dit lors de cet atelier.

J'ai appris par Mack Adams que Jeff Patton préparait un livre sur le story mapping, bonne nouvelle !

Agile Grenoble, c'est demain !

Demain, j'anime avec Laurence Hanot l'atelier "Story Map : objectif feed-back !".

De quoi nous allons parler ? De story map, bien sur, mais surtout de vitesse. La vitesse est importante, elle entretient la motivation et la vision. Et une story map est un bon moyen d'aller vite.

Par aller vite, j'entend "livrer rapidement aux utilisateurs une première version du produit".

On en parle demain ? Vous n'y serez pas ? Vendredi, alors, à Agile Innovation ? Non plus ? Alors rendez vous ici dans quelques jours...

Menuiserie agile

Après en avoir essayé une, j'ai décidé de me fabriquer une pagaie groenlandaise. Ce n'est pas tout à fait comme développer un logiciel. C'est un peu plus compliqué de recommencer quand on s'est trompé. Ou alors il faut être prêt à gâcher beaucoup de bois...

Alors j'ai fait un plan. Avec des mesures et tout. Vite fait, mais fait quand même. Je me suis servi d'indications trouvées sur internet. Et bonne nouvelle ! Celui qui a rédigé ce "manuel pour faire une pagaie traditionnelle" est un menuisier agile !

Pour construire sa pagaie, il faut tenir compte d'éventuelles erreurs de mesure ou de coupe, mais surtout, surtout, une pagaie traditionnelle doit être adaptée à la morphologie de son utilisateur. Et là, pas de recette miracle, il faut... tester !

Il conseille donc de tailler une pagaie un peu trop grande et trop épaisse, puis de faire des essais et de rectifier ensuite...

En avant pour l'itération 1 de ma pagaie !

Des logiciels et des hommes. Part Two

Un sujet récurrent dans le développement logiciel, c'est l'architecture.

Il y aurait de bonnes et de mauvaises architectures. Ou plutôt, il y aurait des architectures bien adaptées à tel ou tel produit ou environnement technique, et d'autres qui le seraient moins.

Mais est-ce l'essentiel ? N'oublierait-on pas quelque chose ?

Imaginons que je veuille construire ma maison moi-même. J'étudie tout ça, me plonge dans différents ouvrages ou sites sur le sujet, puis je décide finalement de construire une maison bio-climatique, avec toutes les caractéristiques qu'une maison du XXI° siècle devrait avoir. Je conçois la maison idéale. La maison avec la bonne architecture.

Bon il n'y a plus qu'à la fabriquer, alors. Oups. Moi, en dehors de clouer quelques planches... Heureusement, mon cousin m'a dit qu'il m'aiderait. Il est maçon. Le hic, c'est que ma maison à l'architecture parfaite, elle doit être en bois et en paille... Et puis mon cousin, tous ces trucs bio-machin... Lui, il monte des parpaings.

La bonne architecture, c'est un compromis entre l'architecture "idéale" et celle que l'on est capable de réaliser. Et surtout celle qui reçoit l'adhésion de ceux qui vont l'implémenter, "pour de vrai" !

La bonne architecture, c'est celle que l'équipe "sent" le mieux. Pas celle impos.. pardon, proposée par l'architecte en chef ou je ne sais quel expert.

Et vous savez quoi ? Il y a une méthode infaillible pour qu'une équipe adhère à une architecture. C'est qu'elle la définisse elle-même...

Et vous savez quoi (bis) ? Si cette équipe a des compétences variées, des jeunes prêts à tout changer, des vieux expérimentés (ou l'inverse) et que tout ce monde a envie de réussir... ils trouveront certainement l'architecture idéale.

Des logiciels et des hommes. Part One

Des logiciels et des hommes. Ben oui. Les logiciels sont faits par des hommes et, la plupart du temps, pour des hommes.

Et d'où sortent ceux qui les font ? D'écoles où l'on ne parle que mathématiques et techniques. Et pas (ou alors peu), des hommes. Etrange, non ?

O surprise, en lisant le programme de "Agile Grenoble 2011", je découvre "It’s What You Don’t Do That Counts", une session animée par Susan Hunter. Qui est Susan Hunter ? Je ne le savais pas, mais le mot accolé à son nom m'a attiré l'oeil : Google.
Passé la première réaction (les chevilles qui enflent, je suis dans le même programme qu'elle - j'espère que j'arriverai à mettre les chaussures de ski, quand même), j'ai lu un peu plus attentivement.
Susan Hunter est Program Manager chez Google. J'ai cherché pendant quelques secondes ce qu'est un Program Manager chez eux, je n'ai pas trouvé. J'ai juste trouvé que ça a un salaire annuel moyen de plus de 100 k$.
Le programme dont elle s'occupe, c'est un petit truc, chez Google : Gmail... Il semble qu'elle bosse avec 4 équipes qui contribuent à le développer.
Pourquoi je vous parle de ça ? Parce qu'elle n'a pas fait des études d'informatique. Elle a un master en résolution de conflit. Elle aide les gens à travailler ensemble.

Bien sûr que nous avons besoin de "techniques". Les bases de données et les protocoles, c'est compliqué, par exemple (et ça ne s'arrange pas vraiment avec la fin de SQL). D'un autre coté, il y a de plus en plus d'outils qui masquent cette complexité. Ce blog, par exemple. Pas besoin de connaître HTML et CSS.
Mais nous avons un besoin criant d'autres profils ! De gens qui comprennent les problématiques du développement logiciel, mais qui comprennent surtout les hommes... les utilisateurs et les développeurs.

Jouer aux devinettes

Une traduction en français du premier livre de 37signals, Getting Real est disponible ici. Elle est incomplète, dommage.

37signals, c'est quoi ? Une entreprise étonnante qui a réussi, il y a "longtemps" (ils ont commencé en 1999) à réaliser des logiciels utiles et à prospérer en appliquant des méthodes qui allaient à l'encontre de ce qui se pratiquait - et se pratique encore énormément.

Le blog #hypertextual a fait un bon résumé, que je vous recommande de lire.

Quelques extraits, pour vous donner envie (j'espère) :
L’accent est mis sur la productivité et la confiance : I have no idea how many hours my employees work — I just know they get the work done (J. Fried).
Et bien évidemment la simplicité, cette sophistication ultime selon Léonard de Vinci : “Simple requires deep thought, discipline, and patience – things that many companies lack”(Matt Linderman)
Le Leadership c’est aussi une communication saine et maitrisée. 37Signals a ainsi banni une série de four-letter-words de son vocabulaire. Ces mots simples et passe-partout qui ont souvent des effets désastreux : must, need, just, cant, easy, only, fast.

Pour Fried, le planning ne sert à rien. Il ne s’agit que de vagues suppositions qui ne servent qu’à rassurer un management avide de contrôle.
A quoi bon perdre du temps à prévoir l’avenir quand la Reality is a terrible collaborator. Où serons-nous dans 10 ans ? In the business (Fried).
L’incontournable Peter Drucker distingue le leadership du management en ces termes : Management is doing the things right, while Leadership is doing the right thing.
37Signals a démontré avec panache que les Digital Natives savent gérer leurs affaires en intégrant complètement les contraintes et caractéristiques du monde du XXième siècle. Pour un effet de levier ahurissant : 12 personnes (sur 4 jours) pour une société qui propose des services informatiques à des centaines de milliers d’utilisateurs. Le tout en prenant le contrepied parfait des principes au coeur des organisations telle que nous les connaissions au siècle dernier.


Une dernière précision : aujourd'hui, ils sont toujours moins de 20 personnes. Leur chiffre d'affaires en 2010 : entre 10 et 15 millions de dollars. Les employés sont à Chicago et ailleurs, en télétravail. Et ils travaillent 4 jours par semaine.

L'année dernière, ils ont sorti un deuxième livre : Rework. La bonne nouvelle : il existe en français !

Planning is guessing

("jouer aux devinettes")

La fin des listes et des dossiers ?

Par manque d'imagination ? Ou tout bonnement parce qu'à l'époque c'était le plus simple, l'informatique a pendant longtemps essayé de ne pas trop changer nos habitudes, en conservant la logique que nous utilisions déjà, mais en nous simplifiant son application.

Documents feuilletés page par page, fichiers rangés dans des dossiers, dossiers posés sur un bureau, par exemple. Ou encore courrier électronique envoyé dans une boîte aux lettres.

Pierre Bellanger en parle pas trop mal aux Ernest :


Pierre Bellanger - Communiquer avec Internet par les_ernest

Et puis, tout a commencé à aller de travers. Documents partagés, flux RSS, réseaux sociaux, architectures réparties, cloud, bases de données dénormalisées, etc. Houlala mais c'est la pagaille !

Nous persistons à vouloir classer, ranger, archiver, planifier. Alors que toute l'info est là, disponible en quelques millisecondes, il suffit de demander. Il est plus long de naviguer dans une arborescence de répertoires que de taper un mot dans un champ de recherche.

Nous sommes (surtout les vieux comme moi), enfermés dans nos schémas mentaux. Et ils ne sont plus valables. Enfin si, on peut les garder, mais ils nous limitent.

D'après Michel Serres, la génération mutante pensera différemment.

Pourquoi je vous parle de tout ça ? Parce qu'ayant pendant plus de vingt ans contribué à développer des logiciels, je pense qu'aujourd'hui ceux-ci doivent évoluer. Je dis "je pense", mais c'est faux. La bonne formulation, c'est : je m'aperçois que les logiciels évoluent, et leurs usages aussi.

Fini les listes. Le fameux rêve du bouton "J'ai de la chance" de Google. Nous devons concevoir des logiciels qui présentent l'information utile, aux bonnes personnes, au bon moment. Et pas toute l'information. Car celle-ci est désormais infinie.

Un exemple ? Shazam... Avant on pouvait chercher une chanson par genre, ou par auteur. Maintenant on ne cherche plus rien. Quelques notes et hop, c'est là. Un clic - pardon, un pouce - et je peux écouter et réécouter autant de fois que je veux. Et faire écouter, partager.

Allez, au boulot...

Elastic Leadership

Un blog à lire : celui de Roy Osherove

Un extrait : "Team leadership is the next big thing that software developers need to conquer, or non of this unit testing, TDD, Agile or Lean thing is going to catch on, except in very small circles, that, by chance, happen to have the right people leading their teams."

Pour aller vite, avancez pas à pas

Bon, vous avez été convaincus par mon précédent billet ;-) et maintenant vous vous dites : comment fait-on pour aller vite et, en plus, sans bâcler ?

Aller vite, ça n'est pas produire des milliers de lignes de code, ou de meubles ou de photos ou de chapitres d'un roman en un temps record.

Aller vite, c'est fournir le plus vite possible "au monde" votre idée, sous une forme utilisable. Et pour cela, il ne faut pas attendre d'avoir terminé pour présenter votre oeuvre. Car la plupart des projets sont longs, voire très longs, voire sans fin...

Il faut donc avancer pas à pas. Lentement, donc. En ajoutant petit à petit des éléments à votre projet. Qui - comme vous le savez déja car vous me lisez régulièrement et attentivement ;-) - va évoluer en cours de route.

Dans le développement logiciel - mais ça fonctionne pour tout - on appelle ça faire des itérations. Mais souvent on considère juste qu'une itération c'est une période de temps dans laquelle on va réaliser quelque chose. Une sorte de rythme que l'on se donne.

Ca peut être cela, mais ça peut être beaucoup plus. Une itération, c'est d'abord un objectif ! A la fin d'une itération, on doit obtenir un produit qui apporte quelque chose, sur  lequel "le monde" peut réagir. Car tout est là : pour que votre idée de départ se transforme en une bonne idée et un bon logiciel, un bon meuble, un bon je-ne-sais-quoi, il faut qu'il suscite des réactions !

Au plus vite vous obtenez du retour, des commentaires, des remarques, des critiques, au plus vite vous avancez dans la bonne direction. Au plus vite vous confrontez votre idée au monde réel et aux vrais problèmes, au plus vite vous pouvez corriger le tir.

Une itération c'est un petit projet en soi, il y a un peu de tout dedans : de l'étude, de la production, des tests, de la mise en place, de la communication, une présentation "au public", des critiques, etc. Et quand elle est terminée, on s'arrête ! Vraiment. Et on se change les idées. On travaille sur autre chose. Le temps de laisser aux autres du temps pour réagir. Le temps de recharger ses batteries, de laisser reposer tout ça.

Et on y retourne, avec un regard neuf et fort du regard des autres. On se fixe un nouvel objectif et en avant pour une nouvelle étape. Pas d'objectif, pas d'étape. Vous allez produire dans le vide. Un objectif est essentiel pour la focalisation et la motivation.

Pour aller vite, avancez pas à pas. Aucune chance d'arriver au bout, sinon.

Vite !

Dans un projet, la vitesse est importante. Un projet qui traîne est un projet menacé.

Une équipe focalisée sur un projet est beaucoup plus efficace. Et on ne peut pas rester focalisé à 100% très longtemps. On se lasse, on s'use, on se décourage, on se démotive.

A la base de votre projet il y a une bonne idée. Puis des choix de réalisation. Mais cette idée est bonne maintenant et ces choix sont valides là, tout de suite. Mais demain ? Vite ! Il faut réaliser et livrer ! Qu'il s'agisse d'un livre, d'un nouveau magasin ou d'un logiciel. C'est maintenant que ça se passe, pas dans 6 mois.

Mary et Tom Poppendieck dans "From concept to cash" (j'aime beaucoup ce titre) proposent de se concentrer là-dessus. De ne mesurer que cela : le temps écoulé entre l'idée initiale et la livraison au client.

Aller vite, cela oblige à se concentrer sur l'essentiel, à utiliser les bons outils et les bonnes techniques. A alléger l'organisation et les procédures (ça existe encore, ça ?). Attention, cela ne veut pas dire bâcler et faire n'importe quoi. Au contraire. Pour aller vite, il faut faire des choses de qualité. Sinon on va passer tout son temps à corriger les problèmes. Et puis l'objectif n'est pas d'aller vite une fois. C'est d'aller vite tout le temps !

Plus vite vous montrez votre oeuvre, plus vite vous confrontez votre idée à la réalité, au regard des autres, et mieux c'est. Vous pouvez ainsi adapter, transformer votre idée de base en... autre chose. Voire tout autre chose. Car vous allez vous tromper, bien sur. D'idée, d'outil, de technique.

Allez, vite ! Arrêtez de réfléchir, d'étudier, de vous réunir, de lire ce blog, réalisez !

Comment aller vite ? On en reparlera...

Une carrière de rêve

La semaine dernière, j'ai été sollicité par un cabinet de recrutement. Vous savez, le truc par lequel on attend tous d'être appelé ;-) et qui va vous proposer un pont d'or et une carrière de rêve.

Quelques morceaux choisis du poste proposé :

DIRECTEUR CENTRE DE PROFIT Secteur : e-commerce

- Être responsable de la gestion stratégique & opérationnelle
- Être garant de l'engagement de tous les responsables
- Fixer les objectifs généraux
- Etre responsable du reporting auprès du PDG Europe et des actionnaires.

Bon, d'accord, je n'ai retenu que les 'meilleurs' morceaux. Mais ça fait rêver quelqu'un, une définition de poste comme celle-ci ? Il n'est question ni d'un produit, ni d'un service ou au moins du domaine d'activité concerné. Chaussettes, voitures de sport, fusées ou armes lourdes ? On ne sait pas... Ca ne doit pas être important.

Et les gens avec qui vous allez travailler ? Ah oui, il doivent être 'engagés'. Enfin, les responsables, parce que les autres, ça n'a pas l'air utile.

Brrrr... Enfin, heureusement, je ne postule pas.

Pensée divergente et plein d'autres choses

Vous DEVEZ regarder cette vidéo de Ken Robinson ! Ok, elle dure 11 minutes, mais ça vaut le coup et puis c'est en français. Et c'est peut-être la fin que je préfère : la pensée divergente et comment l'éducation la fait disparaître.

Groupe vs Expert

La force du "groupe" face à l'expert "solitaire" : j'en ai eu récemment deux exemples.

Le premier la semaine dernière : j'étais au 40 ans de l'Association Nationale d'Etudes de la Neige et des Avalanches, à une table ronde sur le rôle d'internet dans l'aide à la décision pour les skieurs de randonnée.

Il existe en effet des sites communautaires (skitour.fr et camptocamp.org sont les plus importants), dans lesquels des milliers de personnes saisissent leurs sorties et renseignent les conditions de neige qu'ils ont observé. Ces sites ne dépendent d'aucune institution ou organisme quelconque. Ils sont gérés par des individus ou des associations, à titre bénévole. Nombreux sont ceux qui utilisent ces sites pour avoir des informations relatives à la sécurité : où aller le lendemain ? Est-ce que ce massif est avalancheux ?

Cela fait (un peu) débat : "ces informations sont-elles fiables ? Quelle est la légitimité des ces comme-vous-et-moi pour discuter nivologie ? C'est un peu dangereux, non ? Il se dit n'importe quoi sur ces forums ! Moi, je n'écoute que les spécialistes de Météo-France",  etc.

Ces remarques viennent surtout de certains professionnels ou skieurs expérimentés. Mais que disent les "vrais" experts, ceux qui passent leur vie à analyser, à étudier les avalanches en labo et sur le terrain (Alain Duclos, par exemple) - je retransmets ses paroles "à peu près" : "Bien sûr, il y a parfois des âneries sur ces forums, mais elles sont très vite corrigées, commentées. Je suis surpris de la pertinence des propos échangés et certains professionnels devraient aller voir, ils apprendraient des choses".
Cela rappelle un peu Wikipedia, finalement.

Le deuxième exemple est plus qu'un exemple : c'est une preuve, tout simplement.

Vous pouvez lire les détails dans cet article, mais tout est dit dans cette phrase : "les adeptes d'un jeu vidéo sur l'internet ont réussi en trois semaines à décoder la structure d'une enzyme proche de celle du virus du sida, une énigme qui tenait en échec depuis dix ans les plus éminents scientifiques."
Grâce au site fold.it, conçu dans ce but. Attendez un peu avant d'aller jouer sur leur site, leurs serveurs n'arrivent plus à suivre depuis ce succès et la pub qui leur est faite... Il ne s'agit pas que de la réussite du "groupe", mais aussi du "jeu" - on reparlera "gamification" et surtout plaisir à l'occasion...

Pour conclure cet article un peu long (une fois n'est pas coutume, vous me pardonnez ? Vous êtes encore là ?) : attention ! L'individu a un rôle, il n'y a pas que le groupe ! 


Les sites communautaires dont j'ai parlé ont été imaginés par quelques individus. Les idées individuelles sont essentielles, mais elle n'ont d'impact que si elles sont partagées, diffusées.

Ne faites pas les poissons rouges !

Dans de nombreuses entreprises, être manager est encore associé à bureau particulier, réunions de management et tableaux de bord. On reçoit ses collaborateurs dans son bureau et on les rencontre en réunion. Le reste du temps, le manager travaille seul ou avec ses congénères, dans des réunions de management.

C'est quoi, une réunion de management ? Beaucoup trop souvent (je n'ai pas dit tout le temps !), c'est un moment de haute stratégie déconnecté de la réalité. Pourquoi ? Bonne question... Cela dépend de l'orientation donnée par le "top management", comme on dit. Qui est trop souvent du "taupe management", fait en aveugle. Forcément, car si les managers sont éloignés de leurs "managés", où croyez-vous que sont leurs propres managers ? Encore plus loin. Et ils ne voient pas leur entreprise fonctionner. Ou seulement à travers des tableaux de bord.

Mais même si l'orientation donnée et les intentions sont bonnes, cela ne suffit pas. Il faut être en contact avec son équipe. En contact permanent. Assis dans le même bureau, à partager leur quotidien. A entendre, sentir, voir comment les choses se passent. Et aussi à faire entendre, sentir, voir vos propres préoccupations. C'est un bon début pour former une équipe.

Sortez de votre bocal ! Retrouvez la vraie vie et par la même occasion la mémoire : oui telle tâche prend du temps, oui tout ne se passe pas toujours bien, etc.

Ne faites pas les poissons rouges !

La valeur du manager

Dans une organisation, il est bon que chacun se demande quelle est la valeur qu'il apporte. A l'entreprise, aux autres, au produit, etc.

La principale valeur apportée par un manager, c'est de créer les conditions favorables à ce que les "managés" puissent apporter leur propre valeur. Et pour cela, parfois, le mieux est de... ne rien faire. De laisser l'équipe s'organiser, de laisser chacun faire comme il l'entend.

Quand un salarié vient trouver son chef avec une idée et que celui-ci n'y prête même pas attention, c'est de la valeur qui disparaît en fumée. Peut-être que cette idée était franchement mauvaise, qui sait ? Ca n'a pas d'importance. En l'ignorant, le manager n'a pas seulement tué l'idée, il a tué l'esprit créatif de son inventeur. Et comme les gens se parlent, il a probablement aussi tué celui de tous les membres de l'équipe.

Si un manager considère qu'il est là pour décider quelle idée est bonne et contrôler que seules les (ses) "bonnes" idées sont mises en oeuvre, alors il faut se débarrasser de ce manager.

NoManager...

NoManager

NoManager, pour Not Only Manager (en référence au "mouvement" NoSql, pour ceux qui font un peu de développement logiciel).

Un manager doit surtout être un leader. Pas un gestionnaire. Un leader ça guide, ça mène et ça participe. Ca montre "le bon geste", ça forme. Ca ne reste pas "sur le bord", dans sa tour d'ivoire, à dire ce qu'il faut faire et ne pas faire.

Comme en montagne. Le bon premier de cordée, c'est celui qui passe... en second. Pour permettre à l'autre d'apprendre, de devenir autonome, d'affronter les problèmes. Mais en étant, là, tout près. Tout prêt à soutenir, à encourager, à conseiller, et à repasser devant si besoin.
Et l'autre peut ainsi progresser (avancer, au propre comme au figuré) en confiance. Il peut tenter, essayer, rechercher ses limites.

Merci Céline !

Ne soyez pas des managers, soyez des leaders. No Manager...

(Et si on lançait officiellement un mouvement NoManager ? Il y a des amateurs ?)

La liberté, pourquoi ?

Un peu à droite de ce texte, il y a écrit "Libérer". Qu'est-ce que ça vient faire là ?

Je me suis auto-proclamé "Libérateur" ;-) et j'ai même mis ce verbe en tête de liste, car je pense que c'est primordial : une équipe qui fonctionne, c'est une équipe qui est libre. Pourquoi la liberté ?

Eh bien d’abord, parce qu’être libre c’est plus agréable, et que la vie est courte.

Mais aussi parce que ceux qui sont libres d’imaginer toutes les solutions sont plus efficaces.

Une équipe libre envisage toutes les possibilités et choisit celle qui lui semble la plus adaptée. Ce n’est pas forcément la meilleure, mais celle qu’elle “sent” le mieux. Et c’est important car imaginer, inventer, avoir des idées c’est une chose mais ensuite il faut réaliser et la vraie difficulté est là. Et qui est le mieux placé pour juger de la faisabilité que celui qui va faire ?

Le chef qui pense et les autres qui exécutent. Les choses ont-elles évolué ? Maintenant, on manage, on délègue, on implique, on motive. Mouais. On ne libère pas vraiment, la plupart du temps. Le manuel du parfait manager le dit bien : il faut déléguer puis contrôler. S’il y a contrôle, il n’y a pas de liberté. Le travail sera fait de façon à satisfaire au contrôle. Où est la création ?

Mais libérer est dangereux. Ceux que vous allez libérer ne feront peut-être pas ce à quoi vous vous attendiez. Normal, vous les avez libérés pour qu’ils créent. Peut-être vont-ils se révéler plus efficaces que vous ? Peut-être ne servirez-vous plus à rien ? Si vous êtes un chef, pardon on dit un manager, et que vous libérez “votre” équipe, elle ne sera plus la vôtre. Mais rien ne vous empêche d’en faire partie. Libérez-vous aussi !

Votre chef ne l’entend pas de cette oreille ? Prouvez lui qu’une équipe libérée est plus forte, plus efficace. Et s’il ne veut rien voir, changez de chef...

Si vous n’êtes pas prêt à tout cela, attention : la liberté est dangereuse. Restez sagement dans le workflow. Profitez-en. Tant qu’il existe.

Merci à Emmanuel pour le dessin !

Partage d'informations : danger !

Voltaire (il y a donc pas mal de temps), nous avertissait déjà dans ce texte : "de l'horrible danger de la lecture".

Partager ses connaissances et les informations que l'on a, c'est dangereux... pour ceux qui tirent du pouvoir :
- soit du fait que certaines informations restent cachées (les malhonnêtes qui veulent cacher leurs méfaits)
- soit du fait qu'ils sont les seuls à disposer de ce savoir et qu'ils peuvent ainsi le monnayer

Cela est valable partout : dans une entreprise, une association, un pays, etc.

L'invention de l'écriture a été considérée comme très dangereuse et il en est de même pour internet. Pensez-vous ! Des informations fournies par on ne sait qui, diffusées à tout le monde. "Mais mon bon monsieur, la plupart des gens sont incapables d'interpréter correctement ce qu'ils lisent ! Il faut que quelqu'un leur explique tout ça et fasse un peu de tri là-dedans, sinon où va t-on ?"

En d'autres termes : les gens sont stupides et il faut contrôler ce qu'on leur dit.

Dans une entreprise, il faut garder secret les salaires et les prix de vente, par exemple. Pourquoi, au fait ? Il y a des méfaits à cacher ? Non ? Alors c'est sûrement parce que les salariés sont trop bêtes et ne peuvent pas comprendre pourquoi untel est mieux payé qu'un autre ou pourquoi leur travail est vendu au client à un prix très différent de ce qui va leur revenir en fin de mois.

Quand vous proposez de rendre visible une information et que certains vous disent que c'est dangereux, essayez de comprendre leurs motivations (malhonnêteté, intérêt ou mépris ?). Et continuez, vous êtes probablement sur la bonne voie !

L'école-usine

Après l'école... et quelques règles pédagogiques d'actualité, je vous parle encore un peu de l'école.
Ou plutôt c'est (encore) Seth Godin, dans "Permission marketing" cette fois :

"D'une génération à l'autre, l'école primaire a toujours été le miroir de notre société. Il y a deux cents ans, la population non agricole était constituée essentiellement d'artisans. Ils avaient peu d'appareils mécaniques à leur disposition, ne travaillaient que sur quelques objets à la fois et sortaient des produits non standardisés et de grande qualité.

L'école d'alors correspondait assez bien à cette image. Le petit bâtiment à classe unique était le domaine particulier d'un seul être de talent. Sa mission consistait à travailler individuellement avec chaque enfant et, au bout de quelques années, à produire des élèves qui avaient acquis des connaissances réelles.

A partir de la révolution industrielle, ce fut désormais l'usine qui marqua le mode de travail, et cette transformation s'insinua même dans l'idée que l'on se faisait de l'école. Au lieu de confier à un seul individu la tâche de former un nombre restreint d'enfants, on s'est mis à construire des écoles-usines. Aujourd'hui, les différentes salles évoquent autant d'ateliers d'un grand établissement industriel, avec des pupitres disposés en rang. Le maître ou la maîtresse enseigne à partir d'un programme standard : à la place de l'artisan chevronné d'autrefois, on trouve un salarié engagé pour sa capacité à appliquer les consignes. Et à la fin de chaque année, les enfants passent au poste suivant sur la chaîne de montage.

Les élèves qui ne ressemblent pas parfaitement aux autres "pièces" du même lot sont acheminées vers de filières spécialisées. Ceux qui ne répondent pas aux normes édictées par le service centralisé de gestion de la qualité sont sanctionnés, "réparés" ou rejetés."

Les dessins sont de Ken Robinson.

Le droit à l'erreur, ça ne suffit pas

Dans certaines entreprises, celui qui fait des erreurs est réprimandé, blâmé. Dans d’autres on donne le droit à l’erreur.

Mais trop souvent, ce droit donné n’est qu’un leurre. Le jour où vous allez vous tromper - et il arrivera tôt ou tard - on vous le dira, gentiment, peut-être, mais avec deux sous-entendus :
     1) que cela ne se reproduise pas
     2) vous êtes nul

Et on n’oubliera pas de citer ce faux pas lors du prochain entretien individuel.

Ce n’est pas cela, donner le droit à l’erreur.

Permettre à chacun de se tromper, c’est encourager les expérimentations, pousser à se lancer, à essayer de nouvelles voies. Et accepter comme un fait normal que ça ne fonctionne pas. Quand on se trompe, on apprend. Les skieurs le savent : un skieur qui ne tombe pas est un skieur qui ne progresse pas. Pour apprendre, pour aller plus loin, il faut jouer avec ses limites et passer du mauvais coté parfois.

Bien sûr, il y a des risques. Certaines erreurs peuvent être fatales. Il faut accepter la présence du risque. Ou ne rien faire.

Si vous entendez cette phrase, cette fameuse phrase : “sur ce projet, nous n’avons pas droit à l’erreur”, fuyez. Le risque zéro n’existe pas.

Les skieurs-alpinistes prennent toutes les précautions : ils se forment et s’informent sur les conditions nivologiques, s’équipent, progressent espacés, développent leur intuition, suivent les progrès de la nivologie. Au final, il y a des guides de haute montagne - des professionnels - emportés par des avalanches. Si vous faites du ski-alpinisme, vous pouvez mourir sous une avalanche. Il faut accepter ce risque ou ne pas y aller.

C’est exactement la même chose sur un projet - avec des conséquences moins graves - il faut accepter le risque ou rester assis dans son canapé. 

Si vous voulez progresser, faites des choses, trompez-vous, apprenez, recommencez.

Naturellement et culturellement - merci l’école - nous sommes timorés et nous avons peur de faire des erreurs. Nous avons besoin d’être encouragés, poussés à nous lancer. Pas d’être blâmés quand nous avons enfin osé et que - malchance ou inexpérience - nous nous sommes fourvoyés.

Plutôt que de parler de droit à l’erreur, parlons du devoir d’essayer !

Remplacez "Déléguer et contrôler" par "Faire confiance et communiquer"

Faire confiance aux autres est primordial.

Abandonnez le "Déléguez et contrôlez", remplacez le par "Faire confiance et communiquer".

Si vous n’avez pas confiance en vos collaborateurs, alors vous allez devoir consommer beaucoup d’énergie à contrôler ce qu’ils font. Et eux n’auront pas confiance non plus. Donc ils ne vous diront pas tout. Ils ne diront que ce qui les met à leur avantage, ou qui justifie leurs actes. Ou pire, ils vous diront ce que vous avez envie d’entendre. Donc sans confiance, pas de vraie communication.

Mais aussi, sans confiance, pas de droit à l’erreur. Pas de prise de risque. Pas d’innovation.


Les enfants progressent parce qu’on leur fait confiance. Si la première fois que votre fils monte sur son vélo sans roulettes, il vous sent terrifié et que vous lui dites : “tu es sûr de vouloir faire ça ?”, il y a de grandes chances qu’il laisse tomber ou qu’il se laisse tomber...
Si au contraire il vous sent... confiant dans ses capacités, alors il sera encouragé. Il aura... confiance en lui ! Et si en plus vous le mettez en... confiance en étant à ses cotés pour l’aider “au cas où”, pour le conseiller, ça marchera encore mieux. Il vous... confiera ses problèmes, ses peurs, ses questions et vous en parlerez ensemble.
Faire confiance, c’est prendre un risque. Celui de se tromper. Peut-être que votre fils va tomber. Il ne faut pas lui cacher, d’ailleurs. Tomber, ça fait partie de “faire du vélo”.

Il ne suffit pas de dire aux gens : je vous fais confiance. Il faut le prouver. Les laisser libres de faire des choix, et ensuite les assumer avec eux. Il ne faudra pas reprocher à votre fils d’avoir déchiré son pantalon ou cassé son vélo.

Gagner sur les deux tableaux

Il y a quelques temps que je n'ai plus parlé de développement logiciel, alors allons-y.

Dans le développement logiciel, donc, quand on cherche à optimiser on est confronté à un choix :

- soit on optimise la vitesse d'exécution,

- soit on optimise la mémoire consommée.

Quand on peut gagner sur les deux tableaux : vitesse et espace utilisé, c'est qu'on s'était fourvoyé au départ. Ou alors qu'on a vraiment trouvé une autre façon d'aborder le problème, qui permet de gagner en vitesse et en mémoire.

Avec les tests automatisés, c'est pareil - qu'il s'agisse de développement piloté par les tests ou de chaîne de développement automatisée. On peut gagner sur les deux tableaux : qualité et temps de développement.

Alors pourquoi tout le monde n'en fait pas ? Parce qu'il faut changer les habitudes, se former, et cela veut dire perdre un peu de temps à court de terme. Investir, en fait.

Et aussi devenir adulte, accepter que même les bons développeurs expérimentés n'échappent pas aux bugs et qu'il est illusoire d'espérer que cette fois, tout se passera bien, qu'on peut y aller sans faire de tests, que le client les fera et puis on verra bien, on s'en est toujours tiré de toutes façons et puis, oui, des fois le boulot c'est dur...

(voir aussi mon post sur le respect).

(bis)

IL FAUT TESTER AVANT DE LIVRER 

ET LA SEULE FACON D'Y ARRIVER, C'EST D'AUTOMATISER !

Carotte ou bâton ? Nous ne sommes pas des ânes !

La traditionnelle méthode de la carotte et du bâton est encore très largement utilisée : augmentations ou primes pour récompenser, par exemple.

Elle est censée être LA méthode pour motiver ses salariés. Pardon ses collaborateurs.

Or - mais vous le saviez déjà, je pense - elle ne fonctionne pas.

L'image de la carotte et du bâton est très révélatrice du respect que l'on a pour nous... Manager, c'est très facile, il suffit de faire comme si vous travailliez avec des ânes. Pour motiver, méprisez. Mais cachez bien tout ça sous un vernis managérialement correct.

Les récompenses et les sanctions, ça ne fonctionne pas ! Ce qui marche, c'est la communication, la collaboration, la transparence, le respect, le plaisir... et encore plein d'autres choses ! Mais pas ça.

Vous le savez déjà, pour vous-même. Peut-être que vous ne vous l'avouez pas, mais vous le savez. Et figurez vous que vous n'êtes pas "anormal". Tout le monde fonctionne comme ça. Il y a même des études, des expériences qui le prouvent.

Dan Pink en parle très bien (en plus c'est sous-titré en français). Ca dure 18 minutes, mais ça vaut vraiment le coup.

J'oubliais : ça ne marche pas terrible non plus avec les ânes.

Quelques règles pédagogiques d'actualité !

Je me suis replongé dans les bases de la pédagogie Freinet. Je dis replongé mais ça n'est pas tout à fait vrai. Plongé serait plus juste. Je suis tombé dedans quand j'étais petit, alors je n'avais pas tellement approfondi la théorie sous-jacente. Je n'avais pas besoin de la recette, quoi...

Pas de grandes surprises en lisant les recommandations de Célestin Freinet et de tous ceux qui ont mis en oeuvre sa pédagogie : j'ai trouvé ce à quoi je m'attendais. Je savais déjà que l'instituteur que j'ai eu au primaire était bien une sorte de ScrumMaster (pour ceux qui ne connaissent pas la méthode Scrum, allez faire un tour sur le net et revenez ici ensuite).

Mais je suis quand même frappé par la cohérence entre certaines des recommandations (il appelle ça des invariants pédagogiques) et la façon dont je vois le management et la vie en général. Tout ça me parait vraiment d'actualité, alors que ça a été rédigé en 1964 (un an avant ma naissance, tiens).

On trouve la liste complète ici, mais je vous en cite quelques unes :

• Nul - l'enfant pas plus que l'adulte - n'aime être commandé d'autorité.
• Nul n'aime s'aligner, parce que s'aligner, c'est obéir passivement à un ordre extérieur.
• Nul n'aime se voir contraint à faire un certain travail, même si ce travail ne lui déplaît pas particulièrement. C'est la contrainte qui est paralysante.
• Chacun aime choisir son travail, même si ce choix n'est pas avantageux.
• Nul n'aime tourner à vide, agir en robot, c'est-à-dire faire des actes, se plier à des pensées qui sont inscrites dans des mécaniques auxquelles il ne participe pas.
• Il nous faut motiver le travail.
• Personne, ni enfant ni adulte, n'aime le contrôle et la sanction qui sont toujours considérés comme une atteinte à sa dignité, surtout lorsqu'ils s'exercent en public.
• L'enfant n'aime pas le travail de troupeau auquel l'individu doit se plier comme un robot. Il aime le travail individuel ou le travail d'équipe au sein d'une communauté coopérative.

Cette dernière, notamment, est étonnante ! 40 ans avant que l'on parle de l'entreprise 2.0 !

"le travail d'équipe au sein d'une communauté coopérative"

Célestin, reviens, tu adorerais cette époque !

L'école...

En vrac, quelques infos liées à l'école et à ce qu'on y enseigne :

5 qualités pour réussir dans la vie et qui ne sont pas enseignées à l'école (et même réprimées) :
- la passion
- la curiosité
- être orienté objectifs
- être créatif
- être sociable

Ce n'est pas moi qui le dit, c'est Faysal Hafidi, à voir ici, mais je suis d'accord !

Seth Godin, lui (lisez le !), dit que l'école ne devrait enseigner que 2 choses :
- résoudre des problèmes intéressants
- diriger, avoir du leadership

En attendant de lire son livre, lisez ce petit résumé de la partie sur l'école.

Dernière info sur l'école (mais on en reparlera, c'est sûr) : vous avez entendu parler des écoles 'alternatives' : Montessori, Freinet, Summerhill ? Non ? C'est dommage.

Tiens, vous savez qui a été dans une école Montessori  ? Je l'ai appris il y a très peu de temps et ça m'a fait tout drôle :
- Larry Page, Sergei Brin (Google, ça vous dit quelque chose, ça quand même ?)
- Jeff Bezos (fondateur d'Amazon)
- Jimmy Wales (fondateur de Wikipedia)

On devrait peut être s'y intéresser, non ? Moi je m'y intéresse depuis longtemps. Depuis tout petit même. Depuis le CE1, où je suis rentré dans une école Freinet. Je vous en reparlerai, promis.

Liberté et création : le rôle des règles

La liberté de créer, c’est d’abord une affaire de sensation. La sensation d’être libre de faire les choses comme on l’entend. De ne pas se mettre soi-même des barrières, des tabous ou des règles inutiles.

J’ai bien dit inutiles. Mais on peut décider d’encadrer son travail avec des règles pour se canaliser ou orienter son esprit.

Prenons l’exemple du haïku (je vous recommande le livre de Philippe Costa pour en savoir plus).

Il y a quelques bonnes pratiques, comme la simplicité et le kigo, qui consiste à faire une allusion à la saison. Mais une seule règle : 5-7-5. Trois vers, le premier de cinq syllabes, le second de sept et le dernier de cinq. Une règle facile à comprendre et qui oblige l’artiste à trouver les bons mots et à être bref. Un peu comme un peintre qui commence par choisir la taille de la toile qu’il va peindre. Et cette règle des 5-7-5 a une caractéristique très importante : on peut l’enfreindre si elle nous entrave, si elle nous freine, si c’est un obstacle, si le haïku ‘sonne’ mieux de cette façon.

Un nouveau matin

en courant le long des blés

mûrissent les idées

Dans une entreprise, il faut des bonnes pratiques, mais peu de règles. Et il faut les expliquer, les justifier et les remettre en question. Souvent. Car le monde change, et les règles d’hier ne doivent pas être celles d’aujourd’hui. Si la taille de la toile habituelle n’est plus adaptée à ce que vous voulez peindre, changez-en. Et remplacez la toile par du bois, si c’est mieux.

Great place to work et distance hiérarchique

Great Place To Work récompense les entreprises où il fait bon travailler.

Et bonne ambiance = meilleurs résultats

Dans le classement des 50 meilleures PME européennes, on trouve une majorité d'entreprises scandinaves et particulièrement le Danemark (10 dans les 25 premières !)

Or, les pays scandinaves sont connus pour avoir une faible distance hiérarchique (power distance en anglais) et... particulièrement le Danemark (une des distances les plus faibles du monde !) .

Ceci expliquerait-il cela ?

Comparons un peu le classement de "Great Place To Work" avec l'indice de distance hiérarchique de chaque pays (d'après ce tableau, suite aux études de Hofstede) :

Intuition confirmée, on dirait... distance hiérarchique faible = bon classement => bon résultats !

A noter : parmi les (seulement) 2 françaises, il y a OCTO, bien connue dans le milieu agile.

Pour en savoir plus sur la distance hiérarchique (et plus généralement la distance au pouvoir) :
http://www.ciao.fr/Par_D__Avis_453796
http://base.d-p-h.info/fr/fiches/dph/fiche-dph-7467.html

Peut être ma "démonstration" est-elle un peu simpliste, peut être y a t-il d'autres paramètres, plus importants, à prendre en compte ?

Votre avis m'intéresse...

Les idées, c'est sous la douche ou en montagne

Vos meilleures idées, vous les avez eues où ?

Assis bien sagement à votre bureau, pendant les heures de travail ? Ca arrive, mais en général, moi, les bonnes idées, les solutions aux trucs qui ne marchent pas, ça vient en dehors du bureau : sous la douche, le matin au réveil, en marchant, en pédalant, en pagayant.

J'en ai souvent parlé autour de moi, et visiblement, je ne suis pas le seul. D'ailleurs, il existe même un bloc-notes spécial douche !

Conclusion : une entreprise a tout à gagner à ce que chacun, en dehors du bureau, pense à elle et à ses projets. Au point d'avoir envie d'y réfléchir en marchant dans les montagnes, par une belle journée d'été (tiens, comme aujourd'hui).

Comment ?
Il faut que penser à son travail soit AGREABLE. Sinon on s'empresse de penser à autre chose et on n'a pas ces fameuses bonnes idées !

Il faut aussi avoir les moyens de mettre en oeuvre ces idées, mais c'est une autre histoire. A suivre, donc...

Le meilleur moyen de faire taire la résistance

Seth Godin explique très bien ce qu'est la résistance, et comment elle nous empêche d'avancer.

Vous DEVEZ absolument lire son livre "Etes vous indispensable ? Libérez le linchpin qui est en vous"!

En attendant, vous pouvez, pardon vous DEVEZ lire un résumé du chapitre sur la résistance.

Quand vous êtes sur le point de prendre une décision qui va vous engager pour longtemps (quitter votre boulot, par exemple...), vous oscillez sans cesse entre "vas-y, fonce" et "ça va pas la tête ?". Ce "ça va pas la tête", c'est la résistance qui l'exprime. Elle vous fait douter, angoisser, voire paniquer.

Quand enfin vous vous décidez, elle fait "oh, le con !" et se jette sur le premier prétexte venu pour vous faire renoncer.

Si vous arrivez à l'ignorer à ce moment là, c'est terminé. Elle ne vous embêtera plus, bien au contraire. La peur de l'échec qu'elle vous distillait va disparaître. Pourquoi ? Parce que ce fameux cerveau reptilien sait qu'il n'y a plus d'autre alternative que d'aller de l'avant. Il va même vous pousser à aller encore plus vite, plus loin.

Un effet double, donc :
1) Quel soulagement quand la peur s'en va ! Plus de choix à faire, plus d'hésitations.
2) Vous aviez déjà de l'énergie à revendre, et votre cerveau reptilien va vous en donner encore plus. "Mais tu bosses pas là ? Tu crois qu'elle va se créer toute seule ton entreprise ? Allez, go !"

Davaï ! (comme disait Youra).

Avoir, être, faire

Notre société est souvent accusée de privilégier l'avoir sur l'être. Je suis d'accord. Mais si être est important (surtout être agréable, gentil... ;-)), ce qui l'est encore plus, c'est de faire.

Je ne sais plus qui a dit ça (personne, peut être ?) : "Nos pensées ne sont rien, seuls nos actes comptent".

Il faut faire. Au sens de réaliser. De créer. Une oeuvre d'art, un bon repas, une fusée, du pain, un moment sympa, voire un blog...

Et avec d'autres, c'est encore mieux.

Alors voyageons léger, soyons chouettes et faisons, faisons !

Story Map : l'outil

Les post-its sur une table, une baie vitrée ou par terre, c'est bien, mais...
- ça prend de la place
- ça s'envole
- il faut être tous dans la même pièce
- ça n'est pas facile de décaler toute une ligne vers le bas, par exemple.

Alors j'utilise Google Docs ! Un bête dessin. Les avantages :
- c'est collaboratif ! on peut travailler à plusieurs sur le tableau, même en étant chacun à un bout du monde. Avec Skype en plus pour se parler, c'est parfait.
- on peut changer les couleurs, jouer sur les tailles, déplacer plusieurs "post-its" à la fois
- on dispose de l'historique des différentes révisions
- on peut utiliser la recherche de Google Docs pour retrouver tel ou tel tableau par la suite

Seul inconvénient : on est limité en taille. Dans ce cas, je découpe mon tableau dans plusieurs documents.

Voilà... un outil simple, souple et efficace !
D'ailleurs, je l'utilise aussi comme tableau kanban ou scrum, pour des équipes distribuées, mais pas seulement (merci Céline pour l'idée !)
Et aussi pour de vrais schémas collaboratifs, qui ne sont pas seulement partagés, mais qui sont réalisés par plusieurs personnes simultanément.

Mais on en reparlera sûrement.

Story Map, Project map

.J'aime beaucoup le concept de Story Map décrit par Jeff Patton : http://www.agileproductdesign.com/blog/the_new_backlog.html

Très utile lors du développement d'un logiciel pour exprimer (et faire exprimer) des besoins, et surtout pour définir les priorités et le contenu des itérations.

On peut généraliser ce concept à tout type de projet. L'objectif est d'énumérer tout ce qu'il y a à faire, et de trouver le "chemin minimal" qui pourrait mener à la réalisation du projet (ou à une première "version").

Un exemple : vous décidez de faire une exposition de tableaux dans un refuge de montagne pour l'été (si si, c'est possible).

Etape 1 : définir les grandes "activités" nécessaires, dans l'ordre :

Etape 2 : détailler chaque activité :

Etape 3 : prioriser (les plus importantes en haut) et continuer à détailler :

Voilà ! La première 'ligne' (en pointillés) contient ce qui doit absolument être fait pour que l'expo "existe", il faut se concentrer là dessus, y mettre toute l'énergie. Ce qui n'empêche pas de faire le reste si c'est facile...

La prochaine fois, je vous parlerai de l'outil que j'utilise (quel suspense !).