Au coude à coude

séminaire 4 avril matin : ce que les méthodes Agiles peuvent faire pour vous

J'anime un séminaire jeudi 4 avril matin à Montparnasse via le cabinet de coaching Melcion. Si vous avez envie de travailler moins en produisant plus, ce sera l'occasion d'y découvrir ce que ces méthodes peuvent faire pour vous, quel que soit votre métier.

J'y déroulerai quelques études de cas dans des contextes variés : industrie, R&D, entrepreneuriat, IT, conseil, etc

Ce sera un plaisir de vous y voir !

De 8h30 à 11h, inscription et détails ici

"Nous on est agile"

L'agilité est le dernier buzz word managérial, instantanément dévoyé par un amalgame quasi omniprésent entre le fait "d'être agile" et celui d'utiliser les méthodes Agiles.

"Etre agile" est sans doute sympathique, mais on pourrait débattre pendant des heures de ce que ça signifie concrètement. 

Utiliser les méthodes Agiles, c'est en revanche profiter de 30 ans de retours d'expérience d'équipes projet du milieu informatique, sur la bonne manière d'éviter les retards, les dépassements de charge et les livrables de peu de valeur ajoutée tout en garantissant une forte flexibilité du PERIMETRE du projet. 

- Scrum est la plus connue d'entre elles, c'est une pure méthode de gestion de projet. Elle permet effectivement le changement du périmètre du projet en cours de route ( au fur et à mesure de la confrontation de produit à la réalité). Elle embarque quelques points traits d'ADN commun avec la production lean ( management visuel, point d'équipe, amélioration continue, etc) mais s'applique à des contextes qui n'ont pas grand chose en commun avec de la production.

- Extreme Programming -XP- concerne toujours des projets de développement d'un produit, elle est encore plus spécifique au contexte informatique. Utilisée seule ou en complément de Scrum, cette méthode permet d'élever et de garantir un très haut niveau de qualité. Là aussi c'est le changement de périmètre qui veut être facilité. 

- Lean startup reprend du lean la notion d'élimination du gaspillage, mais dans une otique de mise sur le marché le plus vite possible d'un produit le plus petit possible pour confronter une hypothèse business bien délimitée à la réalité, et pivoter vers une hypothèse plus plausible le cas échéant ( changement de périmètre et/ou de cible et/ou de business model).

- "Kanban pour l'IT" est une mouvance plus récente qui complète chacune des méthodes ci-dessus par une mécanique d'amélioration continue des processus. Là aussi le vocabulaire emprunté au lean est assez trompeur, le seul point commun étant cette volonté forte d'amélioration continue.

En synthèse : l'approche Lean Startup ( business) est plus facile à dérouler si l'équipe est organisée en Scrum ( gestion de projet) et utilise les outils d'animation Extreme Programming pour garantir une très haute qualité de code. 

Ajouter une couche Kanban permet de garantir l'optimisation du système dans la durée.

Le mot agile surfe donc sur la popularité naissante des méthodes du même nom pour s'infiltrer dans des domaines où ces dernières n'avaient jamais mis les pieds. Il tombe d'ailleurs à point nommé chez trop de managers à qui on demandait depuis des années d'être Lean sans qu'ils aient jamais réellement compris en quoi ça consistait. "Agile", au moins, ils ont l'impression de savoir ce que ça veut dire...

Tout n'est pas perdu pour autant, beaucoup d'outils issus des méthodes Agiles peuvent être déclinés hors de leur milieu informatique d'origine. Ce transfert a commencé et permet à des projets de toutes tailles et de tous secteurs de respecter leurs délais et leur budget tout en offrant une belle souplesse sur le périmètre.

La recette ? peu d'informatique, peu de dogmes, et une dizaine de techniques d'animation pragmatiques frappées au coin du bon sens.

Expérimentation réussie !

Ce blog est resté en standby pendnat près d'un an, il est temps de donner quelques nouvelles.

Je décrivais ici la nouvelle donne que nous nous étions donné en famille courant 2011 : le modèle tient le coup à tous les niveaux !

La famille est heureuse et les poules se multiplient, côté professionnel je partage maintenant mon activité de consultant et formateur entre deux types de mission :

- l'organisation des équipes : que ce soit en contexte de production ou de projet, en industrie ou dans les services, j'aide mes clients à pourchasser les déperditions d'énergie avec un objectif simple : produire mieux, plus vite et avec le sourire.

