Savoir ce que l’on peut faire amène à l’auto responsabilisation

Lors du premier jour du ScrumDayFr, j’ai pu assister (Comme peut-être certains d’entre vous) à une conférence que j’ai trouvée super intéressante !

« Reinventing organizations » par Michael Sahota et Olaf Lewitz
vous pouvez trouver le Slideshare de la présentation ICI

Cette conférence passionnante nous apprenait en substance que « Faire de l’agilité » différait d' »Être agile » (« Doing Agile =/= Being Agile« ) et qu’il y avait des différences fondamentales entre les pratiques agiles, et l’agile mindset. On comprend donc que au delà de la stratégie, et de la tactics, la culture d’entreprise occupe une place majeure dans le fait d’être agile.

When you listen to your guts how does it make a difference ?

Olaf Lewitz

« Small And localized changes leads to failure or limited success »

Michael Sahota

whereisagile
Il y présente un magnifique modèle de progression vers l’agilité.

On peut y voir par exemple que pour parvenir à l’auto-management (l’auto responsabilisation ou self management) il faut d’abord passer par l’octroi de plus de pouvoir aux individus ou aux groupes pour agir sur leurs conditions de travail (empowerment)

Knowing what you can do leads to self responsabilization

Olaf Lewitz

2. Ensuite une petite images qui n’était pas prévue à la présentation, mais qui a émergé des tables rondes organisées pour l’organisation. (désolée pour l’angle de vue pas terrible)

VAST-Cycle

Ce qui n’a pas manqué de me rappeler ce magnifique livre (et Ted Talk de Brene Brown)

3. Enfin les différents indices de mesures pour savoir où se positionne vraiment l’organisation concernée :

Everything you do reshapes the way your work, look at your desk’s placement for exemple… »

Olaf Lewitz

Trust
Trust no one 0 < = = = = = = = = = = > 10 Trust

Openness Level
Keep Calm and cover your ass 0 < = = = = = = = = = = > 10 Vulnerability

Safety Level
Fear 0 < = = = = = = = = = = > 10 Safety

Connexion level
Alone 0 < = = = = = = = = = = > 10 Authentic Connexions

Wholeness level (capacité à être soi-même, ou « entier »)
Wear a mask 0 < = = = = = = = = = = > 10 Whole personn

Power and Leadership
Centralized 0 < = = = = = = = = = = > 10 Distributed

Information Acess
Restricted 0 < = = = = = = = = = = > 10 Transparence

Planning and Control
Predict and Control 0 < = = = = = = = = = = > 10 Emergent (en fonction des besoins lorsqu’ils se présentent)

Performance and compensation (répartition des mesures de performance et rémunération)
Centralized 0 < = = = = = = = = = = > 10 Distributed

Après cette analyse vous devriez pouvoir positionner votre société par rapport à l’agile mindset ou plus précisément la « culture agile »

plan

Conclusion :

Tout cela reste mon retour suite à une conférence et je n’ai pas (encore) lu le livre qui a inspiré ce talk, mais ça m’a non seulement donné envie, mais cela m’a aussi bien inspirée, et je n’avais pas eue autant de palpitation depuis les TAZ de Hakim Bey (mais cela sera peut-être l’objet d’un autre post). Et vous ? ça vous inspire ?

Et Dieu Créa l’Agilité pour les projets…

Au départ, au commencement, la gestion de projet Agile c’était meugnon, plein de grands principes et de jolis propos, visant à rendre une meilleure et plus rapide qualité de service, de faire apparaitre plus vite des outils… Ben oui, au lieu de faire de gigantissimes expressions besoins, des spécifications à n’en plus finir, des cas d’utilisations discriminant, et déterminant, à la pèle en veux-tu-en-voilà , le tout pour partir gentiment en excursion sous marine de mise en œuvre pour parfois revenir, au mieux, en ayant été oubliés (mais payé) ou, au pire, en ne correspondant plus aux attentes qui avaient évoluées entre temps (les coquinoutes), on pouvait alors prôner l’Agilité, la Souplesse, le Dynamisme ! Et c’était aussi émouvant que la déclaration d’indépendance, que l’abolition de la l’esclavage et que l’invention de la roue.    

Les développeurs étaient  tout le temps, à s’agiter sous les yeux d’un représentant métier et à lui demander tout plein de choses à faire, et le chef de projet passaient son temps à poser des questions  ça donnait la garantie certaine qu’ils bossaient et qu’ils essayaient au mieux de répondre aux besoins…  

Oui mais voilà, du coup, il a fallu mettre en place des modes de fonctionnement très très rigoureux, parce que le manifeste qui disait que la « collaboration des parties » devait prendre le pas sur la contractualisation, a fait déborder un peu les caprices de la clientèle dans des proportions budgétaires aussi hasardeuses qu’exponentielles.

C’était de fait, donc, plus cher mais au moins là du coup, on savait dans quoi on dépensait, puisqu’on le suivait à la semaine parfois à la journée, alors open-bar on faisait sa liste de course et en toute mauvaise foi on osait dire que les développeurs, qui travaillaient déjà comme des chevaux de poste qu’on remplaçait régulièrement, tellement on les usait moralement, n’en faisaient pas assez dans le périmètre du projet.

