Priorisation & pression

Je me rends compte que bien souvent les difficultés rencontrées autour de la priorisation sont souvent issues de la pression exercée.

Du fait de cette pression, on ressent des difficultés à prendre du recul, on est dans le faire, faire... et dans la peur de ne pas bien faire, et notamment en terme de quantité.

On se retrouve dans une sorte de cocotte minute infernale. La pression est constante, et le surplus de pression sort par la soupape.

On se retrouve dans un mode, où on ne peut rien changer, car on ne peut pas ouvrir la cocotte minute pendant la chauffe, et il faut même attendre un certain temps que la pression soit redescendue pour l'ouvrir. Une fois les ingrédients mis, on a un résultat à la fin quoiqu'il arrive.

Si on reprend une image culinaire, si vous faites mijoter un bon ragout, sans pression, vous pouvez voir régulièrement ce que vous faites, ajuster les saveurs, ajouter des morceaux, éventuellement, commencer à déguster, sélectionner les morceaux...

Les points qui favoriseront la descente de la pression, et je ne pense pas que cela soit une nouveauté, mais on a parfois besoin de reprendre conscience de l'importance de ceux ci.

1/ La vision

C'est important de pouvoir se dire ce qu'on veut faire sur le terme, se donner une trajectoire, des envies, une feuille de route, ou en tout cas un guide cohérent, nous permettant de vérifier que nous allons dans la bonne direction.

Cette vision sert notamment à arbitrer les éléments, car si un nouvel élément arrive, il faut voir si cela correspond à la stratégie, et s'il n'en fait pas partie de pouvoir acter qu'on ne le fera pas dans cette feuille de route.

C'est peut être aussi à la fin de l'année, car finalement, on a encore souvent des budgets annuels, de faire une rétrospective sur ce qui avait été prévu vs ce qui a été fait. Et par ce chemin, réfléchir aux processus de décisions, aux circonstances de décision, et pouvoir en conscience reprendre une route sans faire semblant, en honnêteté. 

C'est aussi l'occasion que chacun reprenne ses responsabilités, et que chacun trouve le pas qu'il peut faire vers l'autre.

Peut être aussi, qu'on va se rendre compte, que ce ne sont pas les bons interlocuteurs qui travaillent actuellement ensemble. Comment arbitrer, prendre des décisions stratégiques, quand on est en délégation?

2/ Le travail capacitaire

Au final, quelque soit l'argent que vous injectez, on est toujours limité par la capacité des hommes dans leur travail. Ce n'est pas parce que vous avez ajouté 10 développeurs, que vous irez dix fois plus vite. C'est un leurre.

Devenons honnête sur notre capacité à faire, et nos limites, et utilisons les comme une valeur, une source de partage.

C'est un principe fort qu'on retrouve dans Kanban, rendre visible le travail, mais aussi les limites des équipes en terme de capacité à chaque étape du cycle de vie de la demande.

Dans une relation client/ fournisseur, vous serez toujours dans cet espèce de négociation qui ne satisfait personne au final, car chacun essaye de tenir ses objectifs personnels, et on a du mal à s'inscrire dans une stratégie d'entreprise.

Idéalement, il faut dépasser cela, et créer un partenariat entre les différentes parties. Chacun devrait pouvoir comprendre les contraintes de l'autre, et surtout faire les pas nécessaires pour rendre les choses plus harmonieuses entre les parties.

3/ Sécurité 

Je pense que c'est un enjeu important, qui va permettre d'aller vers ces fameuses relations harmonieuses.

Si on fait un peu attention au temps consommé sur nos projets, vous verrez qu'un temps très important est dépensé dans des postures de défense, de protection.

C'est un cercle vicieux compliqué à combattre mais qui peut s'avérer très bénéfique sur le long terme pour toutes les parties.

Un exemple concret de temps consacré à la défense / protection est ce qu'on appelle par exemple la recette applicative. Ce que j'appelle la peur de passer en production.

On passe un temps important dans ce cycle, pour à la fin pouvoir dire, vous prenez la responsabilité (PV de recette) de passer en prod, donc vous ne pourrez pas nous reprocher par la suite des choses. 

Si on imaginait un cadre, où le droit à l'erreur existait, et était pleinement assumé, on ferait du test en continu, avec des petits morceaux. Si on met en prod, un erreur, on est alors capable de rectifier le tir en quelques heures (c'est petit, on vient juste de travailler dessus,...). On fait du cycle court au global, même dans la manière de travailler.

L'insécurité amène sa charge mentale du début à la fin. Insécurité dans le choix des sujets qui nous paraissent important, insécurité dans le cycle de préparation, insécurité dans les instances de décision, insécurité dans la spécification, insécurité dans le développement, dans le test, dans la mise en production, dans la gestion des retours, dans les comités de pilotage...

