Mon nouveau blog pro : Agile après l'Ecole

http://agileapreslecole.fr

J'aimerai y partager les finesses des méthodes de développement logiciel Agile/Lean, celles qu'on ne voit pas à l'école, que je découvre à la pratique -d'où le titre.
Read more


Peut-on tout étiqueter “Agile” ?

L’autre jour, j’ai eu une réaction épidermique, sans savoir vraiment pourquoi, alors que je discutais avec Jean-Claude Grosjean, mon binôme en mission, de son article sur le management agile. J’ai eu besoin de tirer mes idées au clair, voici ce qui en est sorti.

Quel est mon objectif ? Utiliser des termes précis pour décrire mon domaine (le développement logiciel) afin de l’enseigner et échanger avec mes pairs. Créer et partager un cadre de pensée, basé sur des concepts finis. On ne peut pas coller l’étiquette “agile” sur tout ce qu’on touche.

Au travers du développement agile nous découvrons de nombreux sujets connexes : complexité des organisations, facilitation des échanges, dynamique d’équipe, etc. Nous les associons au thème de départ, mais je pense que c’est un abus. Ces concepts sont connexes à notre domaine, mais ils ne lui sont pas spécifiques.

Je pourrais parler de management agile dans des activités précises, comme la gestion de portefeuille de projets itératifs, par exemple. Pour moi, un manager au carrefour du leadership et de la gestion n’est pas spécifiquement “agile” : cette posture de management existait déjà hors de notre domaine.

A titre de comparaison, on ne fait pas d’amalgame sur la facilitation. Nous en utilisons quelques outils classiques (agenda, support visuel, divergence/convergence, etc), et pourtant je n’ai jamais entendu qu’on faisait de la facilitation “agile”. On en utilise, c’est tout.

Poussons le bouchon : les post-its sont-ils agiles ? Tant qu’ils restent de simples bouts de papier adhésifs que votre mère collait sur le frigo, non. Mais quand ils seront pré-imprimés, par exemple en cartes de user stories spécialement conçues pour Scrum, oui, on pourra parler de post-its agiles.

Alors, pourquoi ça m’a piqué ?
En fait, je crains qu’on manipule l’Agile comme une marque, qu’on repositionne pour attaquer de nouveaux segments de marché. J’ai peur d’être décrédibilisé, comme si je fourguais mon produit, alors que je fais juste les recommandations qui me semblent pertinentes dans le contexte.
Je ne vends pas l’Agile, je vends mes conseils, je ne veux pas qu’on se méprenne.

 Bon, en réalité ça me pique pas tant que ça. Je survis très bien aux contradicteurs qui m’envoient “tu vends ta sauce”, ils me donnent l’occasion d’expliquer ma démarche.
Finalement, c’est peut-être mon côté obtus : pour moi c’est important d’utiliser des termes spécifiques pour des concepts définis, ça me parait une condition nécessaire à la progression de toute science. Sinon… “ça m’énnnneeeeeeeerve” (air connu).

 


La vraie nouveauté de la keynote Apple WWDC 2013

J’avais commencé à regarder les keynotes Apple pour analyser les techniques de présentation de Steve Jobs. Puis j’ai continué quand la pomme a commencé à s’emballer, en dévoilant année après année le macbook air, l’iphone, l’ipad, juste par impatience technophile. Bref, c’est devenu une habitude, même si je me suis parfois ennuyé.

Maintenant Steve est mort, je crois que cette keynote (WWDC 2013) est la 3e ou 4e sans lui. J’ai lu qu’elle marque l’air post Jobs car elle montre enfin des innovations, des produits nouveaux : iOS7 à l’interface totalement revue, le futur Mac Pro tout cylindrique. Moi ce sont les présentateurs qui m’ont marqués.

Pour la première fois, les patrons, Schiller et compagnie, s’éclataient sur scène. Ils étaient enthousiastes, ils se lâchaient, ils avaient l’air vraiment fiers de leurs nouveaux produits. Avant, on les sentait coincés, entrainés à imiter timidement le phrasé de leur leader : mots bien détachés, superlatifs à tout va. Mais au lieu de l’air passionné de feu leur boss, ils avaient l’air de répéter leur texte et de mal le jouer. Maintenant ils s’expriment, on sent qu’ils pensent ce qu’ils disent. Et ils ont l’air d’avoir le feu ! (… ok, sauf Tim Cook qui continue à imiter)

En analyse systémique, on dit “le produit reflète l’équipe”. Il vient de là mon espoir suite à cette Keynote : la nouvelle team de direction Apple vient de prendre son envol, donc les produits ne devraient pas tarder à suivre.


Rallonger ou pas les itérations