Et c’était bien là tout le problème. Le périmètre du projet n’étant défini que dans ses grandes lignes, il devenait le tonneau des développeurs à défaut de celui des Danaïdes.

Ce qu’on tricotait avec ses petits doigts de développeurs, un jour, on le détricotait le lendemain pour faire une autre partie. A la fin, on était à la fois plus tellement sûr de réaliser un pull-over tellement on y avait mis de poches, de raccords, de bout de laines ou de ficelles, de ci de là et on avait tellement découpées de parties, remplacés des bouts par d’autres, que la cohérence technique ET fonctionnelle de l’ensemble en pâtissait, mais on était un peu incapable de comprendre comment on en était arrivé là, puisqu’on avait quand même assigné des chefs de projets qui étaient sensés assurer la maitrise de l’ouvrage, et donc, tout l’équilibre de l’ensemble…

Vite fait bien fait, il a donc fallu mettre en place un mode de gestion budgétaire tangible, compréhensible, pilotable, et à défaut d’un processus (puisque le manifeste encourageait plus à la compréhension humaine qu’à la rédaction de spécifications) mettre en œuvre une méthodologie et une flopée de bonnes habitudes :

Dans les grandes lignes ça a donné ça :

Phase 1 : Définir un périmètre fonctionnel à grosse maille, et un pré-découpage fonctionnel rapido –et les chiffrages correspondants) –Et demander la production en conséquence d’un budget pour cela.

Phase 2 : Prévoir le bas de laine : laisser quelques cases vides avec de quoi faire dedans, pour les fonctionnalités supplémentaires à venir (inévitablement) –et les clients, quand ils peuvent faire quelque chose, ils auraient tort de se priver, alors ils font-   

Phase 3 : Surveiller, quotidiennement la consommation des ressources et vérifier la cohérence entre la vélocité des équipes, le consommé, le reste à faire, et les briques fonctionnelles (et là tous les outils sont bons pour réaliser cela : de votre cerveau en passant par votre calculette, votre tableau Excellent, ou votre pur outil de gestion de projet qui envoi du poney),

Phase 3.1  s’affoler vigoureusement si à 1/3 du budget, 1/3 des fonctionnalités n’ont pas été réalisées. –à noter que s’affoler vigoureusement, ne consiste pas agiter les bras frénétiquement mais bel et bien de faire un rapport d’identifications des raisons du retard, et d’en avertir le client-

Phase 4 : A 2/3 du budget consommé, procéder à un contrôle rigoureux du Reste A Faire (le RAF) et des fonctionnalités ajoutées dans les cases vides, et déterminer s’il faut rentrer en phase 5.

Phase 5 : Commencer à faire de la gestion des priorités –et donc commencer les exclusions voire la chirurgie- et/ou à demander à nouveau du budget.  

(Bon, ça ne s’applique pas si vos budgets sont infinis, vos clients adorablement réalistes, vos investisseurs peu exigeants, et que le monde autour de vous est peuplé de Bisounours)

Et en contrepartie ça obligeait :

– A chaque nouvelle « évolution » demandée par le client, à défaut de la refuser, de tracer les changements (et donc de quantifier les impacts (non, les méthodes agiles ne réduisent pas le temps de travail, surtout pas du Chef de Projets) pour pouvoir faire un ratio du Delta entre ce qui était prévu à T0, ce qui s’est passé à T1, T2, T3…TN et à faire la différence finale entre TN et T0 pour en apprendre un peu plus.

– A accepter que les temps de réalisation que vous aviez communiqués étaient a) Soit compressibles (et du coup, un tout petit peu bidons ;)) b) Soit incompressibles (et du coup, un tout petit peu pas réalistes) c) n’étaient pas les éléments sur lesquels on devait faire reposer la « dynamiques » de la gestion de projet agile, mais uniquement les bonus de celle-ci. –je vous laisse réfléchir sur quoi on plaçait la souplesse alors ;)-

A Ranger sa timidité ET son stress au placard pour communiquer, collaborer et joyeusement interagir avec les équipes techniques mais aussi ne pas leur transmettre de parasites (entendez sollicitations directes qui auraient pu être évitées), parce que déjà bien assez sollicitées (même si bon, c’est connu, les teckos sont des gurus, et on ne leur confierait pas ce travail s’ils n’étaient pas experts ( ?!) –Mais oui, ayez la foi… et, si vous n’avez pas la foi : persuadez vous !-)

– A apprendre à dire « non » en souriant, ou à répondre « ok pour ça, mais du coup, on doit retirer quelque chose, on enlève quoi ? » comme on faisait avant, sans Agile, et qu’il fallait placer son sacro-saint « oui, mais » dans les conversations avec le client.

En conclusion, agile c’est ni mieux ni moins bien que les méthodes de gestion de projet « classiques », c’est différent, cela dit, ça ne doit pas empêcher d’avoir un peu de rigueur, et donc d’en connaitre les écueils.