Du coup, pour palier à cette insécurité, nous créons tout un tas de processus (écriture d'expression de besoin, de spécification, de gestion budgétaire, de suivi, de contrôle, de partage) et avec une comitologie qui permet de garder les bonnes distances, et se justifier.

Injecter de la sécurité, et vous verrez que tout un tas de processus vont devenir obsolètes, et vous gagnerez en time to delivery, en qualité, et en valeur produite, avec le même budget initial.

C'est intéressant de voir que certains processus datent d'une époque, ou d'un contexte qui n'a plus forcément lieu aujourd'hui. Mais qu'il est très difficile de s'en affranchir. Ils ont servi un jour...

Le lien vers la vidéo

Transformation ou adaptation

Toujours sur le thème de la violence, je voulais faire un petit article sur un détail étymologique qui pourrait vous apporter du sens, et moins de violence.

Le mot transformation pour moi, a toujours eu pour moi une connotation un peu violente. Une sorte de changement "radical" qui pousse à renier ce qu'on a été pour embrasser un nouveau costume. Et qui pourrait dire, vous faisiez "mal", vous allez faire "bien".

A mon sens, le but nos transformations est de faire grandir, et de faire évoluer l'individu vers le collectif, en intégrant de nouveaux savoir être.

Adaptation intégrative

Je pense qu'en tant qu'agiliste, un terme plus serein me vient à l'esprit qui est adaptation. L'adaptation n'est pas un reniement de ce que nous sommes, mais plus l'utilisation de ce que nous avons été, pour se mouvoir dans un nouvel avenir. Il est dommage de jeter à la poubelle tant de savoir faire, et de savoir être, pour le plaisir d'un "agile-washing", grand nettoyage à sec au nom d'un idéal, d'une notion.

L'adaptation seule ne suffit pas, il faut également intégrer de nouveaux concepts, de nouvelles manières de voir les choses, c'est pour cela que je préfère parler d'adaptation intégrative. On va intégrer dans notre démarche un ensemble de savoirs supplémentaires, qui vont venir compléter notre manière de faire, ce qui pourra demander parfois des adaptations à nos habitudes.

Le Manifeste Agile par ailleurs appuie le fait qu'on ne renie pas tout d'un bloc, mais qu'on va aller dans une direction privilégiée, vers de nouvelles valeurs :

" Précisément, même si les éléments à droite ont de la valeur,  nous reconnaissons davantage de valeur dans les éléments à gauche.".

En tant qu'agiliste, je soutiens l'épanouissement des individus et des interactions entre eux, et en même temps, je ne renie pas la valeur que peuvent avoir un processus ou un outil, qui viendrait soutenir les individus et leurs interactions.

Dans une démarche, dite de transformation, le but ne serait pas de faire table rase, mais bien d'intégrer des nouveaux concepts à leur prédécesseur. Nous le voyons bien, il n'est pas possible de supprimer 20, ou 30 ans d'existence dans un autre mode, juste en le décrétant.

Ce n'est pas une coexistence à proprement parler, mais une adaptation, et une intégration de nouveaux concepts.

Intégration à la performance

Nombre de sociétés sont dans la recherche de performance. Dans le monde qui est le notre, il n'est pas imaginable de sortir de la recherche de performance. Par contre, les moyens de l'obtenir peuvent être adaptées.

J'ai l'impression que pour certains le mot performance est un mot à casser, car agilistes que nous sommes, nous avons à cœur de développer des valeurs autour de l'humain, et souvent le mot performance l'a été au détriment de l'humanité de l'entreprise.

La performance n'est pas quelque chose de "mauvais", ce sont plus les moyens utilisés pour y arriver qui ont pu être déshumanisant. Si vous voulez avoir une approche adaptative intégrative, il faudra composer avec les besoins de l'entreprise, et la recherche de la performance en est un un.

La mise à l'agilité amène à aller vers une nouvelle direction. On va rechercher plus de valeurs humaines, plus de sens du collectif, moins de chef, pour plus de "nous", où l'importance de la place de chacun est important pour chacun, plus que l'intérêt pour sa place individuelle.

Le point de départ de "nos transformations" est souvent une organisation très hierarchisée, construite dans un but de recherche de performance, de valorisation du mérite(travailler dur pour réussir et monter les échelons), et très centré sur l'individu et de sa performance individuelle.

Ma vision est qu'il est nécessaire d'apporter une réhumanisation de cette organisation, tout en tâchant de continuer à cibler une performance, mais qui sera valorisée collectivement, et sans oublier l'individu, qui doit trouver sa place, et son contentement.

Il ne faut pas créer une cassure, mais plutôt prolonger l'individu à son collectif, à ce qu'il apporte aux autres, à sa contribution au grand tout.

Nous allons donc essayer d'apporter plus de sérénité dans les relations, donner de la place à chacun dans le collectif, ce qui va apporter de la sécurité (ma place n'est plus menacée) et donc une propension à essayer, expérimenter et donc à innover et à sortir de :

"Faire plus de la même chose est une excellente stratégie pour réussir à échouer"

-- Paul Watzlawick

Et en même temps, on va utiliser notre expérience, pour s'objectiver, mesurer, se challenger, et garder cet objectif de performance.

L'enjeu sera de montrer qu'on peut continuer à performer, mais autrement. C'est un enjeu complexe car, bien souvent, coach que je suis, nous sommes complètement dans la mise en oeuvre du réhumaniser, de créer du sens du collectif, d'abolir de la hiérarchie, en rendant tabou l' "ancien monde". Si je veux être crédible, et intelligible par tous mes interlocuteurs, je dois savoir écouter ce besoin de performance, et l'intégrer dans ma démarche, et peut être passer du temps avec les "compteurs" (même si ma préférence va aux conteurs), pour voir avec eux ce qu'il y a à compter, et ce qui va être comptable à la fin, et j'espère que tout cela me mènera à vous conter d'autres histoires.