La question est super classique : “on arrive pas à terminer tout ce qu’on a commencé, on pourrait pas rallonger les sprints ?”
C’est un piège. Si vous n’arrivez pas à terminer ce que vous avez commencé, 2 solutions s’offrent à vous : rallonger les sprints, ou faire moins de choses à la fois.
La seconde option est ma préférée, celle qui est recommandée : l’équipe commence une histoire, deux à la rigueur, et on en commence pas d’autre avant d’avoir terminé.
Problème souvent observé : les histoires sont trop grosses pour être terminées en un seul sprint. Donc pour en faire moins à la fois, il faut découper les histoires, diviser les fonctionnalités jusqu’à avoir un rythme de travail fluide, et peu d’encours.

Pourquoi l’allongement des sprints n’a pas ma préférence ? En fait, on risque de doubler le problème : 2 fois plus de planification nécessaire, risque d’avoir 2 fois plus d’encours, et 2 fois moins de rétrospectives pour s’en rendre compte.

 


Confiance et contrôle, application aux jeux de rôles

Je relatais ailleurs comment, paradoxalement, une équipe avait amené plus contrôle sur son travail en se faisant confiance.

Ca me fait penser à une pratique que nous avons instauré autour de notre table de jeux de rôles pour vérifier que personne ne triche au dés.
Je ne sais plus si j’ai déjà parlé des tricheurs dans les communautés de joueurs, mais ce n’est pas un phénomène rare. Et c’est parfois une plaie. Ils ne l’avoueront jamais pour eux-mêmes, et comme ce sont des amis, les confronter pourrait créer une crise. Donc on a cet espèce de consensus : personne ne triche, mais on contrôle les jets de dés.
Traditionnellement, la tâche de contrôle incombe au maître de jeu : “tu jettes tes dés quand je regarde”. Mais le MJ, pendant la partie, il est généralement débordé, alors les joueurs l’attendent, souvent. Et d’ailleurs, pourquoi ce serait seulement à lui de contrôler ? Tous les joueurs sont embêtés lorsqu’un joueur triche au dés ! Il déséquilibre la partie, s’accapare les réussites, c’est chiant pour tout le monde. Si vous avez déjà essayé de jouer avec un gars qui “réussit” 8 fois sur 10 des jets à 30% de chance, vous comprenez comme c’est pesant.

Chez nous, les joueurs sont chargés de se contrôler entre eux. La responsabilité partagée est posée : on ne triche pas, mais comme la tentation peut être grande, tout le monde contrôle tout le monde. Entre amis.
Quant au maître de jeu, il se focalise sur son rôle : animer un beau scénario.
Même conclusion que dans des articles précédents : on joue ensemble.
—-
Edit : lien vers l’article “Confiance et contrôle” sur Agile après l’école, mon blog sur l’agile


Comment accueillir une interruption de réunion

Le boss a ouvert la porte : “J’ai vu les gens du market’, vous en êtes où ?”. Tout le monde s’interrompt. “Pour la newsletter ?” répond Magali, la responsable produit. “Non, pour les maquettes, apparemment ils veulent les changer. C’est hyper important pour eux, je vous rappelle qu’on a un projet top visibilité, là”. Et la conversation a continué. Nous avons attendu son départ pour reprendre le cours de notre revue d’agenda.
Nous avons attendu. Et je me demande si je suis le seul scandalisé. Je dis “scandalisé”, je devrais dire “bouillonnant”, mais je ne le montre pas, après tout je suis coach, c’est pas moi, l’équipe.
Personne n’a osé interrompre le chef. Stupeur et tremblements. La discussion reprend. “Où on en étais déjà ?”. Visiblement, Magali n’est plus avec nous, elle pense aux maquettes. La graphiste aussi.
Merci le chef.

Alors, comment gérer ce genre de situation ?
On ne devrait déjà pas l’accepter. La réunion est coupée net, la productivité à zéro. C’est pourtant pour le chef qu’on bosse.
Pourquoi a-t-il cru que notre réunion était à ce point si peu importante ?
Parce qu’en acceptant son interruption, on lui a dit que c’était le cas.

Accueillir l’interruption
Comment j’aurai aimé qu’on gère cette interruption ?
“Bonjour chef. On est en pleine revue de planning, ça nous demande d’être focalisé sinon on va se déconcentrer. On termine dans 45 minutes, est-ce que ça peut attendre jusque là ? Sinon, si tu as besoin de quelqu’un, je vous propose d’aller en discuter dehors pour qu’on puisse continuer le planning.”
Ca s’appelle “accueillir l’interruption”. Ce qu’on peut y voir simplement, c’est qu’on explique avec pédagogie pourquoi son interruption pose problème, et on lui offre des options, plutôt que de le rembarrer. Chef ou pas chef, il peut comprendre l’importance de votre réunion.

À ces conseils, je reçois souvent des objections comme “Mais là c’était le chef” ou “Mais c’était un problème urgent”.
Face à une interruption, quel est le message que vous voulez passer, “pas de problème, chef, ce qu’on faisait n’était pas important” ? J’imagine que non.
Notre temps et nos occupations sont précieuses. Si nous voulons que les autres respectent notre activité, nous devons leur dire.
Si votre chef vous interrompt en réunion, gérez-le, c’est une opportunité de lui montrer… que vous travaillez.