Croire prendre soin de l'autre et faire une demande

J'ai voulu écrire un article pour apprendre à différencier "croire prendre soin de l'autre", et "être à l'écoute de l'autre", et prendre soin des besoins de l'autre.

Souvent, on fait attention à l'autre en pensant à sa place, ce qui serait le mieux pour l'autre.

Finalement, c'est un jeu de pouvoir / domination, basé sur le mental.

On lui impose un choix qui n'est pas le sien, sous prétexte de c'est pour ton bien.

Un exemple

Voici un exemple fictif d'une discussion de deux amoureux.

Discussion par téléphone jusque minuit.

Anna est fatiguée, mais n'ose pas le dire, de peur de décevoir Pierre.

Anna sait que Pierre est lui même fatigué car dans le fil de sa discussion il a pu lui dire.

Anna dit donc : "Allez Pierre, va dormir, tu es fatigué, et demain tu dois te lever".

Anna pense je prends soin de Pierre, et je le "libère" de son obligation de continuer à veiller pour me parler, et je le materne en lui montrant que cela serait mieux pour lui qu'il se couche pour se reposer.

La réaction de Pierre la prend à contre-pied. Il a le sentiment d'être poussé hors de ce moment agréable, qu'il apprécie tant. Une fin de non recevoir auquel il ne s'attends pas. Il est triste par cette "rupture".

Il a également un sentiment de colère, car il se sent quelque peu materné, et il ne souhaite pas considérer sa partenaire comme une mère, et il n'a pas besoin qu'on lui dise à quelle heure il doit se coucher pour être en forme... et quand bien même, s'il est fatigué c'est son choix personnel. Il est assez grand et adulte pour savoir s'il a envie ou non.

Emettre une demande

Une bonne démarche pourrait être plutôt de parler de soi, et de ses propres besoins, et/ou de ses émotions.

Réimaginons le dialogue vers quelque chose de plus positif.

Anna est fatiguée. Anna dit à Pierre : "Je me sens fatigué, c'est ok si on termine notre discussion, j'aimerai aller dormir".

Pierre pourra dire alors : "Tu es fatiguée? Oui bien sûr, je comprends, prends soin de toi, et va dormir. Je vais faire de même de toute façon, ou je vais prendre encore un peu de temps pour lire avant d'aller dormir.".

ou bien Pierre pourra dire : "Tu es fatiguée? je comprends. Mais j'aimerai te dire quelque chose avant de te quitter. Est ce que tu serais d'accord pour me donner encore 15 min de ton temps?".

Il est important de se rappeler la différence entre demande et exigence. Quand vous faites une demande, vous êtes prêts à entendre un refus de la part de l'autre, ou une négociation.

Dans ce cas, Anna demande pour aller dormir et clore la discussion. Pierre peut accepter, ou comme dans le deuxième cas négocier encore un peu de temps à discuter. Dans ce même cas, Pierre fait lui même une demande car il a un besoin de connexion, ou de partage. De la même manière, il doit être prêt à envisager que Anna refuse, car elle est trop fatiguée.

En tous les cas, les deux protagonistes ont cessé de faire des hypothèses l'un envers l'autre (confère 3e accord de tolthèque également), et se sont recentrés sur leur besoin propre.

Cela amène une meilleure compréhension de ce que l'autre veut, de la clarté dans la relation, et surtout pas de sentiment négatif (culpabilité, colère, tristesse).

Chacun a fait du mieux qu'il a pu, sans jouer contre l'autre.

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.

Le manque de sens (humour)

Le sens de la vie, avec humour

Récemment, suite à un échange sur une iconographie sur le sens de la vie, j'ai eu la chance d'avoir un échange très intéressant sur le sujet : le sens de la vie.

