Vous avez tué l’agilité, message d’un futur bien présent

Durant les accompagnements que je réalise auprès des entreprises informatiques, ou avec un pôle informatique, pour les aider à passer le cap de la croissance, à passer le cap des problèmes de cohésion, nous discutons très souvent de l’agilité.

Et il faut dire qu’il y a une véritable pression autour de l’agilité, aujourd’hui.

Jusquà un point de non retour, une mort assurée ?

Que cherche-t-on avec cet engouement autour de l’agilité autour de SCRUM ?

A remettre l’humain au centre de tout ? Vraiment ? Alors pourquoi nous nous centralisons sur une méthodologie (SCRUM) ?

A remettre un cadre, non pardon, un framework (#WTF), pour valoriser la synergie de groupe ? Ah oui, bien entendu, alors pourquoi nous dit-on encore aujourd’hui : c’est pas bien tu ne respectes pas Scrum, donc t’es pas agile …

A vouloir mettre en avant l’autonomie des équipes ? Tiens celle-là, elle mérite qu’on s’y attarde un peu plus !

Un secret de polichinelle – L’autonomie des équipes

Reprenons une des propositions de l’agilité, du manifeste agile :

Les meilleures architectures, les meilleures spécifications de besoins, et les meilleures conceptions émergent d’équipes auto-organisées.

Comment réussir à avoir des équipes auto-organisées si les équipes n’ont pas d’expériences ?

Des équipes non expérimentées

Vous avez sans doute lu mon dernier article au sujet de la mort de la formation ? Oui, cool.

Note: c’est vrai en ce moment, c’est assez glauque mes sujets, mais c’est pour la bonne cause. Vous savez, l’effet « Chapeau noir ».

Mais bon revenons à ce manque d’expérience. Le constat est sans appel, les entreprises manquent de salariés, dans plusieurs secteurs d’activités (informatique, btp, …).

Je souhaite pourtant ajouter une notion, un détail qui a toute son importance ici :

Les entreprises manquent de salariés qui ont de l’expérience …

Et là, je vous vois venir au front et me dire, et voilà Evan, tu contribues à cette idée qu’on ne peut pas débuter …vu qu’on débute souvent … sans expérience.

Oui tout à fait … si .. vous vous arrêtez de lire mon article ici, si vous n’avez pas lu mon dernier article au sujet de la mort de la formation 🙂

Pour vous rassurer, et que l’on puisse continuer cet article sereinement :

Ainsi, on ne va pas mettre ensemble des juniors, qui plus est, des juniors en agilité, dans un projet agile et hop le tour est joué ! Après, on s’étonnera d’avoir des propos du genre « pff de toute façon l’agilité ça ne fonctionne pas »

Et étonnement, cette réflexion fonctionne aussi avec une équipe faite de personnes qui ont de l’expérience dans leur métier. Mettez-les dans un projet dit agile, sans formation, sans accompagnement. Et observez le résultat …

Et pourtant c’est ce que font bon nombre d’entreprises aujourd’hui.

Aucun texte alternatif pour cette image

Un mea culpa

Alors, attention, ne vous y méprenez pas, je ne suis pas là pour accuser !

Je suis passé moi ausi par là, lorsque j’ai créé mon entreprise NETil (le .net agile). Le but de ma première entreprise : créer une entreprise totalement agile, pas que la partie SI.

Et ça a fonctionné, mais petit à petit, comme un oiseau qui fait son nid, comme on dit.

Et non sans mal … On apprend par l’expérience. Mes équipes avaient appris à être autonome, à vraiment travailler ensemble.

Comment : continuons l’article ensemble, des idées sont distillées dans la suite … 🙂

Des chef-fes qui veulent garder leur pouvoir

Comment réussir à avoir des équipes auto-organisées, si le-la coach agile est un-e chef-fe de projet déguisé-e ?

Ca vous surprend ? Regardez le nombre d’offre d’emploi où vous trouvez « Chef de projet agile », « Scrum master (chef de projet) ». Ou bien les missions intitulées « Scrum master », et lorsqu’on lit la description du poste, on détecte un « manager les équipes », ou bien « être responsable de l’équipe », ou alors, encore mieux « Effectuer un pilotage précis de l’équipe ».

Méfiez-vous de ces loups déguisés en mouton …

OK OK, je l’avoue, j’attise la peur ici … on dirait presque un sujet de JT.

Plus que le poste, c’est le positionnement, la façon d’aborder le métier qu’on ne veut pas changer :

On pense à tort qu’on a besoin de chef, de chefs qui dirigent, commandent. Et on prend pour exemple mon chapitre sur la non expérience des équipes, ou bien sur les erreurs faites par les équipes.

Garder le pouvoir, tout en faisant de l’agilité .. pardon, tout en disant faire de l’agilité, c’est comme dire qu’on sait voler, et que l’on est passager dans un avion.

Un outillage plutot que des humains ?

En fait, j’ai envie de revenir sur SCRUM (ça fonctionne aussi pour tous ces outils que l’on trouve aujourd’hui et qui font sensation #buzz).

Reprenons ce que je disais en début de cet article : « c’est pas bien tu ne respectes pas Scrum, donc t’es pas agile », ou bien « quoi tu ne fais pas de daily scrum, pff t’es pas agile ».

Vraiment ? On en est encore là ? Je comprends tout à fait le besoin de se rassurer, de rassurer les équipes, les entreprises : « c’est bon, là je fais du scrum, ouff, je suis agile », mais de là à dire que l’on doit tout appliquer, n’est-ce pas là le contraire même de l’agilité ?

Bon nombre d’entreprises sont agiles, sans appliquer de méthodes, de frameworks #buzzword. Elles ont co-construit des processus dynamiques et agiles, et qui s’adaptent aux clients, qui s’adaptent au changement.

Et pourtant on vient leurs dire qu’elles ne sont pas agiles. On vient leurs apporter la voie de la sagesse, comme s’il n’y avait que cette voie-là (SCRUM, XP, …).

Ca me rappelle une certaine époque où certaines personnes allaient évangéliser (par pression) certaines autres personnes, en leurs disant : non ce que tu fais c’est mal, maintenant tu feras comme ça. (en me relisant, je note que cette idée est très vieille en fait).

Des discussions centrés outillage plutôt que collaboratif, écoute, échange

Et ça amène toujours ces discussions où l’on dit faire le Daily Scrum à 10h00 ou bien à 16h. Et que l’un est mieux que l’autre ….

Mais rappelons un autre principe du manifeste agile :

Les individus et leurs interactions, de préférence aux processus et aux outils

Et voilà qu’ici aussi nous sommes en train d’échouer, en nous centralisant sur les outils type SCRUM, type XP, type Kanban, ….

Des buzz words à n’en plus finir

Durant mes accompagnements, je cherche à comprendre au mieux comment fonctionne une entreprise pour détecter les points d’amélioration, et surtout, surtout aider l’entreprise, les équipes, à faire émerger d’eux-mêmes, d’elles-mêmes, les axes d’amélioration.

OK, et comment alors leur parler d’agilité, de la vraie agilité hein, pas celle qui est en train de mourrir, lorsque l’on découvre tous ces buzzwords qui se concurrencent les uns les autres ?

Ca a commencé avec SCRUM, ça continue avec les sprints, les user stories, les use case, les …. on parle maintenant d’entreprise S.A.F.E (il y a même des versions de SAFE), de devops, de secuagidevops, de … Et maintenant, on est en train de dire que SCRUM est mort, …

Tout ceci est contre productif, et continue à tuer dans l’oeuf un potentiel qui était pourtant bien parti pour éclore !

Une note positive – Transformer l’agilité, arrêter de l’imposer

Aucun texte alternatif pour cette image

Je reste convaincu que l’agilité telle que tout le monde veut la présenter aujourd’hui, surtout centralisée d’ailleurs autour de SCRUM, est morte, ou en fin de vie. Ca fait plusieurs années que j’en suis convaincu.

En pédagogie, pour transmettre, il est nécessaire de savoir vulgariser. C’est un premier pas pour permettre l’adhésion.

Le second pas, c’est oser se lancer. C’est oser avancer, donc faire le second pas. Celui qui va nous faire progresser.

Ce que l’on croit, c’est que tout va bien se passer. C’est une vraie première erreur ! Hélas, bien souvent cette découverte se fait sur un projet réel, pour un vrai client, une vraie cliente ….

Et si on pouvait accepter que la vraie agilité, c’est une équation assez simple :

équipe qui s’adapte au changement = apprentissage. Et la seule constante c’est le changement. Tout le reste c’est de l’humain, du travail d’équipe, et c’est tout.

Tant pis si vous faites des sprints de 6 semaines, et que vous ne faites pas de delivery en e2e testing. (private #joke)

Alors arrêtons d’imposer l’agilité telle que les livres le disent. Et essayons de ne plus utiliser des mots qui créent un clivage, qui sectifie les usages.

A la question : le changement … c’est ? Nous avons tous et toutes quasiment le même réflexe, répondre :  c’est maintenant.
Et pourtant nous allons voir ensemble que le changement, oui, c’est important, oui, nous devons l’apprécier, c’est aussi un autre slogan …. #teasing.

Passer d’un monde monolithique …

Vous me ferez un cahier des charges s’il vous plaît ? Un bon, un gros cahier des charges. Et surtout, n’oubliez rien dedans hein ! Car sinon, je vous congédie !
Ca vous rappelle quelque chose ?

Le cahier des charges, saint graal ?!

En informatique, et dans beaucoup de métiers d’ailleurs, le cahier des charges est LE document officiel qui permet de valider le démarrage d’un projet.
Ah pardon, j’ai oublié un autre hyper important qui est lié, et souvent son remplaçant : le devis

On n’a dieu que pour lui, on ne pense qu’à lui.

Souvent un fournisseur dira : hmm vous avez un cahier des charges ? Je ne travaille qu’avec un cahier des charges !

Et le client de répondre : oh oui, j’en ai fait un rien que pour vous, c’est bon on peut travailler ensemble ?

La minute historique

Dans ma première entreprise, NETil, on a toujours cherché à travailler en agilité avec nos clients. On ne souhaitait donc pas travailler avec un cahier des charges.

Or, si l’on n’avait pas le cahier des charges, on avait… rien d’autres. Le client se croyait décharger de toute responsabilité, tout travail à effectuer pour faire avancer son projet !

Et donc, pour tous les clients qui ne voulaient pas travailler en agilité, en réelle agilité, nous avons mis un mur de protection devant eux : le cahier des charges.

Un contenu important, un contenu exhaustif

Or, construire un cahier des charges ça ne décrète pas, ça s’apprend ! Réussir à décrire les besoins au plus précis, ce que l’on attend exactement est … difficile et souvent impossible.
On doit le réaliser le plus clair, le plus exhaustif !
Et … ça prend du temps ! Tellement de temps !

Du temps qui file, des besoins qui ne changent pas ?

Et durant tout ce temps, surtout aujourd’hui, on pense que durant tout ce temps de rédaction du cahier des charges, les utilisateurs ne vont pas avoir des besoins qui vont changer.

Et l’on se trompe ! Oh que l’on se trompe !

Il est fini ce temps du monstre cahier des charges monolithique qui ne bougera pas durant les 2 ans de mise en place de l’application (voir plus pour certaines applications).

Bouclier juridique

Et puis, nous voilà, comme dans mon exemple chez NETil, à nous protéger.

En fait, nous sommes en guerre face à notre client. Et le cahier des charges est notre château fort. Il va nous protéger quand tout va mal se passer.
Car, on le sait non, tout doit mal se passer .. et ce n’est surtout pas de notre faute en plus !

Et si nous cessions de construire des châteaux forts juridiques ? Et si nous acceptions le changement même dans la construction du cahier des charges ?

… à un monde qui change, tout le temps

Détruisons les barrières qui s’opposent à une vraie collaboration avec notre client. Vous vous souvenez : le client n’est pas roi, nous ne sommes plus au temps féodal !

Et acceptons d’abord que tout change, tout change, et tout va changer. Et de plus en plus vite.

La minute historique

Chez NETil, nous avions répondu à un appel d’offre d’un gros client. Nous avions gagné ce projet. Cet appel d’offre s’était basée sur l’analyse d’un cahier des charges réalisé par le client.
Cela leurs avait pris 2 ans pour le rédiger ! OK OK, admettons qu’il soit bien réalisé, qu’il soit clair et que l’implicite ait bien été tué
Nous avons démarré le travail de production, et dès le démarrage, le client nous annonce : en fait le cahier de charges ne vaut plus rien, on va devoir en reconstruire un avec vous ! #WTF

Le changement, c’est maintenant !

Donc, nous allons accepter que le changement c’est maintenant, et c’est tout le temps.

Comment fait-on pour s’adapter à ce changement ?

confiance client
Photo by Fancycrave on Unsplash

Une des pistes proposées par le manifeste agile, et j’ai bien dit piste, j’ai pas dit méthode (screugneugneu! :)) :

Sur le papier, ça donne envie, n’est-ce pas ?

Et en fait, ça fonctionne … uniquement si l’entreprise est prête.

Avoir une culture du changement

Et ici, on touche du doigt le point le plus important. On a beau dire, je suis agile, je suis agile, j’aime le changement. Si autour de soi, personne ne l’aime …. si la culture du changement ne fait pas partie de la culture de l’entreprise, du client, de la culture d’entreprise du client …

cadeau empoissonne deception
Photo by Kira auf der Heide on Unsplash

Et bien, on est mal barré  

Smile

Ainsi, je vais amener, (ça y est, oui, vous avez tenu tout l’article pour lire cette information, bravo ), une correction à la phrase : le changement c’est maintenant.

Nous allons plutôt dire : le changement ça s’apprend !

Le changement ça s’apprend

Vous qui me lisez depuis un bon moment maintenant, vous savez que je suis un état d’esprit, une philosophie, un art de vivre même : Kaizen !

Je vous rappelle l’idée :

Kaizen, c’est l’amélioration continue en réelle ! On ne parle plus de faute, mais d’essai, d’apprentissage (apprendre par tâtonnement, par réussite / échec)

Alors, plutôt que d’imposer que votre entreprise aime le changement, plutôt que l’imposer à votre client :

Co-apprenez à changer, à accepter le changement !

Comment ? (et oui, on est chez evan le concrétiseur tout de même !)

  1. En faisant des itérations courtes
  2. A chaque fin d’itération, on analyse ce qui a été fait de bien, et ce qui pourra être améliorer l’itération prochaine
  3. A chaque début d’itération, on cherche à mettre en place au moins une action de changement à tester, travailler
  4. Et on itère,
  5. Et on itère !

Alors, prêt-e, pour le changement ? Alors apprenez à l’apprécier .. continuellement

Smile

Vous voilà devant une fenêtre, et flûte, elle est fermée. Non, je suis certain qu’elle était ouverte, je suis arrivé-e par là, vous vous dites.
Vous essayez de sortir, bing, la fenêtre. Vous réessayez, bing, encore la fenêtre. A gauche, à droite, rien n’y fait.
Vous avez beau persévérer, vous voilà prisonnier-ère ! Vraiment ? Sortons ensemble du théorème de la mouche.

Être persévérant-e, une vraie qualité

A la base, persévérer dans une action, un projet, tant que l’on n’y arrive pas, c’est bien ?
C’est une vraie qualité.

Prenons l’exemple des résolutions de début d’année.
Beaucoup en font, peu les réalisent.

Je vous rassure, je ne suis pas là pour vous critiquez, mais avouez que la plupart du temps les résolutions que l’on prend, et bien ….

Ce sont de belles intentions, mais rien de concret n’en sort.

Je vais arrêter de fumer, je vais faire du sport une fois par semaine, j’arrêterai de râler, ….

Tiens, en parlant de faire du sport une fois par semaine.
On a bien envie d’y croire qu’on va réussir, mais … au bout d’un mois ou deux, ça devient vite saoûlant. Et puis, j’ai mal à ma cheville, je suis fatigué-e, ….
On a vite pris le pas d’arrêter, et de remettre à l’année prochaine ce dont on espérait tant réussir cette année.

Cette fois-ci, je vais réussir

Alors comment réussir cette fois-ci ?
Et bien cette fois-ci, vous allez être persévérant-e. Vous allez résister, insister. Même si c’est difficile, même si par moment vous allez avoir des coups de mou.

Selon le Larousse, être persévérant-e, c’est être doué-e de persévérance. Et bien vous avez bien fait de venir lire mon article, n’est-ce pas !
Ce que l’on lit juste après cette superbe définition, c’est :

Persévérant, il finira par réussir.

On note ici cet avantage que l’on a, selon le Larousse, à être persévérant-e : c’est l’une des clefs vers le succès. (Rien que ça !)

Plus sérieusement, voici la définition de persévérer :

Demeurer ferme et constant dans un sentiment, une résolution : Persévérer dans une recherche, dans une erreur.

C’est une vraie qualité, une valeur forte.

theoreme mouche

Pousser à l’extrême

Alors pourquoi se mettre à la critiquer cette bonne vieille persévérance ? Elle n’a l’air d’avoir que du bon, non ?!

OK, reprenons l’exemple en introduction. Bien entendu, vous n’allez pas réagir comme ce que j’ai décrit, si ?
Je décrivais ici le cas d’une mouche.

Que fait la mouche quand elle rentre chez vous ?
Elle se colle à votre fenêtre et cherche tout le temps à sortir. Elle va tester à droite, à gauche, encore à droite, ah non, un peu à gauche, … ah non, tiens, elle va essayer un peu plus haut.
Vous l’aurez remarqué, ça peut paraître bien con une mouche, surtout quand ça veut sortir.

Pourtant si elle avait bien regardé, vous êtes en train de vous dire, elle aurait vu, elle aurait découvert le Grand secret : la fenêtre n’est même pas fermée !

 

Un manque de recul – Savoir disrupter un système

En fait la mouche est victime d’une de ses plus grandes qualités (en plus d’avoir la capacité de ne pas réussir à se faire attraper).

Elle insiste, insiste, sans se dire : hey, et si je prenais un peu de recul ? et si je sortais de mon système en deux dimensions (abscisses, ordonnées) pour aller voir si je peux pas sortir ailleurs.

(Je vois déjà venir les passionnés d’animaux, d’insectes : heu, mais si, elles y arrivent quand même à force les mouches à sortir. Je tiens à les rassurer : vous avez bien raison. Mais ici, c’est un exemple caricatural, pour l’image).

Réussir à ne pas être trop persévérant-e devient alors une qualité.
Tout est d’ailleurs souvent dans la mesure, l’équilibre.

Exemple : quelqu’un qui s’entête dans une idée trop longtemps est vu comme têtu, celui qui assume ce qu’il sait est vu comme obstiné ou bien avec de l’assurance.

 

Des aides pour s’en sortir

Heureusement, nous ne sommes pas des mouches ! Si si, je vous assure !

Et l’on peut éviter de tomber dans le théorème de la mouche au travail, à la maison.
Comment ?

La règle du demi

Si vous appliquez plusieurs principes que je vous proposais dans les 5 astuces pour gagner du temps, du blog Parent Entrepreneur, vous avez découvert la Loi de Parkinson.
Cette loi vous propose de fixer des délais serrés pour s’obliger à faire les choses dans ce temps écourté.

Maintenant que vous l’appliquez, appliquer la règle de demi : si vous avez prévu deux heures pour une tâche, faite une pause après une heure.
Et demandez-vous :

Ça fonctionne très bien dans des périodes où vous avez un problème à résoudre : une recherche compliquée, un algorithme à faire où vous bloquez, une étude compliquée où vous buttez, un puzzle où vous n’arrivez pas à trouver une pièce, …

Il existe d’autres techniques … je vous en parlerai dans de prochains articles, de prochaines vidéos.

 


Vous l’aurez compris, être persévérant-e est une très grande qualité, valeur. Mais appliqué-e jusqu’à l’absurde nous fait devenir des mouches.
Et vous, vous réagissez comment quand vous avez un problème ? Vous persévérez jusqu’à y arriver ? Tout le temps ?