Agilité : Chaos, Honnêteté & Valeur

Agilité : Chaos, Honnêteté & Valeur

Parce qu'on oublie souvent le pourquoi de l'agilité, et qu'on se concentre beaucoup sur le comment, j'avais envie d'écrire quelques lignes sur le sujet.
Je resterai humble en disant que cela ne reste que mon interprétation et une sorte de prise de recul sur mon vécu, et cela n'a rien d'objectif.

A mon sens l'agilité doit être mise en place pour deux raisons majeurs et une motivation profonde:

• raison 1 : remettre le principe de valeur au coeur de nos projets
• raison 2 : se donner les moyens de canaliser le Chaos inhérent à la plupart de nos projets
• motivation : reprendre une part conséquente d'honnêteté intellectuelle

L'honnêteté

Je commence par ma première motivation : redevenir honnête et arrêter ce jeu d'entre soi, insupportable entre nos clients et nous.
Appelons un chat, un chat, et essayons de:

• comprendre les motivations de chacun
• intégrer les enjeux de chaque partie
• partager les difficultés

Je dissocie un tant soit peu l'honnêteté de la transparence. D'ailleurs il existe deux mots différents.
La transparence est plus un biais, un outil. J'ouvre mes volets, vous pouvez regarder ce que je fais, voire comment je le fais.
La transparence se matérialise souvent sous forme de management visuel, de kpis, en donnant accès à son travail, ses sources.

L'honnêteté va plus loin dans le processus de partage, car on donne les raisons réels de l'action.
Les moments où l'honnêteté est important est lorsque le processus humain est requis :

• le daily meeting : où on partage de manière ouverte ses difficultés, ses succès
• le planning : où les priorités sont partagés
• la démo : où on sait expliquer pourquoi on a fait ses choix, où le feedback prévaut sur la validation elle même
• ....

C'est un effort intellectuel très important.

Canaliser le chaos

L'agilité ne règle pas vos problèmes. Pour être impertinent, je dirai même bien au contraire. C'est exagéré, mais....
A mon sens, via le principe d'honnêteté, j'ai le sentiment qu'en agile, nous mettons en exergue les problèmes. Contrairement, à d'autres manières de travailler, nous n'occultons pas les problèmes.
Ils sont là, la transparence et l'honnêteté nous pousse à les afficher, et à en parler. Cela peut déranger, mais...

Ensemble, nous décidons que :

• nous sommes capable de pourvoir une solution au problème, qui induit une charge de travail, qu'il faut inclure dans le plan projets
• nous ne sommes pas capables de trouver une solution acceptable dans le délai :
• il faut alors le prendre en compte, comme étant un frein dans notre quotidien
• il faut imaginer un plan projet différent qui permette d'aller vers la vision malgré les difficultés

Exemple de problèmes : juniorité de l'équipe, adhérence technologique, ou sur un autre projet, limite technologique, besoins non clair....

J'insiste sur le fait qu'en agile, les problèmes impactent forcément le projet. Dans les autres méthodes, l'impact existe tout autant, mais ils sont souvent occultés, jusqu'à arriver à un nexus, où des situations de crise apparaissent, car le problème aura mûri dans son coin, et engendre finalement un point de contention, menant à la situation de crise.

J'ai souvent l'impression qu'en cycle en V par exemple, le chef de projet dresse un mur dans son outil de planification en alignant ses barres représentant ses éléments de planification.
Cela donne l'image, d'une digue érigée, sur laquelle les problèmes viennent tenter de rompre la digue, et en ajoutant des éléments dans son planning, il espère renforcer la digue.

C'est pour cela, que j'ai utilisé le terme de canaliser le chaos en agile. J'aime prendre en compte l'environnement dans lequel je suis, et éviter de créer une rupture par rapport à celui ci.
Je n'érige pas une protection autour de nous, en espérant que rien n'arrive, je préfère ouvrir un courant qui passe dans le projet, mais dont le débit est mesuré, et prise en compte dans l'élaboration de la structure que nous construisons.

Nous ne pouvons pas éradiquer le chaos, ni le contrôler, mais nous pouvons le prendre en compte, et le canaliser pour qu'il reste à un niveau acceptable pour le projet. Au pire, il induira de modifier notre approche du projet, car le courant est trop important.

De la valeur

Le temps c'est de l'argent. Un adage bien souvent resservi, comme une potion amère, mais qui comporte ses vertues.
Oui le temps c'est de l'argent, nous en avons bien conscience, alors tentons d'utiliser ce temps et cet argent, pour créer le maximum de valeur.

L'honnêteté intellectuelle est un point focal de nouveau dans cette approche de maximisation de la valeur.

Les contextes projets sont tous différents, néanmoins la constante est que le délai est court, et les moyens insuffisants.
Insuffisant pour faire quoi? Pourquoi ne pas rendre le travail supportable, en se concentrant sur ce qui apporte de la valeur.

Trop souvent, nous avons des gens en face de nous, qui ont des exigences de toute part, sur tous les sujets, et qui veulent tout à tout prix.

Il est important de revenir aux basiques, et de bien comprendre les enjeux du projet. On nous demande de faire A, B, C, D.
Finalement, en creusant la raison d'être du projet, l'entreprise, le métier a besoin d'une foncionnalité Y. D permet d'ouvrir cette fonctionnalité, B permet de construire D, et C sont les référentiels alimentant B.
A est l'élément différenciant de la fonctionnalité Y.

Il existe plein de manière de faire. A mon sens, le refactoring n'est pas une difficulté pour moi. Au final, il existe dans tous les projets, mais est souvent masqué, occulté, ou parfois pas fait, alors que nécessaire.
La plupart des chefs de projet choisiront de commencer par C, B, A et finir par D. (ou D et A).

Moi je propose de commencer par D, car finalement, c'est ce que les utilisateurs ont besoin. Si on a fait D, le projet est fini à 70%. La brique B et C, sont la plupart du temps des éléments techniques, de confort, d'automatisation.
Ils apportent rarement de la valeur métier. Ils deviennent très important, si le cycle de travail induit, correspond à une donnée financière importante. L'automatisation permet de gagner 50j de travail par mois.
Néanmoins, cela reste une donnée financière, et pas une valeur métier.

Le fait de construire D en premier, permet également de rassurer le métier sur la compréhension de son besoin, et surtout de povoir voir un feedback rapidement sur son besoin réel, et de pouvoir adapter D tout au long du projet, pour maximiser la valeur de la fonctionnalité.
Ces évolutions de D impacteront forcément A, B et C, alors autant les démarrer une fois que le besoin est cerné.

Et A, quand le fait on? A vous de voir, mais si D satisfait pleinement le business, est ce que A n'est pas superflu. Est ce qu'il n'a pas été un argument pour convaincre le management de lancer le projet.
A vous de vérifier la valeur...

Pascal Ogil