J'ai pris le parti de défendre le point de vue que la vie n'avait pas de sens.
Que c'était juste une suite de choses qui se succédaient de manière temporelle, et non causale.
Le monde est chaotique, les choses qui t'entourent aussi. Il y a sûrement une capacité à s'en démêler un peu avec des efforts, en tentant une analyse de notre environnement, des gens que nous côtoyons, et en faisant profil bas, pour ne rien provoquer.

Malgré tout, des choses arrivent, que nous ne contrôlons pas, ne maîtrisons pas, et que nous ne pouvons pas prévoir.

Certains essayent de donner du sens à tout cela, peut être un aspect religieux, un aspect défaitiste, un aspect optimiste (pour mieux rebondir).
Je prends le parti dans cet article, qu'il n'y a pas de sens à chercher, et que même, chercher à y mettre du sens peut être un élément de perte de confiance en soi, car on se retrouve à chercher des causes extérieures, et en oublier sa propre puissance au détriment d'une forme de fatalité.

Mais sans sens, la vie n'est elle pas plus simple? A quoi bon, essayer de construire une vie sur le long terme, en espérant "réussir", à atteindre des buts. De toute manière, à un moment donné, quelque chose va déraper, et va saper tout le travail que tu as fait. Non par malveillance (pas de sens), mais parce que cela arrive.

C'est un moyen d'embrasser les vertus de l'agilité à 100%.
Plutôt que de se projeter dans un avenir incertain, qui ne sera absolument pas celui auquel tu aurais pensé.

A la place, il faut faire des itérations courtes, pour atteindre des paliers de plaisir régulièrement. Une fois chaque palier atteint, se remettre en question, et reprioriser ce qui est important pour soi en ce moment.

Tu construis ta vie (produit) à ta vraie mesure, à l'aune de ce qui se passe pour toi en ce moment, de tes convictions, de tes envies. Et non sur la base d'une projection que tu aurais faite il y a 10 ans, avec tes convictions d'antan et tes envies d'antan.
Ce que tu pensais avoir envie, est sûrement très différent de ce que tu aimes aujourd'hui, réellement.

De fait, ne pas prêter de sens à la vie, n'est pas un signe de défaitisme, ou de pessimisme, mais c'est plutôt une aspiration à croire que la vie est faite de petites choses qui viennent te perturber et te donner des nouvelles opportunités.

On se retrouve alors dans une forme d'insoumission, vis à vis des codes sociaux... Il n'y a pas de il faut, pour être heureux, avoir fait ceci ou cela dans ta vie, voire pire de ta vie.

Je conclus mon échange, par un "mais tu dois me croire fou", conclusion à laquelle on m'a répondu "peut il il y avoir de la folie dans un monde sans sens?", à laquelle je répondis, "la folie est un jugement donné par des gens sensés de toute façon".

Avec cadre OU sans cadre

Avec cadre OU sans cadre

Votre agilité dans un grand verre avec ou sans framework? 

Qui est assez fou / sage pour se lancer dans une agilisation sans framework? Scrum, Kanban, SAFe, ... Des mots souvent employés à la place d'agile. Et pour cause, il n'y a pas toujours d'agile, alors que le framework est en place.

Le débat du framework est assez intéressant. Ce que je constate c'est qu'un framework, c'est quelque chose de tangible, d'accessible, de rassurant. On peut s'y référer, avoir des points de repères, du vocabulaire à partager, et aussi une forme de vérité sur laquelle s'appuyer -- d'aucuns l’appelleront la bible ou "the book".

Cadre et Agilité

Concernant les cadres, voici mes opinions, et mes observations. On trouve de plus en plus d'experts du cadre, avec des beaux certificats. Je ne mésestime pas ces personnes, car il faut souvent un travail conséquent pour l'obtenir (hors ceux qui se passent les grilles de question / réponses). Pour un certain nombre d'entre eux, ils deviennent des qualiticiens du cadre, et connaissent les nomenclatures par cœur, et sont capable de vous sortir tous les templates dont vous avez besoin, et d'être des personnes très motivées sur le déploiement de la forme.

