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

Tout est un livrable

(English follows)

En 2009, je lisais l’excellent billet “The Duct Tape Programmer” par Joel Spolsky qui souligne l’importance de livrer plutôt que d’atteindre la perfection. Il résume bien sa pensée en disant “Livrer est une fonctionnalité” (Shipping is a feature). Ceci a eu un impact sur moi, car j’applique depuis cette philosophie sur plusieurs choses, poussant à maximiser la qualité tout en assurant systématiquement la livraison.  Je crois aussi qu’à l’intérieur de chaque équipe livrant du logiciel fonctionnel, il y a une personne qui se bat pour la livraison. Autrement, l’équipe resterait piégée infiniment dans un état à 90% complété.

Lorsque que j’approche chaque événement Scrum, chaque sprint, chaque période d’un projet et chaque réunion, je divise les buts en 2 groupes;  le Vital (Must) qui ne peut être atteint que par l’effort collaboratif du groupe et l’Essentiel (Should) qui gagnerait en efficience si il était complété par le groupe.  Par la suite, je recentre les efforts et surveille le temps pour assurer minimalement la livraison du Vital. L’objectif est d’éviter de pousser vers l’avant des tâches non-terminées qui, inévitablement, créeront un effet de cascade dans le flux de travail.

Voici une autre façon de voir la situation. Alors qu’un projet avance, nous créons des moments où nous réservons la capacité d’un groupe de personnes ayant la bonne combinaison de talent pour exécuter un travail précis.  Ce groupe fournit la connaissance et le pouvoir décisionnel unique pour faire avancer un gros bloc de travail. Les membres de l’équipe étant tous réunis, la boucle de communication est alors très efficiente.  Une fois que ce moment est passé, cette boucle de collaboration sera dramatiquement ralentie alors que le focus et la capacité des gens seront submergés par d’autres tâches.  Au début de chacun de ces ‘moments en groupe’, il est donc impératif d’identifier le travail Vital.

Livrer quelque chose, peu importe ce que c’est, est toujours une petite victoire qui vient donner de l’énergie aux membres de l’équipe. Nous voulons donc toutes les victoires possibles afin de garder le moral lorsqu’on traverse les haut et les bas du développement logiciel.  Livrer tout, à tous les moments, m’aide à guider mes équipes dans les périodes difficiles. Ceci me permet de célébrer le fait que nous avons eu une bonne planification de sprint, et que nous pourrons compter sur celle-ci jusqu’à la fin du sprint sans avoir d’autre réunion de clarification.  Livrer tout, c’est savoir que chaque histoire terminée est un avancement concret qui, malgré les embûches, à pu être réalisé à l’intérieur du sprint. Ceci aide à se sentir comme un héros à la fin d’un sprint dans lequel on a livré notre engagement et entrer dans le sprint suivant avec un sentiment de nouveau départ qui n’est pas entaché.

Livrer tout permet de parsemer notre travail de petites victoires.

Phillipe Cantin

Ship Everything

Back in 2009, I was reading a great blog post by Joel Spolsky called “The Duct Tape Programmer” in which he underlined the importance of delivery over perfection. Summing it up in this great motto: “Shipping is a feature”.  This must have had some impact on me since I now apply this philosophy to so many things, pushing to maximize quality while always ensuring delivery.  I also believe that every team delivering working software has at least one person who fights for shipping or they would endlessly remain caught in the “90% done” purgatory.

When approaching every Scrum event, every sprint, every project period and every meeting, I divide the goals in two groups;  the Must which can only be done by the collaborative effort of the group and the Should which would be more effective if done by this group.  I then focus the efforts and monitor the time to, minimally, ensure the resolution of the Must.  The objective is to avoid pushing unfinished work forward which will inevitably create a cascading effect down the workflow.

