Architecture / Préparation express à Agile Québec

Merci d’être venus en grand nombre assister à notre présentation sur la préparation express qui a eu lieu hier à la mensuelle d’Agile Québec.

Nous sommes heureux d’avoir partagé avec vous cette méthode énergisante et efficace pour démarrer vos projets Agile.

Nous vous invitons chaleureusement à essayer ces outils, nous donner vos commentaires et raconter vos histoires.

Si vous avez manqué la présentation ou aimeriez revoir le matériel, il est disponible ici.

Si vous avez des questions ou avez besoin de plus d’informations, contactez l’équipe de Facilité!

Le livre blanc de notre démarche Kanban

Une démarche simple pour vos équipes en quête de performance !!

DemarcheKanban

Comme vous avez pu le découvrir depuis notre premier blog de cette série sur Kanban, nous sommes des passionnés recherchant toujours la solution la plus adéquate, la plus efficace pour les équipes que nous accompagnons, supportée par la manière la plus simple et directe pour y arriver. C’est le fruit de notre expertise et de notre expérience que nous partageons aujourd’hui sous la forme d’un livre blanc que vous êtes libres d’utiliser dans vos équipes, de partager autour de vous et d’expérimenter pour vous inspirer !!

Comme des guerriers sans repos, nous avons continué d’enrichir notre démarche après la publication des blogs. Ainsi, vous trouverez dans ce livre blanc des listes de points de validation permettant de mesurer l’atteinte des objectifs de chaque jalon et d’identifier vos angles morts !!

Bonne lecture… et bon succès dans votre implantation Kanban !!

livre

Attention au glissement du risque

(english follows)

En gestion de projet, atteindre la prédictibilité est un élément clé du succès et son bloquant majeur est le risque. Pour contenir ce dernier lors de la préparation d’un projet, nous prenons grand soin de gérer la quantité de risque inclue dans la portée. En ne voulant rien laisser au hasard, nous augmentons ainsi nos chances de succès en travaillant sur ce risque en début de projet. Lorsque que le risque est résolu ou sous contrôle, nous pouvons enfin tourner notre attention vers la prédictibilité.

N’est-ce pas bizarre alors de voir des ajouts volontaires de risques supplémentaires pendant le projet?

Ceci peut s’expliquer via un comportement de compensation du risque poussant les gens à faire moins attention lorsqu’ils se sentent en sécurité. Cet effet, combiné avec la pression de livrer un maximum de fonctionnalités de qualités, peut nous pousser à prendre des risques supplémentaires en remplacement de ceux qui sont résolus. J’appelle ceci “remplir sa dette de risque”, étant donné que les membres de l’équipe agissant de cette façon sont similaires aux gens qui utilisent leur crédit de façon impulsive. Au même moment, pour certains membres du projet, une baisse de pression sur le risque peut être interprétée comme un signe de perte d’opportunité. Pour résoudre ceci, on doit se concentrer à maintenir un effort constant et soutenable, alors qu’au même moment, on doit accepter une oscillation dans le niveau de risque alors que le focus fait des allers-retours entre le développement et le déploiement.

Le risque est sournois, car il fait toujours partie du développement logiciel, nous désensibilisant ainsi de sa présence et de son importance et aussi parce qu’il prend deux formes : le risque connu, qui peut faire partie de la planification, et les risques inconnus, qui nous surprendront sur le chemin. Plusieurs de ces risques inconnus seront bloquants, nous forçant ainsi à investir un temps précieux pour les résoudre alors que, et nous devrions prendre avantage de ce fait, nous avons le choix d’accepter, gérer ou, plus particulièrement, rejeter les risques connus.

Livrer la vision en résolvant les risques engagés devrait donc toujours surpasser l’ajout de risque additionnel.

Phillipe Cantin

Beware of Risk Creep

When managing a project, achieving predictability is a key element of success and one of its major impediments is risk. To curb this problem while preparing for a project, we take great care, managing the amount of risk accepted in the scope. Not willing to leave anything to chance, we further improve our odds by tackling this risk early in the project which, once removed or under control, clears the way for predictability.

How funny then, to see new risks being purposefully added during a project production.

One reason explaining this is the Risk Compensation behavior, when people tend to be “less careful if they feel more protected”. This effect, combined with the pressure to deliver a maximum of quality features, can drive us to take on new risks as the existing risk is removed. I call this “Maxing out the risk” since team members acting this way are similar to people feeling compelled to max out their credit. At the same moment, for some people, a drop of pressure on risk can be interpreted as a sign of lost opportunity. To resolve all this, we must concentrate on maintaining a constant and sustainable effort level while, at the same time, accepting an oscillation in the risk level as the focus goes back and forth between development and release.