J'utilise pour ça les techniques des méthodes Agiles pour les projets, et de la Théorie des Contraintes pour les autres contextes. Je publierai un livre sur ces sujets courant 2013.

- la refonte d'une stratégie : j'emploie d'autres outils de la Théorie des Contraintes pour aider mes clients qui cherchent un nouveau souffle à ré-inventer leur offre au sens large -état des lieux, identification des problèmes racines, construction de solutions innovantes et désamorçage de leurs possibles effets indésirables-. 

Mes clients sont des équipes qui vont bien et veulent aller très bien, ou des TPE/PME qui vont mal et veulent inventer d'autres solutions que le plan social... Mon champ d'action est large !

Expérimentation

 3 mois de silence sur ce blog... 3 mois en famille à réinventer notre mode de vie.
Ceux qui suivent ce blog depuis le début sauront que ce n'est pas notre coup d'essai.Cette fois-ci en revanche c'est un peu plus qu'une parenthèse de 6 mois en Thailande. 

AVANT
Ma femme, notre bébé d'un an et moi sommes en colocation bancale dans une maison aux portes de Paris. 
Je travaille 60 heures par semaine sur un projet web dont le business model tarde à émerger. 
J'ai de la foi à revendre, mais j'achèterais bien un peu de sérénité et de temps pour ma famille.

APRES
Nous habitons dans un hameau de trois maisons, à côté d'une petite ville, à 20 minutes d'Angers.
Je suis aux 4/5, j'ai considérablement augmenté ma productivité.
J'interviens un peu partout en France pour former et accompagner des entrepreneurs et des salariés à l'Agilité.
Ma femme peut enfin envisager de reprendre son métier d'artiste.
Nous avons quinze variétés de légumes dans notre potager et dix poules dans le jardin.
Notre fils a les pieds dans l'herbe la majeure partie de la journée, une nounou formidable et des parents heureux :-)

Beaucoup de choses à raconter sur ces changements, et un peu de mal à savoir par où commencer...

 

Cycle en V : mais pourquoi ?

Ca vaut le coup d'aller lire mon précédent post sur le côté obscur du cycle en V en préambule.

La question qui reste, c'est pourquoi est-il toujours autant utilisé ?

D'accord, il y a quand même des cas où il est réellement nécessaire...

Si vous construisez un pont, vous êtes relativement assuré qu'on ne vous le demandera pas de le déplacer dans un an. En revanche on supportera mal qu'il se casse en deux, même dans 20 ans.
Non seulement vous n'aurez pas à être très ouvert au changement en cours de construction, mais en plus vous serez partis depuis longtemps quand les vrais problèmes se poseront.

Alors d'accord, on regarde tous les détails avant de commencer, on se met d'accord sur un process en béton armé, on documente un peu tout ce qu'on on peut, et on laisse un service qualité controler à fond toutes les étapes de réalisation.

Si vous travaillez à la NASA, à mettre au point depuis 2 ans un satellite qui embarquera en 2014 pour être mis en service en 2020 autour de Saturne. Vous n'avez pas le droit à l'erreur, genre pas du tout. Ce n'est alors pas choquant qu'un tiers du budget soit consacré à vérifier 3 fois le boulot de chacun. 
C'est bien pour ça que la NASA a grandement contribué à formaliser la méthode CMMI, rouleau compresseur de gestion de projet ultra-blindé que beaucoup d'entreprises s'escriment à mettre en place.

Bon, si vous ne travaillez ni chez Bouygues ni à la NASA, les raisons de la survie du cycle en V chez vous sont peut-être moins valables...

1. Le cycle en V rassure.

C'était en intro de la première session de l'Institut Agile : la survie de ces méthodes s'explique avant tout par l'impression de controle.

C'est vrai que sur le papier, c'est beau, c'est rassurant.
C'est beau de voir un planning ou un diagramme de Gantt. On change un chiffre et tout l'enchainemnet se met à jour.

C'est beau de voir défiler slide après slide ce qu'il se passera dans 6 mois, les inconnues sagement rangées, la marge de manoeuvre soigneusement calculée.

Merci Microsoft, c'est la magie de Project, Excel et PowerPoint : les outils liés au cycle en V donnent une grande impression de maitrise.