Douceur en transformation

Douceur dans les transformations

Petit constat de ma vie de coach agile. J'aimerai vous aider à prendre un peu de recul, dans vos activités de transformation, d'accompagnement d'équipes, afin de réintégrer de la douceur dans ce que vous faites.

Nous faisons un métier, où pour parti nous servons de véhicule d'un message qui ne nous appartient pas. La direction a choisi de mettre en route une transformation, et chacun doit se conformer à ce message.

L'entreprise recrute des coachs, et ceux ci s'approprient "la transformation", et bien souvent ils essayent de la modeler à leur image, leurs idéaux, leurs valeurs. Je dis ceux-ci, il est entendu que j'en fais partie.

Bien souvent, j'ai ressenti une grande désillusion quand mes idéaux n'ont pas rencontré ceux de l'entreprise. Mon envie de faire les choses bien, en grand, de garantir la sécurité et le bien être de mes équipes, de réussir à faire changer le mindset de toute la chaîne managériale, et tout cela, avec amour et tendresse.

Je me suis rendu compte, qu'il était difficile de faire mon métier, si je restais sur des idéaux trop éloignés des possibilités de l'entreprise où je venais apporter la "bonne parole". J'essaye aujourd'hui de traiter cela avec plus de douceur, et pour moi, et pour les autres, car au final, une transformation apporte une forme de violence, qui ne peut être ignoré. Et en tant que coach, je dois composer avec cette violence, pour la ramener à quelque chose de plus doux et serein.

Violence envers les managers

Les managers ont des objectifs chiffrés, des plannings de livraison à tenir, et bien souvent avec peu de moyens, car la transformation doit apporter les leviers de productivité. Ils n'ont bien entendu pas le droit non plus de dégrader la production, car la transformation apporte vélocité, et qualité, il n'y aucune raison de réduire la voilure. Nous sommes bien conscients, que tout changement nécessite  un temps d'intégration, d'apprentissage, et de maîtrise. Je trouve tout à fait normal que la production soit dégradée dans un premier temps, pour amener ensuite une forme de productivité, plus de motivation(bien être), le fait de ne produire que de la valeur, et de la qualité.

Les managers doivent porter bien souvent une transformation qu'ils n'ont pas choisi, sans moyen, ni support. On voit bien la violence dans  l'injonction "change" (devient agile) qui est en contraction avec "ne change rien" (la production doit continuer de la même manière, même niveau de service).

Violence envers les équipes

Pour les équipes, il y a de la violence également. De manière implicite, le message véhiculé ressemble fort à "on va vous apprendre à travailler maintenant". Pour autant, le message est souvent bien accueilli car il va avec de nombreuses promesses : "auto gestion", "autonomie", "droit à se gouverner", "plus de valorisation de la production".

Malheureusement, on s'aperçoit souvent qu'on n'aboutit que rarement à cette promesse, et on atteint souvent un plafond de verre. On demande aux équipes des résultats tangibles, hors de la même manière une non autorisation de réduire la productivité, et donc d'apprendre, de se former, de trouver son équilibre. Et on entend souvent ce reproche de manque d' "agilité" : souplesse, flexibilité, acrobatie.

On se retrouve dans la même violence d'injonction.

Violence envers les coachs

Pour les coachs, il y a aussi beaucoup de violence dans les transformations. On nous reproche assez rapidement une posture basse, posture d'émergence, qui dénote un manque d'implication dans le résultat. On aimerait d'ailleurs nous demander de participer à la production, eut égard à notre tarif journalier. Et nous sommes les premiers qui sont remis en cause, pas assez efficace, pas assez de résultats tangibles, mesurés à partir de Kpi quantitatif. Et on n'aura de cesse de comparer avec l'entreprise ou le département, qui elle/lui est agile.

Plusieurs injonctions jouent contre nous : injonction d'aller vite alors que le changement prend forcément du temps, coacher versus produire, faire pareil mais différemment...

Résilience

Au final, comme on peut le voir, une transformation contient sa part de violence, si on n'y prend garde.

Je prends aujourd'hui beaucoup de recul dans ces démarches de transformation. Je me rends compte du nombre d'injonctions, et du nombre d'injonctions contradictoires que tout le monde reçoit. J'essaye de ne pas y apporter les miennes, et au contraire, de mettre à jour les paradoxes pour apporter de la douceur aux équipes, et non pas une sorte de piège ingérable.

J'aime à travailler la résilience de chaque sous système, pour qu'elle puisse encaisser les changements, et pouvoir continuer à vivre et à évoluer. Je préconise pour améliorer cette résilience, de mettre en place des groupes de soutien par exemple, d'écoute et d'un cadre de sécurité psychologique, indispensable pour la capacité à changer.

Il est important que chaque sous système puisse trouver son rythme, sa respiration (pouvoir respirer littéralement). Il est fort possible que la transformation soit asynchrone, et que chaque partie évolue à son rythme. Il est normal de devoir s'arrêter d'apprendre, pour prendre le temps de l'assimilation et de l'intégration, et du repos pour pouvoir réamorcer la machine pour gravir la prochaine marche. Le système a besoin d'énergie pour fonctionner, il ne faut pas hésiter à trouver les moyens de re énergiser par différents moyens (pause, donner du sens, célébrations, maturité d'équipe, intégration,...)