Look at it this way: as a project moves forward, we create moments where we secure the capacity of the right mix of people to execute a specific task.  This group provides the unique knowledge and the decision power necessary to move forward a large block for work and, by all being present, the collaboration loop is very efficient.  Once this moment is passed, this collaboration loop will slow down dramatically as people`s focus and capacity are swept up by other tasks.  At the beginning of each ‘group moment’, it is then imperative to identify the Must work.

Shipping something, anything, is also a small win adding fuel to the tank of the team members.  We want all the wins we can get to protect the morale through the ups and downs of software development.  Shipping everything, every moment, is how I get my teams through thick and thin.  Celebrating the fact that we had an awesome sprint planning on which we can count to get us to the end of the sprint without a string of meetings.  Knowing that every story done is a concrete step forward which, even with the unexpected,  was able to fit within the sprint.  Feeling like heroes at the end of a sprint where we shipped all the committed work while entering the next sprint with an untainted feeling of a fresh start.

Shipping everything is a way to punctuate our work with small wins.

Phillipe Cantin

Révélez votre système au grand jour !

Banner - Introduire.png

Nous proposons actuellement notre démarche Kanban, dont l’objectif est d’appuyer une organisation dans l’implantation de Kanban. Vous pouvez relire le premier billet de la série intitulé : Des passionnés de Kanban.

Notre démarche se décline en 3 Jalons, est alignée sur les 6 Pratiques Kanban et supportée par un Roadmap de Gestion du Changement.

Cette semaine, intéressons-nous au premier jalon : INTRODUIRE

INTRODUIRE – « Révéler le système »

L’objectif de ce jalon est de rendre visible le système d’alimentation d’une équipe, l’état de l’ensemble du travail en cours et les règles et processus internes. Cette visibilité fournira l’information nécessaire à l’équipe et son écosystème (ses clients, ses parties prenantes et sa gouvernance) afin de mettre en place son processus d’amélioration continue, ce qui permettra d’optimiser la valeur générée par sa prestation de service.

Un point très important à noter: lors de ce premier jalon, pratiquement aucun changement n’est opéré sur le processus de travail, les rôles et les responsabilités des gens impliqués. Nous voulons observer le système tel qu’il est à l’aide d’indicateurs et d’observations factuelles. Ceci va fournir les informations nécessaires pour pouvoir amener les bons changements dans les prochains jalons.

Visibilité

image2017-2-17_10-4-49.png

Lorsqu’on se présente chez le médecin et qu’on lui dit :

Docteur, j’ai mal.

Il nous répond inévitablement :

Mais, où avez-vous mal exactement?

Pour pouvoir agir sur quelque chose, il faut le comprendre et pour le comprendre, il faut le voir. Il faut voir les opportunités d’amélioration, et ensuite il faut poser les bons gestes pour opérer un changement.

Le premier jalon va donc mettre en place divers éléments destinés à rendre visibles les informations nécessaires à la mise en route d’un processus d’amélioration continue.

Cible du jalon

La cible visée est la suivante :

  • Un processus visuel et connu;
  • Un système en amélioration continue;
  • Un focus sur la qualité intégrée.

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.

Visualiser le processus

  • Représenter visuellement le processus;
  • Définir le point d’entrée et le point de sortie du processus actuel.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Communiquer les objectifs de la démarche.

X

X

X

X

Exposer les objectifs de la transparence.

X

 

 

 

Respecter et soutenir la transparence du système.

 

X

X

 X

Limiter le travail en cours (WIP)

  • Centrer l’alimentation autour d’un seul point explicite et visible;
  • 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

  • Implanter la pratique de flux tiré;
  • Suivre le temps de cycle.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Expliquer pourquoi et comment mesurer le temps de cycle.

X

X

 

 

Expliquer pourquoi et comment gérer le travail en flux tiré.

 

 

 

Expliquer comment travailler avec une équipe en flux tiré.

 

 

X

 X

Rendre les règles explicites

  • Identifier les types d’éléments de travail;
  • Identifier les catégories de service;
  • Formaliser une définition de prêt;
  • Formaliser une définition de terminé par étape du processus.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Comprendre les règles du système

X

X

 X

Identifier les cadences

  • Établir la cadence d’alimentation du système;
  • Établir la cadence de synchronisation du travail de l’équipe.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

S’entendre sur la mise en place d’une cadence d’alimentation.

X

X

Expliquer l’objectif d’une rencontre de synchronisation.

 X

 

 

Expliquer comment exécuter une rencontre de synchronisation en Kanban.

 X

 

 

 

Améliorer en continu

  • Introduire des rétrospectives;
  • Introduire une cadence de rétrospectives.
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Expliquer pourquoi et comment s’améliorer en continu.

X

 

 

 

Comprendre comment appuyer une équipe en amélioration continue.

 

 X

 

 

À suivre prochainement

Je vous invite à surveiller ExcellenceAgile.com durant les prochaines semaines car nous allons dévoiler les 2 prochains jalons, soit le jalon STABILISER et le jalon PROPULSER.

Nicolas Mercier
Valéry Germain

Les 3 états d’une rétrospective

(English Follows)

Il est clair pour plusieurs experts Agile/Scrum que si vous ne devez appliquer qu’un seul élément de Scrum, vous devriez choisir de faire les rétrospectives.  Cet acte simple et régulier de révision du processus et de la dynamique d’équipe est la fondation même de l’amélioration continue.  Cet événement important n’est toutefois pas simple à animer, car étant donné que les gens parleront de leurs interactions et du travail de tous et chacun, le Scrum Master devra aider le groupe dans le développement de leur écoute et de leur communication.

En assumant que vous faites déjà ou que vous pensez faire de rétrospectives (rétro) de façon régulière, votre équipe Scrum va fort probablement être dans l’un des 3 états suivants :

Bruit  /  Efficacité  /  Stagnation

Bruit

Toutes les équipes que j’ai suivies sont passées par ces trois étapes. Les deux premières rétros sont toujours dans un état de Bruit où,  pour la première fois, les gens ont la parole et peuvent défiler la liste de problèmes qu’ils gardaient pour eux.  À ce moment, on vous parlera de la couleur du tapis, du manque de stylos bleus et de la machine à café. C’est normal, et c’est un moment critique où les gestionnaires/leaders pourraient, en posant les mauvais gestes, bloquer les canaux de communication avant même qu’ils n’aient le temps de s’ouvrir.  Il est important d’accepter tous les commentaires, ou au moins de reconnaître le point de vue de chaque personne et la guider dans la résolution du problème.  

Efficacité

Avec des rétros régulières, l’équipe va rapidement observer la résolution des bloquants mis en lumière pendant ces rétros. Cette réalisation, combinée avec la réduction du ‘Bruit’, va pousser l’équipe vers un état Efficace.  Une fois dans cette mentalité, ils vont régulièrement identifier des points d’amélioration concrets qui vont aider l’équipe à comprendre l’importance de la boucle d’amélioration continue pendant qu’ils se résolvent systématiquement. Bientôt, la rétro est un événement attendu et le fait de négliger une rétro résulte en une sensation de déconnexion.

Stagnation

Comme Ed Catmull* a dit lors de sa présentation ‘Keep your crises small’ donnée à l’université de Stanford en 2007; ‘Le succès cache les problèmes’ et les gens on tendance à éviter de pointer des erreurs quand les choses vont bien.  Aussi, une fois que l’équipe passe au travers d’une série de rétros ‘Efficaces’, les membres de l’équipe peuvent avoir une baisse de motivation, alors que leurs idées d’amélioration deviennent de plus en plus difficiles à trouver et que les gains diminuent.  Quand cela se produit, la responsabilité de ramener l’équipe dans un état Efficace repose sur le Scrum Master.  Cela peut être fait de différentes façons, mais ma solution préférée, que j’utilise systématiquement afin de prévenir la chute vers un état de Stagnation, est d’utiliser de façon périodique une rétro pour améliorer le produit plutôt que le procédé.  Pendant ces ‘rétros spéciales’, je demande à l’équipe de trouver des points d’amélioration pour le produit en utilisant les mêmes plans de rétrospective utilisés dans les rétros normales.  En plus de rafraîchir la perspective sur les procédés, ce truc augmente aussi l’engagement de l’équipe envers le produit.

*Président des studios d’animation Pixar et des studios d’animation Walt Disney

Phillipe Cantin

The 3 Stages of a Retrospective

Many Agile/Scrum experts agree that if you are only going to apply one part of Scrum, you should choose the retrospective.  The simple and regular act of reviewing the team’s processes and dynamics is the foundation of continuous improvement.  However, that important event is complicated to animate, and since people will be talking about their interactions and each other’s work, the Scrum Master will have to help the group as they develop their listening and communication skills.

Assuming you are either doing or planning on doing regular retrospectives (retros), your Scrum Team will most likely be in one of the following 3 stages:

Noise  /  Effectiveness /  Stagnation

Noise

Every team I have followed went through those three stages. The first couple of retros are always in the Noise stage where, for the first time, people have the mike and are allowed to lay out the laundry list of problems they have on their mind.  In the midst of that meeting, you will hear about the carpet color, the lack of blue pens and the coffee maker. It is a normal and critical time where managers/leaders could, through the wrong actions, block communication lines before they had a chance to open. It is important to accept all the feedback, or at least acknowledge the point of view of every person and guide them in the problem resolution.

Effectiveness

With regular retros, the team will soon witness the pragmatic resolution of different pain points they brought up at their retros.  This realization combined with the reduction of the Noise will move the team toward an Effective state. Once in that mindset, they will regularly identify concrete improvement points that will help the team understand the importance of the continuous improvement loop as the points systematically get resolved. Soon, the retro becomes an expected event and skipping one creates a weird feeling of being out of touch.

Stagnation

As Ed Catmull* said in his ‘Keep your crises small’ talk at Stanford University in 2007; ‘Success hides problems’ and people have a tendency to avoid pointing out errors when things are going well.  Also, once the team goes through a string of Effective retros, members can hit a motivational low point as their improvement ideas get harder to find and the gains get smaller.  When that happens, it is the Scrum Master’s responsibility to bring the team back to an Effective state. It can be done in several ways but one of my go-to solutions, which I systematically use to prevent the team from slipping into the Stagnation state, is to periodically use one of the retros to improve the product instead of the process. During these ‘special retros’, I ask the team to find improvement points for the product using the same retrospective plans we use during normal retros.  On top of refreshing the process perspective, this trick has the added benefit of improving the team’s engagement with the product.

*President of Pixar Animation Studios and Walt Disney Animation Studios

Phillipe Cantin

L’auto-organisation et l’engagement

L’homme qui voue sa vie entière à effectuer quelques rares opérations simples, desquelles les effets sont peut-être toujours les mêmes ou très semblables, n’a pas d’occasion de pratiquer sa compréhension ou d’exercer son inventivité à trouver des opportunités à dissiper des difficultés qui ne surviennent jamais. Il perd naturellement, dès lors, l’habitude de telles pratiques et, généralement, devient aussi stupide et ignorant qu’il est possible à une créature humaine de devenir. La torpeur de son esprit le rend non seulement incapable de goûter ou supporter un parti dans quelque conversation rationnelle que ce soit ou de concevoir ne serait-ce qu’un sentiment généreux, noble ou tendre, mais aussi, en conséquence, de former un jugement juste concernant plusieurs, même des plus ordinaires, tâches de la vie privée.

source : Adam Smith « An Inquiry into the Nature and Causes of the Wealth of Nations »

Avoir du plaisir au travail, est-ce important? C’est le fondement même de la performance et de l’amélioration continue. L’auto-organisation des individus est un carburant puissant qui alimente la motivation, la créativité, le désir du dépassement et la recherche de l’excellence. En tant que conseiller Agile, je suis très sensible au développement du savoir-être dans mes équipes de travail. Voici 3 entreprises florissantes où l’auto-organisation est au cœur de leurs principes : PatagoniaValve et Buurtzorg. Un travailleur heureux en vaut 2 🙂

Des passionnés de Kanban

L’équipe de Facilité possède plusieurs passions pour tout ce qui touche de près ou de loin à Agile ou Lean, et l’une de ses passions est sans contredit Kanban.

C’est propulsés par cette passion que nous avons développé notre formation « Mise en place d’une équipe Kanban » et que nous avons initié notre partenariat avec Daniel Vacanti, entre autres pour ses formations Signature sur Kanban et sur les Métriques Avancés.

Comme tout bon passionné, nos neurones sont constamment en effervescence, ce qui nous a fait plancher sur la création d’une démarche d’implantation Kanban. L’idée était de reprendre ce que l’on enseigne dans nos salles de formation, dans nos conférences et chez nos clients afin de proposer une démarche pouvant appuyer une implantation de Kanban pour ceux qui se lanceraient dans ce projet.

Nous allons donc dévoiler cette démarche ici sur ExcellenceAgile.com au cours des prochaines semaines. Suivez-nous pour en profiter!

La démarche

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

jalons

3 jalons d’implantation

La démarche se décline en 3 grands jalons d’implantation:

  • INTRODUIRE – « Révéler le système »
    L’objectif de ce jalon est de rendre visible le système d’alimentation d’une équipe, l’état de l’ensemble du travail en cours et les règles et processus internes. Cette visibilité fournira l’information nécessaire à l’équipe et son écosystème (ses clients, ses parties prenantes et sa gouvernance) afin de mettre en place son processus d’amélioration continue, ce qui permettra d’optimiser la valeur générée par sa prestation de service.
  • STABILISER – « Stabiliser le système »
    L’objectif de ce jalon est d’amener l’équipe à opérer les changements nécessaires pour qu’elle puisse 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 Introduire et en stabilisant les facteurs générant de la variabilité, l’équipe pourra fournir des ententes de service fiables à ses clients.
  • PROPULSER – « Propulser le système »
    L’objectif de ce jalon est d’outiller l’équipe pour qu’elle soit en mesure d’optimiser son travail, ses processus et ses règles. Dans ce jalon, les conditions sont réunies afin de maximiser l’utilisation des métriques et des techniques de prédictibilité avancées.

 

 

6-pratiques

 

La démarche s’appuie sur les 6 pratiques de la méthode Kanban. Tel que défini dans le guide Essential Kanban Condensed de David J. Anderson et Andy Carmichael, les 6 pratiques représentent des activités destinées à opérer un ou plusieurs systèmes Kanban. Ces pratiques permettent de voir le travail et les politiques qui régissent le processus de travail et permettent également d’améliorer le tout de manière évolutive.

6-pratiques_2

 

roadmap

Un Roadmap de Gestion du Changement accompagne chacun des jalons. Ce roadmap oriente vers différents éléments à adresser en termes de gestion du changement lors de chacun des jalons. Les éléments composants le roadmap s’intéressent spécifiquement aux pratiques, outils et techniques composant une implantation Kanban. Le roadmap vient donc complémenter une stratégie de gestion du changement globale.

On décline les éléments sur 3 axes en fonction de la clientèle visée:

  • Clients;
  • Parties prenantes;
  • Équipe;
  • Gestionnaire.

tableau

 

À suivre prochainement

Je vous invite à surveiller ExcellenceAgile.com durant les prochaines semaines car nous allons dévoiler les 3 jalons au fur et à mesure.

Préparation Express / Démarrage de projet agile

Les pratiques Agiles les plus utiles sont souvent celles qui émergent sur le terrain, en collaboration avec ceux qui vivent le projet. J’ai eu la chance de le vivre dans le cadre de ma pratique. Lors de l’accompagnement de projets de différentes tailles, on m’a demandé d’épauler le démarrage rapide de petits projets Agiles dans une grande organisation de la fonction publique. Dans un environnement de cette ampleur, il est facile de blâmer la taille de l’organisation pour justifier la lenteur et le coût de démarrage de chacune des initiatives. Le printemps dernier, un directeur du côté client m’a demandé de transformer une initiative à faible budget en succès. Lors de ma pratique en clientèle, en collaboration avec des collègues internes, j’ai assemblé un amalgame d’ateliers existants et créé une démarche répétable pour les petits projets. Plusieurs privilégiés ont eu la chance d’expérimenter cet outil via des ateliers pratiques à l’Agile Tour 2016 de Québec (sous le nom d’architecture express).

Cette démarche a été utilisée à plusieurs reprises en environnement réel. Les types de projets possibles varient entre de nouveaux développements, des améliorations à un système existant, des intégrations d’un produit logiciel ou du développement sur un progiciel. Cette préparation de projet rapide se prête bien aux projets de quelques semaines à quelques mois. Afin de mener à bien la préparation, on vise normalement un noyau de leaders variant de 2 à 5 personnes pour animer des ateliers variant entre 5 à 12 personnes, et une réalisation Agile par la suite. Vous pouvez voir les détails dans notre section outils.

Ce genre de démarrage requiert une implication intensive de 1-3 jours dans un tour d’horizon en 10 ateliers. Par la suite, dépendamment du focus de l’équipe de préparation, une série d’ateliers de préparation (écriture de récits, modélisation Agile etc.) s’étalent sur 1 à 3 semaines. Une fois cette étape de préparation complétée, l’équipe de réalisation peut faire un estimé à haut niveau (ex: via une session murale) et ensuite se lancer en réalisation avec la méthode Agile de son choix.

Même les premières versions ont eu beaucoup de succès, chacune d’elles nous ayant permis d’en apprendre sur l’écosystème affaires et TI de l’organisation. L’outil peut sembler intimidant au premier regard, mais n’ayez pas peur de l’essayer, d’expérimenter et de démarrer vos projets dans une collaboration énergisante! Si toutefois vous souhaitez vivre cette démarche avec accompagnement, contactez-nous et il nous fera plaisir de vous appuyer dans son application.

Pour plus d’information sur la méthode: Éric Lessard

Pour plus d’informations sur notre offre d’accompagnement sur la Préparation Express: Christian Savard, Directeur