Qu’est-ce que ça fait un gestionnaire de projet dans une approche Agile ?

Tout le monde le sait, le gain en popularité des approches agiles a bouleversé le rôle traditionnel du gestionnaire de projet. Ce dernier, sur qui l’imputabilité du projet reposait dans son entièreté, se retrouve maintenant dans une zone floue, où soudainement, l’agilité lui allège le fardeau de cette imputabilité du projet. Dans le cadre de mes accompagnements, comme formateur, coach agile ou gestionnaire de projet, j’entends beaucoup de questionnements sur le rôle que doit jouer le gestionnaire de projet dans un projet réalisé avec une approche agile. Les attentes envers un gestionnaire de projet sont très différentes d’une organisation à l’autre, et ce, juxtaposé au cadre méthodologique qui se développe de manière personnalisée dans chaque organisation, ajoutent du brouillard à la vision que les gens ont d’un gestionnaire de projet. Bref, depuis les deux dernières années, je me suis fait poser la question par plusieurs personnes, d’organisations différentes, qui me demandent; Martin, qu’est-ce que ça fait un gestionnaire de projet dans une approche agile ? Martin, est-ce qu’on a toujours besoin d’un gestionnaire de projet quand on réalise avec une approche agile ? Comme bien d’autres choses, je suis porté à répondre : Ça dépend !

Alors avant d’aller plus loin, et comme je ne sens pas qu’il y a une vérité à la question, j’ai plutôt le goût d’échanger sur le sujet avec vous. Selon vous, est-ce que vous avez toujours besoin d’un gestionnaire de projet lors de la réalisation de vos projets avec une approche agile ? Et pourquoi ? Utilisez la zone « commentaires » au bas de cet article pour partager vos réflexions!

Ne forcez pas pour 60%

(english follows)

Je dis souvent à mes équipes “Ne forcez pas pour 60%”. Cela veut dire : assurons-nous que nous ne sommes jamais dans une posture où nous devons travailler sous pression seulement pour atteindre un résultat minimum. Si nous devons donner un surplus de travail, nous devrions utiliser cette énergie pour l’ajout de trucs « cool » au delà du 100%. En d’autres mots, le travail normal ne devrait pas être précipité.

En théorie, nous visons tous à développer du logiciel de qualité à un rythme soutenable. En pratique, nous voyons malheureusement le contraire trop souvent. Ce problème majeur est enraciné dans un défaut fondamental de certaines cultures de développement où la qualité est priorisée au détriment de la cadence soutenable. Dans ces culture, il serait inacceptable de livrer un produit minimum viable (MVP) en ne travaillant qu’à un rythme soutenable. En même temps, rien ne serait dit ou changé si le même MVP était livré de façon précipitée avec des heures supplémentaires.

Le produit minimum viable (MVP) est seulement la note de passage, similaire à recevoir une note de 60%. En restant dans cette analogie de l’examen, livrer un logiciel de qualité serait similaire à une note de 100%. Les organisations devraient alors s’assurer que la livraison de logiciels de qualité soit vraiment planifiée, et que ceux-ci pourront être livrés de façon soutenable. De cette façon, plutôt que de parier sur des livraisons normales, nous pouvons maintenant parier sur les opportunités de valeur ajoutée pouvant être saisies au moment où elles se présentent. Ces opportunités vont fort probablement demander un effort supplémentaire, mais puisqu’elles constituent un ajout positif tout en restant optionnelles, il sera stimulant pour l’équipe de se forcer pour une bonne cause.

Se forcer pour la dernière place n’est jamais stimulant.

Phillipe Cantin

 