Je ne suis pas un bisounours, mais je me préoccupe du long terme, et non des succès court termistes( sans déconsidérer la démarche des petits pas). C'est une grande chose de changer, il faut beaucoup de douceur, de délicatesse, et de considération, pour éviter qu'une grande vague vienne se fracasser sur ces personnes avec qui nous travaillons et nous emporter dans le même temps.

"Un commencement est un moment d’une délicatesse extrême."

 -- Princesse Irulan

Amour et agilité

Aimer son métier et son prochain
L'humain et le manifeste agile

Il y a beaucoup d'effet et de buts différents dans la mise en oeuvre d'une approche agile auprès de nos équipes.

Ce que j'ai remarqué est que l'un des effets le plus visible concerne le bien être des gens avec qui vous travaillez.

C'est pour cela que j'aimerai parler d'un acte d'Amour quand vous venez encadrer une équipe dans sa mise en oeuvre d'une transformation vers plus d'agilité.

Le Manifeste agile, ainsi que l'apparition du "Modern Agile" sont pour moi des déclarations très orientées vers le bon sens, vers l'humain et l'amour de son prochain.

Pour citer les éléments qui me poussent à travailler autour de l'humain :

• Individus et interactions : On va effectivement privilégier les relations humaines et les personnes
• Collaboration : Faire travailler honnêtement les gens ensembles, dans un but commun, avec un sens d'équipe
• Les utilisateurs et les développeurs doivent travailler ensemble : stopper les silos, les passe plats, et renforcer la collaboration, le travail ensemble
• [...]Personnes motivées,  [...] faites leur confiance  : Apporter du bien être dans l'équipe
• Transmission de l'information en face à face : réapporter du liant, entre les personnes
• Rythme de développement soutenable : Respect des personnes, veiller à leur bien être, faire confiance
• l'équipe réfléchit aux moyens de devenir plus efficace : Respect des personnes, faire confiance, autonomisation
• [Modern Agile] : Make People Awesome : Croire aux gens, dans l'équipe, mais aussi nos "clients", nos partenaires...
• [Modern Agile] : Make Safety a Prerequisite : Respect des personnes, créer un environnement bienveillant, sûr. 

Je pense que lorsqu'on comprend qu'il faut avant tout se concentrer sur l'humain, les choses deviennent plus aisées, en tous les cas plus claires.

J'ai en tête l'apaisement des relations entre les équipes que nous essayons d'accompagner et le système qui l'entoure, qui ne perçoit pas toujours cette transformation, et qui continuer à vouloir imposer son mode de fonctionnement.

Les injonctions et les équipes

Les équipes que je rencontre sont souvent dans une forme de "souffrance". Des injonctions venant de différents niveaux, les conduisent à se mettre dans des positions d'inconforts importants. Il faut traiter ce qui est indiqué comme urgent par les différentes autorités, en ne traitant pas toujours l'important. En outre, ces différentes injonctions peuvent générer une surcharge et de quantité de travail, et parfois de posture

Le cadre porté par l'agile doit permettre de soulager les équipes. Je viens avec une envie d'apporter mon amour à ces personnes, pour qu'elles aillent mieux. Leur redonner confiance en elle même, leur redonner une forme de contrôle dans leur vie professionnelle.
L'autonomisation, l'auto organisation sont des leviers puissants dans cette reprise de confiance, et dans la reprise du contrôle.
Il s'agit alors de construire une compréhension de ce que doit être la confiance, la sécurité psychologique, la bienveillance...

Le système

Ce qui entoure les équipes sont souvent des forces contraignantes, qui demandent aux équipes un certain nombre de livrables, de respect de jalon, de respect de forme, de reporting, de soumission à une organisation, de contrôle explicite et implicite.

Il est important d'accompagner ce qui entoure les équipes dans un changement de comportement également.
On ne peut pas demander à des équipes de devenir "meilleure", autonome, dans un esprit collectif, ... et qu'à chaque fois qu'ils font un pas dans cette voie se prennent en effet boomerang, des règles, des injonctions, des égos.

Il est important de notifier au monde extérieur le travail en cours, sur ces changements de comportement par l'équipe, et lui (monde extérieur) montrer que sa manière de faire ou de demander n'est pas approprié avec les nouvelles manières de faire.
Il est important que les gens qui entourent les équipes comprennent en quoi les anciennes habitudes ne sont plus appropriées, et comment les changer pour les adapter.

C'est un sujet qui concerne le respect des personnes, et la bienveillance envers elles.
Il ne s'agit pas d'être dans une confrontation, mais apprendre à s'écouter, et parfois à s'écouter soi même. Quels sont mes besoins, qu'est ce qui est réellement important au delà de ce qui paraît important?
Le fait de partager ses besoins, ses préoccupations, ses enjeux permet de créer quelque chose dans les relations de plus sain, d'apaisé.

Ce n'est pas si compliqué ou si dur. Je remarque que bien souvent, les personnes ont surtout besoin d'être écoutées, comprises, de recevoir des marques d'affection.
Une fois qu'elle voit qu'elles sont considérées, un certain nombre de choses se dénouent, et chacun accepte de se prêter à cette nouvelle humanité et de faire un pas vers l'autre.

Conclusion

Cet article a pour simple vocation de tracer une réflexion que je me faisais, et de faire un état des choses qui me paraissent importantes dans mon métier.