Les outils ne font peut-être pas tout : qui a déjà respecté un de ces jolis plannings ?

2. Au final, le produit sort.

... alors, de quoi se plaint-on ? 

La démocratie a ses défauts mais c'est finalement de loin le moins pire des systèmes. Pareil pour le cycle en V ? 

J'entends régulièrement dire que ce cycle en V, malgré tous ses défauts, a l'immense mérite d'endiguer l'anarchie et de faire en sorte que les projets finissent par aboutir. A coup de chair à canon façon Stalingrad, peut-être, mais aboutir quand même.

Une petite question : à quand faut-il remonter dans votre entreprise pour trouver une projet stratégique ayant couté une fortune ( des milliers de jours-hommes, dans les boites du CAC 40) et ayant été finalement abandonné pour limiter le désastre ? 

Sans doute pas 50 ans, toutes les boites ont eu le leur. Alors non, avec ce cycle en V, le produit ne sort pas forcément.

3. Personne n'est responsable dans un cycle en V

... et c'est carrément confortable.
Comme je le disais dans le dernier post, on fait plus confiance au processs qu'aux individus dans un cycle en V.
Donc quand un projet plante, on n'aura pas trop de mal à se dédouaner en prouvant qu'on a suivi le process. 

Et pour les quelques cas les plus chauds on pourra toujours dégainer le redoutable outil de consensus/auto-validation "ben quoi patron, t'étais en copie ! ".

4. Deux tonnes d'habitudes

Classique le poids de l'habitude mais on ne s'en lasse pas. On se fait à tout, même à avoir l'impression d'accoucher tous les mois, forceps à la clef. Les endorphines sont vraiment bien foutues...

5. Une louche de fatalisme 

"Les projets informatiques ont toujours fait mal. Si il y avait un remède miracle, ça se saurait !"
Et bien non, justement, pour toutes les raisons listées au-dessus, ça ne se sait pas...

Bon, OK, tout ça, ça se convainc, ça s'argumente, ça se retourne. Je termine maintenant par la raison la plus difficile à attaquer : 

6. Parce que ce sont les mieux placés pour changer de système qui ont le plus à y perdre.

et hop, ce sera pour un prochain post.

Founder Institute : un an plus tard

L’heure fatidique approche pour la promotion actuelle du Founder Institute : celle de la création de la boite et de la signature des bons de souscription d’action qui autoriseront grosso modo le FI à acheter des parts à la première levée de fonds.

Plusieurs incubés du Founder me demandent donc ce que j’en ai tiré un an plus tard. 

En deux lignes : oui, un an plus tard, je suis toujours ravi d’avoir participé à ce programme jusqu’au bout et d’avoir signé les fameux BSA.

A ceux qui se posent plus de questions, voici des éléments de réponse.

Oui, le Founder m’a aidé depuis la graduation.
Non, ils ne font pas le boulot à ma place.
Vous n’aurez donc que l’accompagnement que vous irez chercher. 

Quelques exemples en un an :

- J’ai alpha testé mon appli à leWeb, et je me suis débrouillé pour passer une demi-heure en tête à tête avec chacun des 5 ou 6 mentors américains et français qui étaient là. Que des pointures, et pas de cadeaux sur le feedback.
- Quand le big boss Adeo Ressi est passé à Paris, je me suis débrouillé pour le voir et on a discuté d'Opportuner.
- Quand le Founder a organisé des conférences à San Franciso, je me suis débrouillé pour y introduire Opportuner. Si finalement ça ne s’est pas fait, c’est mon choix, pas le leur.
- Je reçois tous les jours des demandes d'incubés d’autres villes qui demandent un coup de pouce de visibilité pour tel ou tel concours, libre à moi d’en profiter aussi.
- J’ai eu accès à plusieurs très bons plans via des co-incubés de ma session.

A ceux qui pensent développer leur boite à l’international : signez tout de suite.
A ceux qui pensent que le deal avec le Founder empêchera leur levée de fonds, allez discuter avec plus de business angels, pour séparer les papis de la vraie smart money.
A ceux qui pensent que le Founder continuera en mode « cours particulier » après la graduation, oubliez tout de suite. 

Je le reformule autrement : le Founder ne vous offre rien de plus qu’un réseau à très haut potentiel.
Un réseau ce n’est que la bonne terre d’un potager, ce ne sont pas des tomates qui poussent toutes seules…

 