Le jeu sera alors pour nous, de leur ouvrir les yeux, sur le fait que le cadre n'est qu'un support à l'agilité. Comme pour une belle peinture, le cadre met en en valeur, l'agilité qu'il contient.
Il faut imaginer que le framework que vous allez utiliser permettra de sublimer l'agilité que vous mettez en place.

Pour ma part, j'ai passé un certain temps à promouvoir des cadres, et cela m'a permis de me faire mon expérience, et d'apprendre énormément avec du recul, sur le fait qu'il faille s'adapter, et que le cadre ne s'adapte pas toujours bien. Il faut travailler du coup, sur la toile, et apporter par touches de l'agilité.
En travaillant avec les personnes, en les reliant (créer du lien) entre elles, on obtient de meilleurs effets qu'en essayant d'imposer un rituel.

Je suis devenu très attaché à la première valeur du manifeste agile : Améliorer la qualité des relations entre les individus, plus que de consacrer de l'énergie à mettre en place des processus et des outils. The modern Agile pousse d'ailleurs cette valeur vers "Make People Awesome".
Croyez en les personnes avec qui vous travaillez, et investissez votre énergie à les faire grandir, à leur apprendre, à les rendre meilleures.

Dans les métiers de l'informatique, de l'ingénierie, de l'étude, finalement, 90% de notre activité est liée aux personnes qui nous entourent, et avec une portée plutôt intellectuelle, que simplement mécanique. Ce qui est mécanique est de l'ordre du reproductible et surtout du prédictible.
Je n'ai jamais vu deux projets informatiques se passer "correctement" et surtout de la même manière. Mettez deux équipes de développeurs à faire le même produit, vous aurez deux résultats différents et surtout un chemin différent, autant sur la manière de faire que sur les difficultés rencontrées.

L'agilité n'est pas affaire de cadre, mais le cadre peut servir à l'agilité

J'ai vu bien souvent les gens se précipiter à mettre en place des daily, du management visuel, et d'autres réunions agiles.
Mettre en place le cadre. Dans l'absolu, cela donne des résultats, et c'est tant mieux. Mais est ce qu'on peut parler d'agilité?
Ma réponse, sera pas toujours... Et bien moins qu'on le penserait.

Une des choses intéressantes sur la mise en oeuvre du cadre, est que cela "force" un changement.
Les équipes se mettent en mouvement, changent leurs habitudes.
Cela peut aussi les amener à réfléchir et à remettre en question leur référentiel.... mais pas toujours.

La mise en oeuvre d'un cadre peut vous permettre d'apporter une impulsion, un changement, une rigueur aussi,  des nouvelles règles de vie en communauté et des points de repères. On ne peut pas dénigrer tout cela.

Mais faut il arc-bouter pour autant sur la tenue du cadre, et le rigidifier à  outrance, because of the book?
Absolument pas.

Comme toute transformation, l'important est le sens qu'on y donne.
Chaque entreprise commençant à son point de départ, et potentiellement sans changement profond, aura une ligne d'arrivée, où tout ne pourra pas être déployé.
Il faut connaître les limites, les apprivoiser, et se donner des buts raisonnés.

L'agilité dans les cadres

Quels sont les problèmes à résoudre? Et avec un zeste de bon sens, comment peut on aider à les résoudre. Car de mon ressenti, l'agilité est avant tout affaire de bon sens.

Face à un problème, reprendre le manifeste agile, et se dire, en quoi on ne respecte pas une des valeurs ou un des principes.
Une fois la valeur/ ou le principe identifié, il faut évaluer la capacité des personnes, à s'approprier ce principe, et à le mettre en oeuvre.
Vous pouvez alors essayer d'organiser un petit jeu, pour illustrer ce principe. Que les gens comprennent bien ce qui a été démontré par ce jeu, et ensuite essayer de les emmener sur le terrain du quotidien, et avec un peu de doigté, arriver sur le sujet que vous avez identifié comme étant un problème.
Compréhension, acquisition, appropriation.