Il y a une certaine facilité à apporter de nouvelles pratiques, ou de nouvelles manières de voir les choses auprès d'un groupe restreint qui se sent exalté par cette nouveauté et ce désir de liberté...
Jusqu'à ce que le système revienne en effet boomerang (Loi de Conway)... et fasse exploser cette motivation, cette envie de changement, face à des murs paraissant inébranlables.

Pour autant, nous n'avons pas toujours la possibilité de changer l'ensemble du système, au vu de l'immensité de la montagne, et le peu d'équipement qui nous est donné pour démarrer l'escalade.

Malgré tout, il est possible par la compréhension des enjeux de chacun, mais aussi en remettant l'humain au centre, plutôt que le processus, de rétablir une forme de bien être dans les relations, et dans l'importance qu'on donne au système.

Je reste persuader qu'en faisant que les hommes et les femmes se sentent respectés, écoutés, et aimés, beaucoup de barrière tombent, et on est capable de franchir de nouvelles étapes dans un élan d'amour.
On oublie un peu l'importance du process, et on s'intéresse à ce qui apporte de la valeur pour chacun,  à sa place, à ses envies, à sa motivation, à son désir d'appartenir au groupe.

En donnant de l'amour, on reçoit cet amour : Etre aimé et aimer en retour.

A chacun sa place

A chacun sa place

Transformation agile, transformation digitale, transformez vous... !
Mais en quoi?

De ma petite fenêtre, je vois nombre d'entreprise vouloir adopter de nouveaux modes de travail, pour répondre à la sempiternelle question de comment faire mieux?


L'agile est agitée comme une baguette magique pour résoudre tous les maux. Mais pourquoi?
Je pense que tout à chacun cherche à découvrir quelque chose de différent, car beaucoup de changements ont été apportés depuis des années qui ont visés à réduire les coûts :

• optimisation des infrastructures
• optimisation de personnel
• optimisation des moyens de fonctionnement
• réduction, réduction, réduction....

On arrive à un moment, où tout ce qui pouvait être réduit l'a été, et on se retrouve avec des gens qui sont globalement en souffrance, devant tenir plusieurs casquettes, et souffrant du manque de moyen.
On se retrouve avec des collaborateurs surmenés, surchargés, avec une motivation qui tient à peu de choses, le stress et le mal être devenant une dominante en entreprise.

D'autre part, les entreprises ont été segmentés en business unit, avec ses propres indicateurs de performance, et ce qui a mené un certain nombre de managers à chercher les optimisations locales, lui permettant de trouver grâce devant le sacro saint indicateur, et cela parfois au détriment du bien commun, et de la globalité de son entreprise.
Le but venant d'être le meilleur d'entre eux, se réduit souvent à être moins mauvais que le voisin.

Les entreprises sont donc en recherche de leviers de changement, notamment car les projets sont de plus en plus complexes, les attentes utilisateurs sont de plus en plus importantes, et que leur capacité à livrer un service est un sujet de discussion.
Le drapeau de l'agile est levé, et ordre est donné, que les projets passent en agile, pour améliorer qualité, rentabilité, productivité, et time to market.

L'agile a au moins pour paradigme de maîtriser le budget. Mais, et c'est un grand mais, un grand nombre de projets agiles restent dans les clous de ce qu'est l'entreprise dans laquelle elle se trouve.

Autant les opérationnels, ce qui travaillent au sein des projets, appréhendent plus ou moins rapidement, et selon la qualité de leur formation, et de leur accompagnement, la nouvelle manière de travailler, qui se tourne avant tout sur le collaboratif, et le fait d'être au service d'autrui, autant les couches supérieures ont du mal à faire la bascule.

Cette bascule ne s'opérant pas, les habitudes de micro management, et de pressurisation reviennent vite à la surface.

Une place pour qui ?

Etre agile signifie beaucoup de choses, et j'essaye encore aujourd'hui à en capter l'essence.

Dans cet article, ce que j'aimerai en retenir est l'aspect collaboratif, se mettre au service d'autrui et la valeur produite. (D'autres vertues apparaissent dans d'autres articles, comme la gestion du risque par la compréhension du changement, la qualité, l'aspect humain, la compréhension des enjeux, ...).

J'ai intitulé cet article "à chacun sa place", car je pense qu'aujourd'hui, on adresse dans les projets agiles, uniquement l'équipe de production, l'équipe qui développe (dans le sens littéral) un produit.
Mais cette équipe fait partie d'un tout plus grand, un écosystème délicat, qui doit lui même évolué, pour supporter ces nouvelles manières de travailler.

Le sujet du sponsoring est un sujet important en agile, mais aussi dans tout autre mode projet. Un manager qui vous soutient et vous supporte, est un facteur de réussite important.
Mais faut il encore qu'il comprenne ce que vous faites et comment vous le faites, et surtout qu'une place lui soit trouvé.

A ce jour, il existe de plus en plus de littérature sur la place du manager dans l'entreprise, position qui doit muter. Les initiatives tel que Management 3.0 sont très heureuses et aident les gens à appréhender ce qu'est le management nouvelle génération.
Mais cela reste à mon sens très théorique, et compliqué à mettre en oeuvre, quand il n'y a pas un accompagnement de mise en oeuvre réel, en groupe.

L'acculturation et la formation restent des étapes excessivement importantes, car la compréhension des nouvelles manières de penser reste indispensable pour appliquer correctement ces paradigmes.