L’agilité, c’est quoi ?

 Finis les préliminaires ici et là, rentrons dans le vif du sujet.

L’agilité en une phrase, c’est faire « mieux, plus vite, et avec les mêmes personnes ».

Pour moi l’agilité, c’est simple comme cette petite histoire :

Il était une fois une petite équipe de développeurs.
Ils rencontrent leur client, qui leur raconte la vision qu’il a en tête.
Ils discutent de cette vision.
Ils discutent encore pour connaître ses toutes premières priorités.
Ils s’engagent sur un petit périmètre très concret de deux semaines de travail.
Ils le réalisent, dans la joie et la bonne humeur.
Ils montrent le résultat au client.
Ils le font parler pour comprendre la suite, et pour savoir ce en quoi sa vision a changé.
Et ils recommencent, une fois, deux fois, 10 fois.
Et le projet grossit, et la vision évolue. Ensemble.

Tout simplement.

« Pas de quoi en faire une formation... » me disent les équipes que je propose d'accompagner. 

Si, parce que finalement le plus clair de mes formations consiste à casser la carapace des pratiques classiques pour laisser respirer le bon sens.
Si, parce que le bon sens en management fait parfois un peu peur.
Si, parce que vous ne mesurez pas encore que chaque mot a son poids dans cette petite histoire.

 

Poste startup marketing manager à Londres

Une startup française en belle croissance dans le domaine de l'e-reputation des marques cherche à embaucher un marketing manager France/UK/US, basé à Londres.

Belle boite, beau produit et fondateur bon esprit.

Contactez-moi si vous voulez des détails : nicolas à opportuner point com

 

 

 

Cycle en V : pourquoi est-il si méchant ?

Pour bien comprendre l'agilité, c'est essentiel de comprendre de quelles frustrations elle est née. Voici donc un nouveau post autour de la non-agilité.

Vous connaissez surement le la gestion de projet façon cycle en V. Si, si : faisabilité, spécifications, réalisation, tests, recette, etc

On appelle ça un cycle en V parce qu'on descend la réalisation du plus général au plus détaillé, puis qu'on remonte les tests du plus détaillé au plus général.

NB : Je parle ici plutot de développement info, mais ça s'applique très bien à l'immense majorité des projets. 

 

Sur le papier, c'est superbe, une vraie horloge : on décide soigneusement de ce qu'on va faire, on le fait, on le teste, et tout le monde est beau.
Dans la réalité vous aurez sans doute constaté que le papier est plus rugueux qu'il n'y parait. C'est beau, mais ça dérape dans tous les sens : votre beau planning sert plus à constater le retard qu'à le prévenir, et chaque demande de changement de périmètre est un psychodrame.

Qu'est-ce qui ne colle pas entre le papier et la réalité ? quelques pistes de réflexion...

1. Le cycle en V ne permet pas de changer d'avis.

Plus précisément le cycle en V ne prévoit à aucun moment d'ouvrir la porte aux changements de la part du responsable produit. On se met d'accord au départ, on fait, et il faudra attendre le prochain cycle en V pour changer quoi que ce soit.  

Si on a des cycles en V d'une semaine, pas de problème ( on a alors fait un premier pas vers l'agilité), mais la tendance que vous observez surement est plutot d'étaler un cycle sur 3 à 6 mois, voire un an.
Et dans notre glorieux XXIe siècle, il s'en passe des choses dans la vraie vie en un an... qui impliquent des changements de cap... qui créent des psychodrames dans les équipes de développement.

Plus insidieusement, ce cycle en V qui ne laisse pas de place au changement véhicule l'idée qu'un changement d'avis est un problème en soi, une perturbation tout à fait anormale qui ne devrait pas avoir lieu. 

Vous avez là un premier superbe lumbago structurel dans le cycle en V : le changement n'est pas le bienvenu, alors que la durée du cycle le rend inévitable. 

2. Le mirage de la planification

Le cycle en V part du principe que nous autres gens bien élevés savons planifier à long terme... ce qui est faux.

Pas besoin de vous rappeler le programme rêvé de vos dernières vacances par rapport à ce que vous avez réellement fait, ni votre dernière période de Noel, où même en vous y mettant deux mois à l'avance avec les meilleures résolutions, vous avez couru un peu partout entre le 20 et le 24 pour trouver vos cadeaux. 