Ensuite, regarder comment mettre en oeuvre. Peut être par la mise en place d'un rituel agile, d'une rencontre, d'une pratique... La solution importe peu. Il faut surtout que cela apporte un bénéfice, car on a compris qu'il faut remettre en équilibre certaines valeurs, pour que la machine soit ré huilé, et fonctionne sans à coup.

Donner du sens

Les outils, les pratiques, les rituels sont mis en oeuvre car un besoin se manifeste.
Et non l'inverse... On démarre par le besoin, et on établit le moyen d'y répondre en l'enrichissant de pratique, rituels, outils... Parfois il s'agit juste de faire ouvrir les yeux aux gens sur leur comportement, et les amener à comprendre en quoi cela les dessert, et trouver avec eux, une nouvelle manière de communiquer, et de travailler ensemble.

Par exemple, le daily meeting appuie un besoin de synchronisation, de planification, de sécurité, de partage, de visibilité, d'accompagnement, d'entraide... Mais il faut que le besoin existe, pour justifier de mettre en place un daily, et surtout donner aux personnes, le sens, et l'apport en valeur.

Cet exemple est un cas d'école, car il est souvent la première chose mise en place lors d'agilisation, mais le but sous jacent n'est souvent pas regardé.
Par contre c'est souvent une injonction simple qui est donnée : Toi équipe réunis toi toute seule pendant 15 min tous les jours, et on va vérifier. Et tu verras, tu pourras partager, et parler de tes problèmes ça va améliorer ton quotidien c'est sûr.

Les autres rituels, qui s'ouvrent à des personnes portant souvent des responsabilités et qui nécessitent plus de préparation, sont souvent plus laborieux à mettre en oeuvre.
Une injonction n'y suffit pas.
Le seul réel moyen d'y arriver est de donner du sens.

Et finalement est ce si important d'y arriver? Peut être qu'il existe d'autres manières de faire, et peut être que de changer le mindset des personnes et les aider à mieux travailler ensemble est peut être aussi le meilleur moyen d'y arriver plutôt que de s'imposer et d'imposer aux autres une réunion qui n'a de sens que dans certains cas et certains contextes, ou parce qu'un livre le dit.

Le cadre et les valeurs agiles?

Mettre en place un cadre de travail, c'est mettre en place des processus. Même s'ils paraissent vertueux, et qu'on a souvent besoin d'un processus décrit, et soutenant, n'oublions pas qu'il faut avant tout favoriser les individus et leurs interactions et se reposer ces questions:

• Quelle valeur je produis en mettant en place ce processus/rituel agile
• Quelle interaction je favorise grâce à cela, et au contraire quelle autre je réduis?
• Est ce que je vais favoriser la collaboration, et mettre en place un cadre de sécurité en faisant cela?
• Est ce que je ne rigidifie pas mon fonctionnement, plutôt que de me mettre dans une posture adaptative?

Vous aurez reconnu les 4 valeurs du manifeste. Comme quoi, en les traduisant correctement, on obtient un guide simple à utiliser dans n'importe quelle situation.

De l'écriture des User Stories

J'ai été sollicité récemment sur un sujet de User Story, et en y répondant, j'ai pris un peu le temps de reprendre un peu le sens de l'écriture des User Stories.

US et Agilité

Ecrire des users stories pour être agile, les écrire comme l'entend les méthodes agiles, être agile parce qu'on écrit des users stories...