Mais qui prend ma place?

Effectivement, les courants de pensée pendant un certain temps, ont laissé penser qu'on allait se passer des managers, et que les équipes autonomes, auto dirigées étaient auto suffisantes.
Le spectre de l'entreprise libérée menaçait de son ombre, et paraissait devenir l'entreprise à la guillotine, où le manager était passé au fil du couperet.

Il y a mécompréhension sur ce que l'agile souhaite du manager.

Le framework SAFE puisqu'il adresse des programmes, embarque dans son framework également les leaders, et les coordinateurs. En couplant, Lean IT, SCRUM, Kanban, et manifeste agile, donne une image du rôle du manager dans un programme agile.

Et je trouve cela très encourageant que des gens aient réfléchi sur comment intégrer les couches hautes dans nos méthodologies projet.

Pour ma part, je pense qu'il y a un changement qui doit s'opérer. Ce n'est pas un renversement du pouvoir en place, mais une amélioration de leur fonction.
Cette fonction managériale a longtemps eu pour but de micro manager des hommes, de contrôler, et de pousser aux limites les équipes.

Je vais dire des choses que vous saurez relire ailleurs, mais le manager doit lui même créer de la valeur, s'occupant de tâches à valeur ajoutée.
Un des paradigmes de l'agilité est que l'équipe de développement devienne auto suffisante (autonomie et organisation), et performante (but à atteindre).
J'attends des managers qu'ils deviennent des "outils" au service des équipes permettant à atteindre ces buts.

Un manager :

• doit être capable de prendre les décisions, car l'équipe doit savoir dans quelle direction aller.
• doit motiver l'équipe pour qu'elle reste à son plus niveau de performance
• doit aider l'équipe à surmonter les obstacles, car elle n'a pas la main sur tout le système
• doit "coacher" l'équipe pour la faire monter en compétence, afin qu'elle devienne auto suffisante.

Un très bon outil, pour aider le management à trouver sa place, et à définir comment il doit interagir avec ses équipes est le poker délégation.
Le poker délégation contient 7 niveaux de managements différents, du plus directif, au plus "libéré", en pensant par les intermédiaires comprenant la délégation.

Pour chaque activité, chaque relation qu'il a avec ses équipes, il peut via un tableau à 7 colonnes (les 7 niveaux de management), définir où cette activité se positionne.

En toute transparence, il affiche s'il garde le contrôle sur une activité, ou au contraire, s'il laisse la responsabilité à l'équipe, ...
L'équipe peut/doit challenger les niveaux de management, en indiquant sa motivation à monter en responsabilité sur les différentes activités qui l'intéressent, ou au contraire, en souhaitant que le manager garde un rôle de "capitaine à bord" pour certaines activités.

La transparence, par la définition des rôles et responsabilités, est un facteur extrêmement facilitant pour chacun, et rassurant pour les différentes parties.
Le manager sait lui même ce qu'on attend de lui, et comment travailler avec l'équipe.

Conclusion

Le message que j'aimerai faire passer est que le manager conserve sa place dans l'entreprise.

Je pense qu'il faut juste redéfinir ce qu'on attend de lui, et qu'il ne se place plus comme le "chef" qui doit montrer, et justifier son poste, mais qu'il doit apprendre quelle est sa place, et réussir à rester en mouvement face aux besoins de ses équipes.

L'équipe s'adapte au contexte de son entreprise, et du marché. Le manager s'adapte aux besoins de son entreprise, et de son équipe.

Le manager doit servir l'équipe au mieux, en définissant correctement ce dont l'équipe a besoin.
Parmi ses besoins, la posture de manager sera toujours présent. On a besoin de décideur, de visionnaire, d'organisateur, de personnes donnant le cadre.
Une équipe ne peut devenir autonome qu'au sein d'un cadre correctement défini.


Par contre, adieu le manager qui impose, sans parler à ses équipes, et qui micromanage. Sa valeur est tout autre, et nous la reconnaissons.

Pascal Ogil

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

Le management visuel n'est pas une fin en soi

Le management visuel n'est pas une fin en soi

J'aimerai faire un aparté sur le management visuel. Il est souvent d'usage lors d'une transformation agile de mettre en oeuvre un management visuel rapidement voire en premier lieu.
Le bénéfice de cette mise en oeuvre est qu'on concrétise matériellement un élément préconisé par l'agilité.
Dans les esprits, le changement est amorcé, on teste un nouvel élément, et on l'utilise.


Il est vrai que mettre en oeuvre un esprit agile sur un projet demande un effort mental qui n'est pas complètement anodin.
La recherche de la valeur métier, la transparence, la qualité, l'inspection sont des concepts, et le management visuel a la vertu de pouvoir concrétiser un certain nombre de ces concepts.
On affichera un avancement à la vue de tous, concernant la transparence, on affichera le rapport qualimétrie/Tu pour la qualité, la dernière rétrospective pour l'inspection....

Malheureusement, le management visuel est souvent perçu comme un aboutissement. Un management visuel élaboré, avec la plénitude des concepts décrits dans les livres, est un souvent un point de satisfaction très important.
On aura mis en place un bac à rouge, un parking, afficher des éléments de planification, des tâches, ....