Don`t Rush For 60%

I often tell my teams “Don’t Rush for 60%”. This means, let’s make sure that we are never in a situation where we need to do a push only to reach the bare minimum. If we have a push to do, let’s use this energy to add cool stuff beyond the 100% mark. Simply put, normal work should not be a rush job.

In theory, we all aim to develop quality software at a sustainable pace. In practice, we sadly see the opposite far too often. This is a major problem rooted in a fundamental flaw in some development cultures where quality is prioritised over sustainability of the pace. In such cultures, it would be completely unacceptable to ship a Minimum Viable Product (MVP) while only working at a sustainable pace. At the same time, nothing would be said or changed if the same MVP was delivered at a breakneck pace.

The MVP is only the passing grade, like getting 60% on a exam. Staying in this ‘exam’ analogy, shipping quality software would be like getting 100%. Organizations should then aim at ensuring that shipping quality software at a sustainable pace is actually part of the project plans. By doing so, instead of betting on the normal delivery, we can now bet on catching added-value opportunities as they present themselves. Those opportunities will most probably require extra work and yet, by being a positive addition while remaining optional, it feels good to invest this extra effort for such a good cause.

Rushing for last place never feels good.

Phillipe Cantin

Stabilisez votre système pour devenir prévisible !

image2017-3-14_9-7-15

Stabiliser le système

Nous proposons actuellement notre démarche Kanban afin d’appuyer une organisation dans l’implantation de Kanban.

La démarche que l’on a créée se décline en 3 Jalons, est alignée sur les 6 Pratiques Kanban de la méthode et est supportée par une Roadmap de Gestion du Changement.

Vous pouvez relire le premier billet de la série intitulé : Des passionnés de Kanban. ainsi que celui consacré au premier jalon :INTRODUIRE.

Cette semaine, nous vous amenons au second jalon : STABILISER

STABILISER – « Stabiliser le système »

L’objectif de ce jalon est d’amener l’équipe à opérer les changements nécessaires pour devenir prédictible, tant au niveau de sa capacité que sur le débit de travail qu’elle est en mesure de livrer à sa clientèle. À partir des informations révélées à l’étape d’introduction et en stabilisant les facteurs générant de la variabilité, l’équipe pourra fournir des ententes de service fiables à ses clients.

Prévisibilité

image2017-3-6_15-28-17

Si vous demandez à votre plombier :

Quand la fuite de mon évier sera-t-elle réparée ?

Quelle sera votre réaction s’il vous répond :

Je ne sais pas, cela dépend du temps que vont prendre les travaux des clients avant vous, et si il n’y a pas d’imprévus… Peut-être cette semaine… sinon la semaine prochaine…

Mitigé pour le moins? Par contre, si il répond :

Étant donné votre demande et les autres travaux prévus avant, ce sera fait d’ici lundi.

Pour prévoir l’avenir (s’engager sur une entente de service), il faut voir le présent (le travail en cours et les contraintes du système) mais aussi comprendre le passé (l’historique de métriques).

Le deuxième jalon va donc nous permettre de mettre en place divers éléments pour stabiliser le système en contrôlant sa variabilité, dans le but de le rendre prévisible.

Description du jalon

À l’intérieur de la démarche, un jalon est un ensemble d’outils et de techniques à mettre en place afin d’atteindre une cible. Un jalon se décline en 6 sections, soit une pour chacune des pratiques de la méthode Kanban.

Une liste d’éléments de gestion du changement est attachée à chaque section. Ces éléments doivent être pris en compte pour appuyer l’implantation de Kanban et s’adressent à 4 clientèles:

image2017-2-17_9-52-52.png image2017-2-17_9-53-0.png image2017-2-17_9-52-31.png image2017-2-17_9-52-42.png
Équipe  Gestionnaire  Client  Partie prenante

Pour atteindre la cible du jalon, l’ensemble de ces outils et techniques ainsi que l’exécution des éléments de gestion du changement doivent avoir été complétés avec succès. L’objectif de la démarche n’est pas de décrire de façon détaillée l’implantation, mais de structurer les éléments principaux afin de laisser place à l’adaptation au contexte d’une équipe. Chez Facilité, la philosophie est ancrée dans la pragmatisme. Ce que nous conseillons est toujours en fonction du contexte dans lequel on intervient. Le rythme, la portée et la vélocité du changement sera variable d’un contexte à l’autre.

Cible du jalon

La cible visée est la suivante :

  • Changements en continu pilotés par les informations révélées.
  • Système prédictible en termes de:
    • Capacité
    • Débit
  • Ententes de services définies

Visualiser le processus

  • Utiliser le diagramme de vieillissement du travail en cours (Aging Diagram)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Surveiller le vieillissement des tâches pour préserver le temps de cycle

X

 

 

Limiter le travail en cours (WIP)

  • Limiter le travail en cours (WIP).
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Expliquer pourquoi et comment le travail sera limité.

X

X

X

 

Comprendre et respecter le point unique d’alimentation.

X

 X

 X

 

Optimiser le flux de travail

  • Utiliser le diagramme de flux cumulé (CFD);
  • Visualiser et gérer les bloquants;
  • Utiliser la pratique de flux tiré;
  • Utiliser le nuage statistique des temps de cycle;
  • Utiliser le right-sizing pour le découpage du travail.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Apprendre à interpréter le diagramme de flux cumulé (CFD)

X

 

 

 

Accepter la transparence des bloquants

 X

 

 X

Apprendre à maîtriser le flux tiré

 X

 

 

 

Apprendre à interpréter le nuage statistique

 X

 

 

 

Laisser l’équipe gérer le système

 

 X

X

 

Rendre les règles explicites

  • Définir des ententes de services (SLA).
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

S’engager sur des ententes de service

X

X

S’entendre sur des ententes de service

 

 

 X  X

Identifier les cadences

  • Cadencer la synchronisation avec les contributeurs/collaborateurs;
  • Cadencer l’alimentation en fonction du débit de sortie.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Impliquer les contributeurs dans l’équipe

X

 

 

Comprendre l’importance de limiter le travail en entrée

 

 X

 

Améliorer en continu

  • Mesurer l’impact de l’amélioration à l’aide d’actions SMART.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Utiliser les métriques pour mesurer l’amélioration

X

 X

 X

 

À suivre prochainement

Nous vous invitons à surveiller ExcellenceAgile.com durant les prochaines semaines car nous allons dévoiler le dernier jalon, soit le jalon PROPULSER… ainsi qu’une SURPRISE pour vous remercier d’avoir suivi notre série de blogs !!

 

Nicolas Mercier
Valéry Germain

C’est quoi le besoin?

J’ai souvent des discussions sur la définition de besoin avec des gens qui prennent en charge le rôle de PO et qui doivent exprimer un besoin d’affaires. Le cas de figure le plus fréquent est lorsqu’on retrouve le Comment au lieu du Quoi. Un de mes outils est le patron suivant :

En tant que …
Je veux…
Afin de…

Je n’entrerai pas dans les détails sur ce patron, mais pour des références sur le sujet je vous suggère cet article de Mike Cohn :
https://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template

La métaphore

J’aimerais plutôt parler d’un autre outil très puissant qui peut nous aider lorsque vient le temps d’expliquer comment définir un besoin d’affaires : la métaphore. Une métaphore est une image utilisée pour illustrer une réalité, un concept, une idée et en faciliter la compréhension. La métaphore que j’utilise lorsque je veux expliquer comment passer du Comment vers le Quoi est la suivante.

Je travaille dans un centre de rénovation. Un client vient me voir pour un acheter une pelle.

Client: Je veux une pelle.

Je pourrais l’amener dans la section des outils et lui vendre une pelle, mais je préfère creuser un peu plus (sans vouloir faire un mauvais jeu de mot).

Moi: Très bien, mais quel est votre besoin? Pourquoi voulez-vous une pelle?

et le client de répondre:Creuser.png

Client: Ben, je veux creuser un trou!

Moi: Fantastique! Mais pourquoi voulez-vous creuser un trou?

Client: C’est parce que je veux planter un arbre.

Arbre.jpgAh! Voilà le vrai besoin….. Mais, question de s’amuser un peu, on continue de chercher, juste pour voir.

Moi: Quelle bonne idée! Mais dites-moi, pourquoi plantez-vous un arbre?

Client: J’adore être a l’extérieur et j’aimerais faire un peu d’ombre sur mon terrain.

Ça se précise. On voit qu’en explorant le besoin, on découvre des informations intéressantes qui pourraient me guider vers une solution idéale. Poursuivons.

Moi: D’accord. Mais pourquoi souhaitez-vous faire de l’ombre sur votre terrain?

Client: J’ai tellement chaud quand je suis à l’extérieur l’été que je n’en pro
fite pas souvent. J’aimerais avoir un coin frais à l’ombre lorsque je suis à l’extérieur.

Parasol.pngBINGO! En ayant investigué le besoin, j’ai fait ressortir des éléments très importants et j’ai réussi à découvrir le besoin réel qui se cachait derrière un ensemble de solutions que le client avait en tête. Je suis donc parfaitement outillé afin de proposer une solution pour répondre à son besoin puisque je l’ai clairement identifié. Je pourrais lui proposer l’achat d’un magnifique parasol, pas d’entretien, pas de fertilisation, pas d’élagage des branches. Peut-être que ça répondrait beaucoup mieux au besoin.
Donc, le client est entré dans le magasin en voulant acheter une pelle, et il est reparti avec un parasol. Je viens de faire 10 fois plus de profit! Euuuh, je veux dire: je l’ai aidé à identifier son besoin réel.

En conclusion

L’une des responsabilités les plus importantes du PO dans sa relation avec une équipe de réalisation est d’exprimer clairement le besoin et d’aller au fond des choses. De son côté, l’équipe de réalisation a la responsabilité de trouver la meilleure solution possible pour répondre à ce besoin. Si le PO dit: « Je veux un bouton, je veux un onglet ou je veux une pelle!« , l’équipe a de fortes chances de passer à côté du besoin et de livrer une solution qui ne sera pas adéquate ni efficace. Par contre, si on fait le même genre d’exercice que dans la métaphore de la pelle, on risque de tomber sur le besoin réel, ce qui laisse toute la place à l’équipe de réalisation pour trouver LA solution parfaite.

6 choses à faire pour bien commencer la journée de travail

Grenouille 2.jpg

1. Ne regardez pas vos emails, vous risquez de vous éparpiller et d’oublier l’objectif principal de la journée.

2. Demandez-vous quelles sont les activités critiques à faire. Pour vous aider, vous pouvez faire un scan rapide des emails. Cherchez les alertes et détectez les impacts possibles sur vos objectifs de la journée.

3. Repriorisez votre liste de choses à faire. Si vous avez un kanban personnel, mettez-le à jour!

4. Mangez la grenouille en premier…

« Si c’est votre travail de manger une grenouille, il est préférable de le faire le matin. Et si c’est votre travail de manger deux grenouilles, il est préférable de manger la plus grosse d’abord » – Mark Twain.

Duo gagnant = kanban personnel + la technique du pomodoro.

5. Saluez vos collègues, ça vous aide à commencer votre journée de meilleure humeur et à recevoir de l’aide plus facilement.

6. N’oubliez pas de relaxer de temps en temps. Pour activer la créativité et l’innovation, il faut bouger, changer d’environnement, changer vos chaussettes…. Les idées arriveront sans effort à votre cerveau.

Inspiré de:

https://www.fastcompany.com/3056631/how-to-be-a-success-at-everything/the-first-four-things-you-should-do-every-workday