Différentes choses dans ces propos me chiffonnent, j'aime à rappeler, de distinguer l'Agile (qui est de l'ordre de l'état d'esprit), des cadres de travail ou des méthodes.

Pour rappel, Scrum n'impose pas de formalisme d'échange entre le responsable produit et l'équipe.

Il préconise d'avoir un backlog, avec des éléments suffisants petits (un item doit pouvoir être réalisé en un sprint).

XP a apporté des éléments précisant un formalisme qui se veux standardisant. Aujourd'hui, la plupart des projets "agiles" utilisent ce "standard" pour échanger de l'information.

Échanger

Il faut bien comprendre qu’une US est avant tout un support d’échange, à la conversation, et non pas un livrable rédactionnel fini. Une US sert avant tout à transcrire un bout d’idée sous un format « standard » pour pouvoir la présenter aux développeurs.

XP préconise que cela tienne sur un bristol horizontal (titre, règle de gestion exprimé en tant que, je peux, afin de, et tests d’acceptation), cela donne une idée qu’en terme de contenu cela doit rester léger.

Même si cela reste un standard, ce n’est pas absolument la forme qui importe, et l’important est de savoir si finalement, grâce à cela, les équipes de développement sont en mesure de faire correctement leur travail. En soit, le travail de rédaction des US n’est qu’une étape dans le dialogue avec l’équipe pour obtenir le produit imaginé.

Pour rappel, les US doivent être INVEST (indépendante, négociable, verticale, suffisamment petite, testable), et le N de INVEST est négociable, c’est-à-dire que les développeurs doivent pouvoir demander au PO de retravailler/découper/reformuler une US, car lors de l’échange l’équipe trouve que l’US n’est pas à la bonne granularité, qu’il manque telle ou telle information, ou qu’elle n’est pas compréhensible en l’état.

Cela ne doit pas être considéré comme un livrable figé, immuable, mais bien un élément d'échange, qui peut vivre durant son cycle de vie.

Il faut être vigilant à ne pas transformer le travail de rédaction des US en ce qui s’apparentait avant à un cahier des charges, ou un dossier de spécification. Sinon on revient à un travail en silo, et du cycle en V.

Finalement, chaque US pourrait être un chapitre d'une spécification plus large, et le format ayant changé, appelé cela l'agile, alors que les usages restent toujours ceux de l'ancien monde.

Les écrits ne doivent en cas être des commandements et surtout ne jamais se substituer à l'échange verbale.

Agilité

Il faut revenir au manifeste agile, dont la 1ère valeur est individu & interaction plutôt que des processus & des outils.

La 2ème valeur indique également notre préférence en un logiciel qui fonctionne plutôt qu’en une documentation complète.

Backlog

Sur un autre sujet, il est important que le backlog ne soit pas de taille démesurée, et on ne prépare pas toutes les US en début de projet, sinon on retombe dans l’inefficace cycle en V. 

En main courante, j’encourage à ne garder qu’une vingtaine d’US finalisées (on va dire l’équivalent de 2 sprints d’avance). 

Le reste doit rester à l’état d’idée (epic, features, ....), afin de pouvoir ajuster au bon moment le besoin, et ne pas avoir besoin de repasser un temps important à corriger une spécification, ou à donner une spécification qui soit bancale (car rédigée 6 mois auparavant) vis-à-vis d’un existant qui a pu diverger.

Échanger et comprendre le besoin

Pour résumé, l’important est de se mettre d’accord ensemble (avec l’équipe de dev) sur leur besoins, sur ce qui les aide à traduire un besoin métier en un code applicatif, qui répond à vos exigences.

L’important n’est pas de passer du temps à rédiger, mais de maximiser le temps que vous avez à échanger avec l’équipe, pour qu’elle s’approprie votre besoin, le challenge, et que vous-mêmes vous vous imprégniez de leurs contraintes.

Les 3 amis

Afin de favoriser l’échange avec l’équipe et de déterminer la qualité de vos US en terme de contenu, il existe une pratique qui s’appelle le three amigos. Une fois ou deux par sprint, vous envoyez vos US aux développeurs et aux testeurs.

Vous organisez ensuite un workshop d’une heure, avec un po, un développeur, et un testeur, et vous vous concentrez sur comment tester les US (pas forcément besoin de descendre au niveau d’un plan de test).

Le but est que derrière cet échange tout le monde ait compris le besoin, car si on sait le tester, c’est qu’on a compris quel était le besoin, et parfois dans cette démarche, le po peut prendre conscience que son besoin n’est pas clair, ou trop important (pas assez découpé). Cela permet à chacun de découvrir ce qu’attend les uns les autres, et avoir les US au bon niveau en fin de compte.

A la fin

Vous êtes à la disposition de l’équipe pour qu’ils fassent au mieux leur travail, et l’équipe est à votre disposition pour produire le meilleur produit.

Pascal Ogil

Le Daily Meeting

J'entends des choses sur la pratique du daily meeting, et je souhaitais m'exprimer sur cette pratique.
C'est une pratique qui illuste très bien, la première valeur du manifeste:
"Les individus et leurs interactions"

Mise en oeuvre

Quand un projet passe en mode agile, c'est une pratique importante qu'il faut essayer de mettre en place.
Tous les jours, au même endroit à la même heure, pour réduire la complexité, et assurer la constance, selon le Scrum Guide.

C'est un vrai facilitateur de respecter cet axiome. Les équipiers savent ne pas devoir planifier une réunion au même moment, ils savent quand ils doivent se lever pour rejoindre les autres, et ils savent où cela se passe.
Il faut créer une routine. Le daily meeting ne doit pas devenir une routine (dans le sens péjoratif du terme), mais le fait d'y aller doit être une routine automatisée.

Le "stand up meeting"

La position debout est une position dynamique, une position ouverte aux autres, position mobile qui favorise l'échange.
C'est une bonne pratique. Néanmoins, notamment au démarrage, cette ouverture peut paraître difficile humainement pour certains, pour qui la création d'un havre personnel constitué de sa position "rentrée", assis sur sa chaise peut procurer une forme de sécurité.
Au delà de la position, si la parole est libre, les échanges fluides, le daily efficace et dynamique, la position des participants reste un élément de détail.

Idéalement devant le tableau de tâche de l'équipe (Scrum Board, Kanban Board, ...).
L'équipe doit pouvoir visualiser le statut du projet, et prendre des décisions en conséquence.
Il est important que le daily meeting se passe avec l'affichage des informations lui permettant de faire un statut de l'activité de chacun, et du projet.
Ces informations doivent susciter l'échange, et les interactions.

Mise à jour du Management visuel au daily meeting ou au fil de l'eau.

C'est une question récurrente.
Je pense que dans une équipe démarrant, la mise à jour au daily meeting, est une bonne pratique.
Cela permet visuellement aux gens de voir le changement, et de s'y intéresser.
C'est un acte social pour celui qui déplace ses tâches de montrer ses victoires ou ses problèmes.
Cela crée une dynamique d'équipe.
Attention, ce ne doit pas devenir le but du daily meeting. Ce n'est pas un moment réservé qu'à la mise à jour du statut du projet.

Pour une équipe plus expérimentée, on peut faire du fil de l'eau, car il existera un besoin de savoir à tout moment qui est sur quoi, quelles tâches sont à faire, et laquelle prendre.
Chaque personne finissant une tâche, ira en chercher de nouvelles, et a besoin de ce statut à jour tout au long de la journée.
Cela nécessite d'avoir des tâches suffisamment fines (d'une à plusieurs heures de travail, n'excédant pas pour la plupart la demi journée).

Mais que dit on lors d'un daily meeting?

En voilà une bonne question! Une bonne pratique est d'utiliser les 3 questions pour libérer la parole:
1/ Qu'ai je fait depuis le dernier daily?
2/ Que vais je faire aujourd'hui?
3/ Ai je des problèmes à partager?

Personnellement, je conseille également de faire de la capitalisation orale (écrite également, de manière évidente).
Hier j'ai rencontré tel problème, aujourd'hui je vous fais part succintement de ce problème et de sa résolution, et je vous invite à venir me voir pour que je vous montre comment j'ai fait.
Il faut véhiculer de l'information et que chacun y trouve quelque chose de valeur durant son meeting.

Mais ... est ce bien suffisant?

A quoi sert le daily meeting

En fait, toutes les questions que vous vous posez sur l'organisation du daily meeting ne peuvent être répondues, que si vous vous êtes posés la question du pourquoi?
Pourquoi doit on se voir tous les jours?
Le scrum guide donne une réponse à cela. L'équipe se réunit tous les jours pour re-planifier les prochaines 24h.
Elle inspecte son avancement au regard de ses engagements, et s'il y a un écart significatif, elle s'adapte, en trouvant les moyens de réduire cet écart.
Et ce, toutes les 24h.

En somme, la partie "déclarative" de chacun ne poursuit qu'un seul but : vérifier si on est dans le plan ou hors du plan.
Le but du daily meeting, permet de réadapter le planning pour atteindre les objectifs de l'équipe.

Voilà où doivent mener toutes les discussions de l'équipe. S'intéresser à l'activité des autres est enrichissant, mais se demander comment on va tenir nos objectifs me parait la cible prioritaire.

De fait, les actions de réattribution de tâches, de travailler à deux sur un sujet pour le débloquer, .... ont pour but de réduire l'écart afin d'atteindre nos objectifs.

En ayant cela en tête, le contenu d'un daily meeting semble beaucoup plus évident.
Le jeu des 3 questions finalement, sert à libérer la parole et à faire ressortir la raison des dérives pour prendre les actions nécessaires à la tenue du plan.
Quelque part, vous comprenez bien que cela reste une bonne pratique, mais elle ne se suffit pas à elle même. Plus encore, vous pouvez adopter d'autres dispositifs, et si votre équipe est vraiment mature, peu importe si tout le monde parle ou non.
L'équipe se concentrera sur les écarts, et ensemble ils comprendront d'où viennent les écarts, et les solutions à apporter.

Du coup, l'apport du management visuel, au regard de cela, devient primordial. L'équipe doit pouvoir inspecter son avancement.
Les outils tel que le Scrum Board, ou le burn down chart sont indispensables à cet égard.
Sans cela, vous en resterez à coup sûr à une discussion sur ce que chacun a fait.

Anti Pattern

L'heure c'est l'heure

L'un des plus gros anti patterns que je connaisse, et d'organiser le daily meeting en début de matinée, pour que les gens arrivent avant l'heure du daily meeting.
Le manager voit ses équipiers arrivés de manière étalée dans la matinée.
Pour remedier à cela et que tout le monde soit présent à 9h au bureau, il instaure le daily meeting à 9h15.
1/ C'est à l'équipe de savoir quel est le meilleur moment de la journée.
2/ Le fait d'imposer à un moment qui ne convient pas, suscite une non adhésion, et donc un daily meeting qui perdra de son intérêt et de sa valeur
3/ Si quelqu'un a un problème avec l'heure d'arrivée d'une personne, il s'agira plutôt d'aller la voir et d'en discuter avec elle. Parfois il s'agira d'une réelle contrainte (enfants, ...) soit d'un manque de compréhension sur les horaires à adopter pour un travail d'équipe efficace.

Faire du reporting

Le daily meeting ne doit pas être juste une phase déclarative de son activité.
Si le daily meeting est poussé par le chef de projet, il y a souvent une raison.
Si l'équipe a du mal à se motiver pour y assister, quelque chose ne se passe pas bien. Le sens n'est pas compris.

Ticket X

Parler des activités en ne citant que son numéro. Cela obscurcit ce quoi vous travaillez, cela va en contradiction avec la valeur "transparence".
Et surtout, on revient à l'anti pattern faire du reporting. On sent bien que la personne ne souhaite pas parler de son travail, mais juste acter de son travail sur un ticket ou un autre.

Pascal Ogil

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