Est ce qu'ils sont bien utilisés? Est ce que le management visuel est un élément renforçant l'esprit agile de l'équipe? Est ce que l'équipe acquiert une plus grande autonomie grâce à celui ci?
Est ce que d'ailleurs, l'équipe est partie prenante de sa mise en place, ou le subit elle?

Fin et Fond

J'ai été longtemps dans le courant de mettre en oeuvre un management visuel pour démarrer une transformation.
Je me rends compte aujourd'hui, que ce n'est pas une "norme" à appliquer.

Il est important en premier lieu, d'être certain que l'équipe a bien "subi" une acculturation aux principes agiles.
Il y a un état d'esprit à acquérir, et la plupart des formations (type Scrum) sont le plus souvent données en inculquant la forme de la méthode : Les réunions à tenir, leurs temps, leurs fonctions.
Mais bien souvent, l'acquisition du fond n'est pas abordée. Il y a une transformation d'attitude, de perception à faire qui est fondamental.

La forme de SCRUM est un cadre idéal donnant un résultat idéalisé. Les gens ont besoin de cadre, cela leur donne un ensemble de règles à respecter, et une définition des rôles et des responsabilités.
Cela aide la plupart des équipes, et surtout cela aide les clients à respecter les besoins des équipes (en terme d'entrant, d'autonomie, de capacité à estimer, et fondamentalement, d'avoir des points d'échanges prédéfinis).

L'un des points du manifeste agile, malgré tout, indique que nous favoriserons les échanges et les rapports humains par rapport à la mise en oeuvre des processus et des outils.
Garder bien à l'esprit cela... Le cadre facilite la mise en oeuvre, mais la réelle mise en oeuvre, concerne l'humain, et son changement de comportement, pour arriver à un comportement agile.

Je me rend compte que bien des managements visuels sont élaborés en premier lieu par des chefs de projet, qui reproduisent physiquement, un outil de suivi qu'ils ont.
Finalement, on n'aide pas l'équipe à devenir autonome, on leur donne un moyen **Exagération** de s'auto flageller devant le chef de projet.
Mais je m'égare...

En tous les cas, si vous commencez par poser cette brique, il faut bien garder en tête, que ce premier jet est souvent un mauvais jet, mais qui peut être un premier lieu de sensibilisation.

Chaque matin, n'hésitez pas à poser la question sur l'efficience du management visuel : est ce qu'il manque une information, est ce que la structure suit finalement le rythme de l'équipe...

• N'hésitez pas à demander dans les répartitions de tâches, si la valeur métier prime dans tous les choix, et sinon, en discuter la raison.
• Vérifier que le niveau de partage de l'équipe est suffisant pour que si l'un des membres s'absente, qu'il n'y ait pas de problème.
• Vérifier que l'information affichée permette l'inspection à l'équipe : Où en sommes nous? Quelles sont les priorités? Quel niveau de qualité? Comment prévoit on de s'organiser?

Conclusion

A mon sens, le management visuel est un outil, plutôt efficace dans la majeure partie des projets. Mais la maxime est bien que nous favoriserons les échanges et les rapports humains, plutôt que les process et les outils.
Ne vous focalisez pas sur votre management visuel, mais bien sur la dynamique de votre équipe, sa prise d'autonomie, sa responsabilisation, sa capacité à prendre en charge tous les éléments du projet...
Le management visuel peut devenir un catalyseur en démarrage de projet, mais sera finalement tel un miroir réfléchissant l'âme de votre équipe.

Pascal Ogil

Entreprise Agile

Entreprise Agile

Ces dernières années, un certain nombre d'entreprise voit échouer leur politique de développement logiciel, et en conséquence admire les modèles "émergeant" qui mettent en pratique l'agilité.
Après des années à vouloir se débarrasser de l'informatique, car trop coûteux, demandant trop de compétences changeantes, des plans de formation coûteux, les sociétés ont adoptés pour la plupart le mode forfait qui consiste à se débarrasser du projet et après un long effet tunnel découvrir un produit ne correspondant pas à leur attente.
Le coût d'achat du projet a bien été réduit, par contre le coût global, sans parler des dérives calendaires, ne sont rarement remontés dans les statistiques.
La honte de l'échec.