Ce n'est pas si terrible de l'admettre : quelqu'un de normalement constituté a toutes les peines du monde à planifier correctement à plus de 15 jours ce qu'il va pouvoir réellement réaliser.

Il y a au moins deux problèmes qui font déraper au delà de 15 jours :
- le premier est lié à la vraie vie : des centaines d'événements et de décisions vont impacter significativement votre projet, dont mathématiquemnet plusieurs dans les semaines qui viennent. C'est tout simplement impossible de les prévoir.

- le second est terriblement humain : vous aurez forcément une impression de confort au début qui fera que vous serez systématiquement à la bourre à la fin. Une pile d'études sociologiques le montrent : nous sommes indécrotablement optimistes et sous-évaluons choniquement les risques. Etre à la bourre sur la fin d'une période de 15 jours, ça s'absorbe, sur la fin de 6 mois, ça fait mal.

En fait, le temps s'accélère progressivement dans un cycle en V.

Regardez par exemple le temps moyen d'un aller-retour de mails entre l'équipe opérationnelle (dév) et le responsable produit. Vous observerez un délai en gros d'une semaine en début de projet ( en phase de spécifications par exemple), et une heure à la fin ( en phase de tests à l'arrache).

Finalement ce temps qui s'accélère n'est pas un drame en soi, c'est le fait que la pression le suive de très près qui ne fait plaisir à personne.

La conséquence, c'est que c'est toujours la fin du cycle qui trinque.

Et la fin du cycle en V, ce sont toujours les tests. Qui dit moins de tests, dit davantage de bugs, et des bugs qui seront vus plus tard, c'est-à-dire en plein milieu du cycle en V suivant... qui sera déjà sous l'eau, etc. 

Je résume : basé sur une vision plus qu'optimiste de la capacité de planification d'une personne normale, le cycle en V crée mécaniquement non seulement de la pression mais aussi des bugs cachés, qui diminueront à l'avenir encore plus la capacité de planification de l'équipe.
Le cycle en V devient cercle Vicieux.

3.le cycle en V est ingrat.

Il est ingrat car comme on l'a vu au-dessus il crée lui même une bonne partie de ses problèmes.
Il est ingrat car il ne fait rien pour mettre en lumière la foule de petites victoires au quotidien.
Il est ingrat car c'est à ceux qui prennent le plus de risques ( ceux en bout de chaine qui doivent produire coute que coute) qu'on fait le moins confiance.

Ce cycle se construit effectivement le plus souvent sur un mécanisme de commande et de contrôle :
- des responsables hiérarchiques décident
- des opérationnels réalisent sagement suivant les process qu'on a pensés pour eux
- un service qualité s'assure que ces process sont respectés, ce qui est censé garantir la qualité du produit final.

La confiance est donc placée dans le processus et dans les outils de controle, et pas dans les personnes qui l'exécutent.

C'est ingrat de travailler avec des méthdoes qu'on n'a pas choisies, c'est ingrat de passer des heures à remplir des tableaux de reporting -que personne ne lira-, c'est ingrat de se faire taper sur les doigts parce qu'on n'a pas suivi une règle qu'on n'a pas choisie. 

Les inconvénients du cycle en V en 10 mots : rigidité, cocotte-minute et vaccin contre la motivation...
Mais alors pourquoi on l'utilise ? next post !

Vous en voyez d'autres, des lumbagos du cycle en V ?

Open Coffee demain : comment trouver des ressources techniques pour une beta

J'animerai l'OpenCoffe de demain pour donner mon retour d'expérience sur les méthodes pour construire un premier produit web quand on ne sait pas coder.

On parle beaucoup de s'associer sans forcément réaliser ce que ça veut dire et comment ça doit se passer. On parle beaucoup moins des autres méthodes et ce sera aussi l'occasion de leur mettre un coup de projecteur.

Je parlerai des moyens pour trouver des ressources techniques, des manières de les rémunérer, des écueils à éviter, de la dure réalité de ce marché et des points clefs à garder en tête...

C'est demain jeudi 17 mars de 10h à midi au café Elgi, 10 Rue St Marc, Paris 2e, M° Grands Boulevards. C'est gratuit, pas besoin de s'inscrire.

Et vous pourrez en prime y tester Opportuner...