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.

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

Retrospective : IceBreaker, mais pourquoi le faire?

La recommandation pour mener à bien une rétrospective se fait de mon point de vue en 5 étapes:
-- rappel des objectifs de la rétro
-- icebreaker
-- collecte des informations
-- brainstorming & plan d'action
-- Revue rapide de la rétro en vue de son amélioration

J'ai connu certains responsables ou "leader" qui ne passaient pas par la case Icebreaker. Les raisons soulevées sont nombreuses : l'équipe se connait, l'équipe est autonome, l'équipe n'en a pas besoin.
De mon point de vue, la réalité est un peu différente. Souvent, le principe n'est bien souvent pas bien compris, et les gens ne s'intéressent pas ou ne s'authorisent pas  à une certaine variété, et restent dans la répétion, ou l'imitation.

Les icebreakers sont nombreux, et je serai tenté de dire, que vous n'êtes limités qu'à votre imagination.
Pour moi l'icebreaker répond à un principe simple, mais peuvent être utilisés à des fins plus subtiles.

Pour rappel, comme son nom l'indique, il est là pour briser la glace. L'équipe vient à une réunion, elle sait qu'elle va être sollicitée, mais prendre la parole face aux autres, en supporter le jugement, ....
La plupart des équipes que j'ai connu sont bien souvent "léthargiques" et attendent d'être menées, guidées. Bien souvent elle a besoin d'être activée pour déclencher une certaine dynamique.

LES FINS SUBTILES

Mais revenons tout d'abord aux "fins subtiles", laissant le but apparent de côté.
L'icebreaker peut être utilisée à des fins personnelles, ou dans un but de construire l'équipe (team building).

FINS PERSONNELLES

Parfois, quand je ne connais pas l'équipe, ou que je sens qu'il y a quelque chose qui cloche(?) dans l'attitude des gens, je lance un icebreaker de première approche.
Ces icebreakers me permettent d'avoir une première vision de l'état morale de l'équipe, voire de leur motivation, ou manque de motivation.
C'est une information très utile, pour orienter la manière dont vous allez conduire votre rétrospective. En effet, une équipe démotivée, étant là par la force des choses, il va falloir trouver les leviers pour que la rétrospective reste constructive, et éviter les éccueils du ressentiment.

Il existe plusieurs "outils" pour démarrer.
On peut utiliser le MVP, qui est plutôt simple. Motivé, Vacancier, Prisonnier. Vous pouvez ajouter les nuances que vous souhaitez. Chacun apporte un post it vierge, et le pose dans la case qui le concerne. Pas d'explication.
Cela permet de savoir si l'équipe vient contrainte, sans but, ou au contraire, très concerné par la rétrospective.

Le nikoniko, est simple d'utilisation aussi. Une colonne dans quelle situation vous sentez vous (travail intéressant, motivation, ....), et que pensez vous de l'équipe (bonne ambiance, bonne dynamique, ....). Chacun vient coller 2 post it de couleur (vert ou rouge), un dans chaque colonne.

Vous avez une photo plutôt fiable (si les gens jouent le jeu), vous permettant de connaître l'état d'esprit individuel d'une part, et la cohésion d'équipe d'autre part.

Team Building

Il ne faut pas négliger le team building, le long des cérémonies agiles. Si on peut créer des souvenirs en communs, des "liants", qui permette de rendre la cohésion d'équipe plus forte il ne faut pas s'en priver.
Personnellement, il y a 2 approches à cela, et on va retrouver les thèmes classiques qui sont vis ma vie, et les énergisants

Vis ma vie

Ce sont les petits exercices qui permettent de manière simple, d'apprendre des choses sur ses équipiers.
Quelques exemples par exemple, chacun son tour, vient coller un post it, avec son film préféré, en expliquant pourquoi, ou quel film est ce?
On peut varier sur le plat préféré, le lieu de vacances préféré.

Un exercice rigolo à faire également concerne la situation géographique de chacun. Si globalement, l'éparpillement des gens est de 20km à la ronde. On peut imaginer indiquer que le centre de la pièce est le lieu de travail, on indique le nord, et à chacun de se mettre en position relative dans la pièce pour indiquer son lieu d'habitation.
On découvre alors que certains habitent à 2 pas ou au contraire à 1h de route.