Les sociétés, face au mécontement de leur métier, face aux challenges de la concurrence, essayent de revenir à un mode plus collaboratif, et reprendre la main sur leur projet.
Mais après 20 ans, les personnes ont oublié comment travailler, et on retrouve sur les projets, une grande lacune dans la rigueur des spécifications, des tests, des recettes, des cas d'usages.
Les sociétés de service quant à elle, ont prospéré en vendant des profils qui ont comblé cette perte de compétence, le signe AMOA (assistance à maitrise d'ouvrage) est là pour en témoigner.

Les directeurs informatiques enjoignent leur équipe à travailler en agile pour améliorer la réussite de leur projet.
Mais en pratiquant une politique de l'autruche, et en occultant le constat que je fais ci dessus, qui restent des généralités, et sont bien en dessous des problèmes rencontrées par l'entreprise.

L'agilité n'est pas une baguette magique.

La recommandation que je ferai est de lancer un audit processus et méthode dans votre entreprise pour déterminer quelles sont les réelles problématiques que votre entreprise rencontre dans la livraison de ses services.
Peut être que l'agilité peut être une réponse en effet.

On parle beaucoup de transformation digitale. Il faut aussi parler de transformation agile. C'est une conduite de changement à mener.
Vos prestataires sont tous prêts à délivrer plus ou moins bien (convenons en), votre projet en agile (SCRUM par exemple). Par contre, vous, êtes vous prêts à en subir le cadre?

A mon sens, il y a plusieurs transformations à opérer, qui sont à des strates différentes, et qui sont des populations plus ou moins résistantes.
La strate la plus simple à convertir est la strate la plus opérationnelle.

1ere strate : le métier

A votre métier, si vous lui dites, qu'ils auront des demos régulièrement, une pleine visibilité sur ce qui est produit et quand, et qu'en plus ils pourront être impliqués dans le lotissement des fonctionnalités, j'ai peine à croire qu'ils résisteront à cet appel agile.
Je ne dis pas que c'est simple. Ils auront besoin de cadre, de comprendre la structure, d'être rigoureux.
La transparence affichée en terme de vélocité, est aussi une contrainte, qu'ils doivent assimiler. Le timebox comporte une productivité max, et ils doivent être en mesure de prioriser leur backlog, et ne pourront pas pousser des choses en plus au delà de la capacité.
La backlog doit rester fourni, et doit être prête dans le cadre temps fourni. Ils épuisent la capacité de prod de l'équipe, si les éléments ne sont pas prêts, ou s'ils arrivent au fil de l'eau.
Ils doivent fournir des cas d'usage, et doivent participer aux tests dans la structure temps imposé.
C'est un contrat bi partite. L'équipe produit au mieux, s'adapte sans cesse, pour donner satisfaction, et se concentre sur la valeur métier, mais le cadre de fourniture des besoins doit être respecté.

2e strate, les équipes transverses, et les équipes en adhérence.

L'une des difficultés des équipes est de réussir à se synchroniser avec les autres équipes (exploitation, intégration, architecture, .... ou projet en adhérence).
Ces équipes sont souvent pilotés par des jalons, des délais, et l'incertitude ne fait pas partie de leur quotidien.
Bien souvent, le rythme des équipes agiles est souvent un rythme soutenu, avec des livraisons fréquentes. Les équipes transverses ont souvent du mal à suvire le rythme et à s'adapter.
Les outils, les hommes ne sont pas préparés aux changements.
C'est un verrou difficile à déverouiller la plupart du temps, car ils ont souvent un poids important dans l'organisation, et demandent aux autres de s'adapter et pas l'inverse.
Il est possible de conduire un changement dans ces équipes également, en proposant une mise en place de Kanban IT, par exemple, et de mettre en place un diagramme cumulé de flux.
Ce diagramme permet de montrer quels sont les goulots d'étranglement en terme de traitement du livrable, et de pouvoir déclencher des actions de fluidification.

3e strate le pilotage & les managers

Pendant 20 ans, la bataille s'est mené sur l'interprétation de la bible cahier des charges, et de son implémentation complète, et sans réserve.
Aujourd'hui, en agile, le projet se mène en coresponsabilité, et arriver en bout de projet avec la spécification initiale n'est plus un but en soi.
Le management par la terreur n'est plus adapté, il faut changer le mode de travail, et surtout le reporting induit par ce nouveau mode de travail.
Quels sont les bénéfices d'un projet agile? Est ce que cela n'est pas cela qu'il faut mesurer au final?
Je serai très vigileant sur la définition des KPIs à mettre en oeuvre. Ma première recommandation est que le projet étant en coresponsabilité, les KPIs doivent pouvoir adresser tous les acteurs du projet.
On challenge le prestataire, mais on challenge aussi les équipes en interne.
Les kpis les plus souvent demandés, sont autour de la qualité et de la vélocité.
Ce sont des kpis issus de l'ancien mode de fonctionnement.

Je ne parlerai pas réellement de vélocité, mais je suivrai plutôt un indicateur lié à la prédictabilité de l'équipe. On pointe du doigt une notion qui me paraît plus essentiel, que la vitesse pure de l'équipe.
J'aimerai voir la capacité d'agilité du client : est il à niveau dans ce qu'on attend d'un backlog (définition des US de qualité, à temps, priorisé). J'aime aussi ajouter une notion, qui permet de déterminer la vie du backlog.
Finalement, un backlog figé (en quantité et en priorité) représente aussi un échec de l'agilité, ou une application abusive de la méthode, alors qu'un waterfall suffirait.
J'aimerai voir la satisfaction client (métier). Est ce que ce qui a été demandé a été développé? Est ce que l'expérience utilisateur est à niveau? Est ce que le sprint apporte un niveau de valeur métier suffisant?
Il est envisageable d'avoir une notation permettant de valoriser, au delà de nos attentes.
La qualité doit être envisagé sur plusieurs niveaux : qualimétrie, couverture de TU, régressions, bug utilisateur, non respect de l'US.

Les managers des chefs de projet doivent donc se fier à de nouveaux indicateurs, et la consommation de budget doit être surveillée, mais doit relever d'une surveillance ratio budget/valeur apportée.
Il ne doit pas être envisagé seule, ou sur la création de telle ou telle fonctionnalité. Il faut avoir en tête investissement et retour sur investissement.

On ne peut pas imaginer de demander à des équipes de changer de manière de travailler, si les "surveillants" ne changent eux même pas d'habitude, et d'attitude.
Il est illusoire de penser d'effectuer un changement de culture aussi profond, en ne demandant qu'à la "strate" opérationnelle de modifier sa manière de travailler.