banner-kanban

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

1280px-wonderland_walker_5

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

team-386673

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 🙂

banner-kanban

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.

f-22-mur-du-son

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

Pourquoi avons-nous arrêté de faire des sprints de 3 semaines?

(English follows)

Quelle longueur devrait avoir nos sprints?  1, 2, 3 ou 4 semaines?  Toutes les équipes Scrum et les organisations Agiles se posent cette question et, dépendamment du contexte, certaines organisations peuvent laisser les équipes ou leur imposer un rythme standardisé. Regardons les deux côtés de la médaille afin de comprendre pourquoi les sprints de 3 semaines sont OK… jusqu’à ce qu’ils ne le soient plus.

La grosseur, ça compte

Prenons un petit détour pour expliquer comment les sprints courts donnent plus de contrôle à l’équipe Scrum pour adapter et guider le projet vers un atterrissage en douceur. Imaginez un projet de 4 mois.  Combien de points d’adaptation pouvons-nous avoir pendant cette période?  Si vous avez livré plusieurs projets Scrum, vous savez que les 2-3 premiers sprints servent au ‘décollage’ et à la stabilisation alors que les 1-2 derniers sprints servent à ‘atterrir’ et fermer le projet.  Sachant ceci, à moins que votre équipe de développement soit une bande de vétérans unis, un projet de 5 sprints ne donnera pas le temps à votre vélocité (d’effort) de devenir prévisible.   Une autre façon de calculer le nombre de points d’adaptation d’un projet Scrum est de retirer la première et la dernière planification de sprint.  Sans mesure précédente, la première planification n’adapte rien alors que la dernière planification est plutôt utilisée pour fermer les travaux et ne prendre aucun risque.  Si on regarde un projet de 4 mois, ceci ne donne que 2 points de contrôle pour des sprints de 4 semaines et 6 points de contrôle pour des sprints de 2 semaines.  Donc, des sprints courts, c’est mieux.

En défense de la liberté

La flexibilité de pouvoir choisir la longueur de sprint est un des avantages de Scrum.  Pour l’équipe Scrum, choisir et adapter cette variable fait partie de leur auto-organisation, permettant de balancer la grosseur des incréments avec la fréquence d’itération.

En défense de la standardisation

À l’autre bout du spectre, imposer un longueur de sprint a comme avantage de synchroniser les sprints, ouvrant ainsi une fenêtre d’opportunité pour le personnel flottant (ne faisant pas partie des équipes « noyau ») de transférer d’équipe.  C’est aussi un moment où l’avancement global peut être mesuré simultanément.  Ceci est particulièrement important pour comprendre l’avancement des projets/programmes composés de plusieurs équipes.

Comment avoir le meilleur des deux mondes?

En éliminant les sprints de 3 semaines

Si toutes les équipes limitent leur choix de longueur de sprint à 1, 2 ou 4 semaines, il est alors possible de synchroniser la fin de tous les sprints à la semaine #4.  Bien sûr, pour que cela fonctionne, certaines équipes devront ajuster leur cadence en ajoutant ou soustrayant une semaine à l’un de leurs sprints.  Une fois cette réinitialisation faite, les équipes auront un sprint synchronisé à toutes les 4 semaines.

Alors, à moins de vouloir synchroniser vos sprints, il n’y a pas de problème à faire des sprints de 3 semaines.  Sinon, ils deviennent le mal incarné.

 

Phillipe Cantin

 

Why did we stop doing 3-week sprints?

How long should our sprint be? 1, 2, 3 or 4 weeks? Every Scrum team and Agile organization will eventually ask that question. Depending on the context, some organizations will let the teams decide, while others will impose a standard pace.  Let’s take a look at both sides of the coin and explain why 3-week sprints are OK… until they are not.

Size matters

Let’s take a little detour to see how short sprints give more control points to the Scrum Team for adapting and steering the project toward a soft landing.  Imagine a 4-month project. How many points of adaptation can we have during this period?  If you have delivered many Scrum projects, you know that it takes 2 to 3 sprints to ‘take off’ and stabilize, whereas the last couple of sprints are used for landing and closing the project. Given that, unless your Development Team are a tight-knit band of veterans, a 5-sprint project will not give you enough time to gain a predictable effort velocity.  Another way of calculating the number of adaptation points in a Scrum project it is to remove the first and last sprint plannings.  By having no previous measure, the first planning is not adapting anything while the last planning is normally used to close things with zero risk. If we look at a 4-month project, it only gives you 2 points of control for 4-week sprints, and 6 points of control for 2-week sprints. Therefore, shorter is better.

In defence of freedom

The flexibility of being able to choose the sprint length is one of the many advantages of Scrum.  For the Scrum Team, choosing and adapting this variable is part of their self-organization, enabling them to balance the increment size with iteration frequency.

In defence of standardization

At the other end of the spectrum, imposing a sprint length has the advantage of synchronizing the sprints, which opens a window of opportunity where floating personnel (employees who are not part of a core team) can hop from one team to another.  It is also a moment where overall progress can be measured simultaneously. That is especially important when we want to be able to follow the progress of projects/programs composed of several teams.

How can we get the best of both worlds?  

By getting rid of 3-week sprints.

If all the teams limit their sprint length to 1, 2 or 4 weeks, it is then possible to synchronize the end of all the sprints at week #4.  Of course, some of the teams will have to adjust their sprint cadence by adding a week or subtracting a week from one of their sprints. After this simple ‘reset’, everybody will reach a synchronized sprint every 4 weeks.