Energisant

La création de situation où on peut rire, où on voit les autres adopter des attitudes différentes, le fait de relevé un défi, typiquement où il faut être le meilleur, le challenge, ... tout cela crée aussi des souvenirs, et crée du liant entre les gens.
Internet regorge d'exemple, je vous laisse trouver ceux qui vous conviennent.

Fins avérées

Le but de l'icebreaker a pour premier but de "réveiller" l'équipe, et surtout de démarrer une première expression sur des sujets non engageants.
Les gens parlent durant cet exercice devant tous, et chacun respecte la parole. Ca créée un sentiment de liberté, qui permettra ensuite d'avoir une phase d'expression libérée.
C'est un moment important pour l'animateur, où justement il faut veiller à ce que ce moment soit vraiment libre, qu'il n'y ait pas de jugement, mais plutôt qu'un intérêt/une écoute envers l'autre se créée.
Si suite à cet exercice les gens se sentent moqués, jugés.... l'exercice a perdu de son sens, et la partie expression libre sera compliquée.
Pas de soucis pour que cela reste un exercice amusant, mais la bienveillance et l'écoute reste des éléments primordiaux.

Cas de démotivation

Il m'est arrivé de conduire des rétrospectives "stériles" où l'équipe avait besoin de laver son lave linge, ou de "pester" sur le management. Chacun s'explique, chacun donne son opinion, on partage, on créée des échanges, on essaye de rendre le fardeau plus simple à porter.
L'important c'est que malgré tout à la fin de l'exercice, même aucun plan d'amélioration n'est sorti, du fait de l'extériorisation des problèmes, le côté "vidage de sac" ait pu apporter une certaine sérénité à chacun.
En effet, le fait de pouvoir vider son sac, de partager son expérience, de voir que la personne n'est pas toute seule, qu'on la supporte, cela peut aussi resserrer les liens de l'équipe.
L'équipe doit en sortir apaisée, ou remontée, mais de manière positive (tous unis face), il faut essayer de tourner cela vers l'union, et pas le désespoir.
Ce n'est pas chose simple. Il convient d'avoir de vrais qualités humaines, et beaucoup de recul.
"Ok, voilà la situation, elle est compliquée, mais que fait on? Comment l'utilisons nous pour continuer à avancer? Vous venez tous les jours travailler, comment gérer la situation?"

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.

QuickWin?

Quelle est la différence entre quickwin et petit pas? Normalement, ce n'est qu'une question de communication à propos d'un succès.

Quand vous travaillez à faire un changement important dans votre organisation, ou quand vous souhaitez essayer une nouvelle manière de travailler, ou encore quand vous souhaitez construire quelque chose de nouveau, je pense qu'il est vraiment difficile de tout planifié, et d'avoir des jalons prédéterminés fiables.

Vous avez toujours des forces externes, qui à tout moment, peuvent faire en sorte que quelque chose se passe mal. De ce que m'apprend l'agilité, je vous conseille d'essayer, d'inspecter le résultat, et d'adapter le processus. C'est la méthode des petits pas. Un enfant qui apprend à marcher.

Minimiser les risques, et gardez en tête que vous pouvez toujours changer quelque chose dans votre plan, pour redresser la barre vers la bonne direction.

En cela, certaines personnes aiment les quickwins. C'est un mot agréable à entendre. Nous produisons quelque chose sur lequel nous pouvons communiquer, et montrer notre succès. C'est bon pour la motivation, c'est bon se savoir que nous allons dans la bonne direction, que nous apportons de la valeur, et c'est bon à montrer à nos managers.

Mais rappelons nous, que le quickwin est un pas dans le mouvement. La valeur gagnée doit être utilisée pour effectuer les pas suivants. Comme le premier pas engendre une motricité, une force permettant de continuer le mouvement.

La valeur gagnée ne doit pas être un profit qui part intégralement dans la bourse de votre manager, comme un trésor gagné qui lui permet de justifier de ses propres résultats.

Un quickwin n'est pas la fin d'un process, mais c'est un pas utile pour démontrer que nous avons pris les bonnes décisions, et que nous avons trouvé l'énergie pour avancer.