Risk is a sneaky thing as it is always a part of software development, desensitising us to its presence and importance. It is also sneaky as it comes in two shapes: the known risks, which can be part of the planning, and the unknown risks, which will surprise us along the way. We don’t have a choice but to deal with the unknowns [risks] as they pop up here and there during the project, and we should take advantage of this fact. We have a choice to either accept, manage or, especially, reject known risks.

Shipping the vision while resolving the engaged risks should always trump the addition of new risk.

Phillipe Cantin

Propulser le système au-delà de ses limites connues !

image2017-3-6_15-32-11.png

Propulser 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, puis le second : STABILISER.

Cette semaine, nous vous amenons au dernier jalon : PROPULSER.

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 pour ainsi être en mesure d’augmenter la valeur d’affaires livrée à sa clientèle.

Dans ce jalon, les conditions sont réunies afin de maximiser l’utilisation des métriques et des techniques de prédictibilité avancées qui permettent de contrôler l’impact des contraintes internes et externes.

Optimisation fine

image2017-3-28_21-41-49.png

L’assistant chimiste au célèbre professeur :

Professeur, est-ce le moment d’ajouter 3 ml de potassium dans la solution, comme hier ?

L’éminent savant de s’écrier :

Surtout pas, malheureux ! Hier, la température de la pièce était un degré plus basse…

Aujourd’hui, si nous ajoutons plus de 1,5 ml de chlorure de potassium, le laboratoire risque d’exploser !!

Une fois que l’on connait bien son système, on doit agir dessus en optimisation fine.

Lorsque l’on comprend son environnement, on peut en absorber les éléments de variabilité petit à petit dans le système pour en diminuer l’impact.

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 le 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 :

  • Priorisation par la valeur
  • Processus en optimisation
  • Prévisibilité basée sur des métriques avancées

Visualiser le processus

  • Optimiser le processus
  • Élargir la portée du système (en amont et/ou en aval)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

S’approprier le processus

X

 

 

Gérer le système et le travail, plutôt que les équipiers

 

 

Élargir la portée du système

 

 

 X

Limiter le travail en cours (WIP)

  • Maximisation des limites de travail en cours (WIP)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Faire évoluer les valeurs de WIP afin de maintenir le niveau de service

X

 

 

 

Optimiser le flux de travail

  • Analyser l’efficacité du flux (Flow Efficiency Diagram)
  • Planification à l’aide des simulations de Monte Carlo
  • Analyse des sources de blocage (Blocker Clustering)
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Faire la guerre aux bloquants

X

 X

 

 

Identifier les temps d’attente et optimiser le système (Flow Efficiency)

 X

 

 X

Prévoir le futur avec la méthode de Monte Carlo

 X

 

 

 

Comprendre les nouvelles ententes de service basées sur les données probabilistes (Simulations Monte Carlo)

 

 

 X

 

Rendre les règles explicites

  • Priorisation par la valeur
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Comprendre, définir et respecter la valeur définie par le client

X

 

Exprimer la valeur des éléments de travail et prioriser en fonction de celle-ci

 

 

 X  

Identifier les cadences

  • Cadencer les livraisons
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Comprendre les besoins afin de livrer au moment optimal pour le client

X

 X

 

S’impliquer pour assouplir les contraintes qui freinent les cadences de livraison

 

 

 

Comprendre les cadences de livraison implémentées par l’équipe

 

 X

 X

Améliorer en continu

  • Prioriser l’amélioration à travers un carnet d’amélioration
  • Découpler la cadence d’amélioration et faire de l’amélioration en continue
  • Utiliser des katas d’amélioration
  • Identifier les sources de gaspillage
  • Instaurer une culture de Kaizen
GESTION DU CHANGEMENT

Équipe

Gestionnaire

Client

Partie Prenante

Mettre de l’avant les initiatives d’amélioration continue et mesurer l’impact des changements

X

 

 

 

Encourager les actes de leadership et d’auto-organisation de l’équipe

 

 X

 

 

Impliquer dans l’amélioration continue

 

 X

 X

À suivre prochainement

Lorsque votre équipe aura atteint les objectifs de ce jalon, elle maitrisera un grand ensemble de pratiques et d’outils qui lui permettront de maintenir un système stable, prévisible et en optimisation continue.

Pour vous remercier de nous avoir suivi tout au long de cette série de blogs sur notre démarche Kanban, nous vous offrirons prochainement LE LIVRE BLANC DE LA DÉMARCHE KANBAN de FACILITÉ.

Nicolas Mercier
Valéry Germain

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

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