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

Conduite du changement

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

Chef de projet et Scrum Master : changez votre vision du monde

Constat

A l'heure de la "mode" SCRUM et agile, beaucoup de chefs de projet tentent la reconversion vers l'agilité.
Nombre d'entre eux, n'ont pas compris qu'il ne s'agit pas en premier lieu d'appliquer une méthode. Malheureusement en France, nous avons fait l'erreur de nommer cela "Méthodes agiles".
Pour rappel, l'"Agilité" telle que nous le connaissons, est d'abord issu du manifeste agile, qui reprend les valeurs et les principes principaux sur lesquels nous fondons notre conviction, et notre état d'esprit.
Ensuite, s'agissant de SCRUM, SCRUM se définit lui même comme étant un "FrameWork", un cadre de travail. Pas une méthode à proprement dite.

Pourquoi cette introduction, car de ce que je vois, nombre de personnes tentent d'appliquer une recette magique, et parfois, quand cette recette, ne donne pas le résultat escompté, on remet en cause la recette, et non les hommes qui tentent de l'appliquer.
Il s'agit avant tout, de changer d'état d'esprit. Il faut revoir sa manière de penser, et d'appréhender les projets.

Mais il est dur de sortir de 20 ans (voire plus long), de cycle en V, mais je ne mettrai pas tout sur le dos de cette méthode qui a toujours ses bénéfices dans les contextes appropriés.
Je pense, que l'aspect qui a le plus gangréné notre manière de travailler est la monétisation via le sacro saint "mode forfait".

Le mode forfait consiste, pour rappel, à débarasser le client d'un projet, en lui produisant un logiciel, qui répond à des spécifications écrites par des tierces parties (rarement le métier), et dont l'interprétation est assez identique à tout livre de référence (ancien testament, Nostradamaus, La divine comédie), c'est à dire très éloignée de la réalité, ou de la volonté du spécifieur (ou écrivain).
Le client est alors souvent spectateur de son projet, à l'image d'un film, où il ne le voit qu'une fois finie, et souvent avec une certaine appréhension, et au final, une certaine déception.

Aujourd'hui, les notions de transparence, de responsabilisation, de ce que j'appellerai le code "just in time", sont encore de mots vains pour beaucoup.

Collaboration  : partage des difficultés

L'agilité est d'abord question de collaboration. A mon sens, la collaboration signifie que nous faisons partie d'une même équipe. Nous jouons dans le même camp, pour aboutir ensemble au bon résultat.
Pour l'ensemble des parties, c'est de réussir à partager ses succès, mais surtout partager ses échecs, ses difficultés.
On arrête de masquer ou de lisses ses difficultés. La transparence est une clef de succès. Mentir met systématiquement quelqu'un dans une position difficile.

Il faut que chaque partie réussisse au plus tôt à mettre en évidence, les difficultés liées à son poste (pour le PO, et pour la dev Team). On essaye alors de trouver les plans d'action pour prendre en charge ces difficultés, et les rendre acceptable dans la cadre du projet.
Nier l'évidence, est le meilleur moyen d'aller vers l'échec. La mise en évidence, permet à chacun de travailler en fonction du contexte, et non pas en faisant semblant que l'équipe se trouve dans un utopie.

Transparence & Avancement

Ce que j'essaye d'inculquer à chacune de mes formations est la culture du succès. Idéalement, chaque itération doit correspondre à un succès.
Le succès n'est pas exempt d'embûches ou de difficultés. Le succès c'est d'avoir réussi à en tenir compte pour mener à bien son itération.

La fin d'itération est aussi là pour exposer à chacune des parties les difficultés rencontrées, pour les prendre en compte. Soit pour les aplanir, car les moyens à mettre en oeuvre sont à notre main, soit pour les considérer commme faisant partie du contexte.
Si ces difficultés font partie du contexte, lors des itérations suivantes, les items dans le même contexte, seront à évaluer avec un indice de difficulté les prenant en compte.

Il est important de comprendre, que des items de même type, puissent changer d'évaluation lors de l'estimation, suite à la découverte de leur contexte. Il est sain, que ce contexte entre en ligne de compte la prochaine fois qu'il est évalué.

Auto organisation

Je pense que le plus gros penchant pour le chef de projet est de réussir à se contenir quant à l'organisation de l'équipe. Des règles d'équipes se mettent en place, soyez vigilants à ce qu'elles soient bien respectées, cela demeure dans votre rôle.
Par contre, quant à l'affectation des tâches, à l'entraide... soyez vigilant à rester assez neutre. L'équipe doit maîtriser ce qu'elle fait, et le fait d'avoir un pilote qui s'immisce dans la micro organisation va donner quelque chose de très inefficace et de frustrant pour l'équipe.
Vous pouvez sonder quelques fois, afin de savoir si l'équipe n'a pas oublié quelque chose, plus en format rapport d'étonnement. Soit l'équipe a effectivement oublié quelque chose, et s'adaptera pour compenser cet oubli, soit c'est sciemment que ce choix a été fait, en ce cas, elle vous fournira l'explication qui saura vous rassurer.

Il faut réussir à trouver la bonne distance, entre conseil, et intrusion.


Pascal Ogil