So, unless you want to synchronize your sprints, 3-week sprints are totally fine. Otherwise, they are pure evil.

 

Phillipe Cantin

 

1738-600x420

Échec : le chemin le moins fréquenté

J’ai raté 9000 tirs dans ma carrière. J’ai perdu presque 300 matchs. 26 fois, on m’a fait confiance pour prendre le tir de la victoire et j’ai raté. J’ai échoué encore et encore et encore dans ma vie. Et c’est pourquoi j’ai réussi. – Michael Jordan

Je n’ai pas échoué, j’ai trouvé 10 000 solutions qui ne fonctionnent pas. – Thomas Edison

  • Est-ce qu’ils se sont sentis mal? OUI.
  • Est-ce qu’ils ont senti la pression de leurs pairs? Certainement.
  • Ont-ils voulu abandonner, revenir en arrière? Assurément.
  • Ont-ils appris de leurs échecs? Qu’en pensez-vous?

Lors d’un échec, est-ce que revenir en arrière est une solution pour essayer autre chose? Bien non! Car j’ai évolué, je ne suis plus le même. Je ne peux pas revenir dans l’état et l’écosystème d’avant, c’est impossible. Et pourtant, c’est ce que nous faisons tout le temps.

Essayer autre chose est-il vraiment garant d’un succès?

La phrase du gestionnaire « OK gang, on va essayer de faire du ABC » se résume dans la tête des gens : « Pis si cela ne marche pas, on va revenir comme avant. ». « Essayer », est-ce une façon d’annoncer un échec?

Voici un autre chemin possible :

  • Faire quelque chose;
  • Célébrer l’échec;
  • Faire une rétrospective, s’améliorer, se perfectionner;
  • Et revenir à la première étape.

Bref, le faire vraiment. Autrement, mais vraiment. Et cela jusqu’au jour où vous prendrez le succès à deux mains avec fierté, en regardant en arrière pour contempler tous ses alliés d’échecs qui vous ont aidé à grandir.

Je termine avec une phrase d’un vieux sage:

N’essaie pas ! Fais-le, ou ne le fais pas ! Il n’y a pas d’essai. – YODA

Tester du Legacy Code, mission impossible ?

Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code, aussi appelé Code Patrimonial. Ces problèmes surviennent notamment lorsque des équipes font un virage Agile et qu’on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que ça, car le système en question n’a pas été prévu pour des tests unitaires.
C’est ce qui nous a donné l’idée de monter une présentation en abordant le sujet avec les points suivants :
  • Description de quelques techniques pour nous aider à tester le Legacy Code.
  • Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler?
  • Quelques pratiques et outils afin de s’en prémunir autant que possible, au jour le jour.
Voici les disapositives utilisées:
Cette présentation a été donnée aux dates suivantes:
  • 10 Novembre 2016 – Beer And Learn (Québec)
  • 16 Novembre 2016 – Agile Tour Montréal
Si vous avez des questions ou besoin de plus amples explications, n’hésitez pas à m’écrire.
Karl Métivier
kmetivier@facilite.com

Notre matériel présenté à Agile Tour de Québec 2016

img_3597

Merci chers participants de l’Agile Tour pour votre fort intérêt envers le contenu proposé par Facilité !

Nous sommes flattés par l’engouement autour des conférences et ateliers Passez un test de la vue – outils visuels pour y voir clair présentée par Nicolas Mercier et Christian Savard, Architecture Express pour petits projets par Frédéric Paquet et Éric Lessard et Mon Agilité est plus grosse que la tienne de Jean-René Rousseau. 

 Des ateliers ou conférences comme celles que nous vous avons présentés ne sont un succès que si les participants s’investissent dans l’activité.  Merci à notre auditoire, nous espérons que vous avez tiré des bénéfices à la hauteur de votre implication durant nos séances.

Vous n’avez pas pu assister à notre atelier puisqu’il était complet ou vous avez manqué une de nos conférences ? Nous serions heureux de vous offrir une séance privée ! N’hésitez pas à manifester votre intérêt à Facilité (christian.savard@facilite.com) pour une offre sur mesure. Parlez-en à vos gestionnaires !

Pour ceux qui ont assisté à nos présentations ou ateliers et qui aimeraient consulter le matériel présenté ou obtenir plus d’informations, notez que celui-ci a été mis en ligne ici. Vous y retrouverez les documents de présentation originaux ainsi que les coordonnées des présentateurs afin de leur poser vos questions.

Au plaisir de vous outiller dans vos projets !

Ne copiez pas le modèle Spotify!

crop380w_boy_cheating_on_test

J’imagine qu’on se rejoindra sur le principe, particulièrement dans le contexte de transformation Agile, que « one size does not fit all ». Même si la culture actuelle de nos clients les invite à vouloir standardiser leur façon de faire Agile, en tant que coach il faut être vigilent pour s’assurer que leur niveau de standardisation est suffisamment macro et adaptable pour permettre aux équipes de faire des choix relatif à leur contexte.

J’ai donc bien aimé cet article paru sur InfoQ  cette semaine qui nous invite à ne PAS copier le modèle de Spotify, modèle largement acclamé par la communauté Agile.

https://www.infoq.com/fr/news/2016/10/no-spotify-model

Bonne lecture, et comme dirait nos amis de DAD  « Context count and choice is good »  (sourire)