Une revue de sprint n’est pas une démo

(English follows)

Faites-vous des revues de sprint, démo ou un mix des deux? Le faites-vous de la mauvaise façon? Ne pas le savoir peut être coûteux. Par exemple: sentez-vous que vous devez sacrifier des fonctionnalités pour préparer vos revues de sprint ou vos démos? Malheureusement, plusieurs équipes Agile le font. Voici comment éviter ce piège en comprenant la différence entre ces deux événements.

Lire la suite

Passer des fausses certitudes aux doutes adaptables

(English follows)

Avant de donner un GO à un nouveau projet ou lors du suivis d’un projet en cours, les parties prenantes et organisations exigeront toujours d’avoir un minimum de confiance dans la planification. En méthodes traditionnelles (e.g. en cascade), ceci se reflète souvent par un besoin de savoir exactement ce qui va être fait, quand ce sera fait et à quel prix. Comme nous le savons maintenant, peu importe la précision de ces prédictions initiales, la réalité en constant changement du projet a tendance à rendre le plan inapproprié. Dans de telles cultures de développement, minimiser les écarts face au plan est plus important que de maximiser la valeur du projet.

Lire la suite

Planifiez-vous pour gagner ou pour ne pas perdre?

low-bar

(English follows)

Imaginez que, en tant que membre d’une équipe Agile, vous tentez quelque chose de nouveau afin d’augmenter la qualité de votre produit et que ça ne fonctionne pas. Qu’est-ce qui fait le plus mal? Devoir re-planifier et essayer de nouveau ou devoir rendre des compte sur cet échec?

Imaginez maintenant que vous, toujours en tant que membre d’une équipe Agile, devez faire des choix difficiles dans la gestion de votre temps suite à des imprévues ayant décuplé la grosseur de l’une de vos tâches. Qu’est-ce que vous regretteriez le plus? Ne pas pouvoir augmenter la qualité du produit ou avoir manqué votre estimation?

Voyez-vous où nous allons avec ceci?

Lire la suite

Les 7 flexibilités du backlog Agile

(English follows)

Comment un backlog Agile peut-il survivre à la tempête d’un projet tout en livrant une solution cohésive? En grande partie, ceci vient de ses multiples niveaux de flexibilité. La vision d’un projet, décrite dans un tel backlog, devient adaptable à plusieurs, ou même à la majeure partie, des changements auxquels un projet fait face. Regardons ces options de flexibilité par ordre d’impact croissant sur la portée et la qualité.

Lire la suite

C’est mieux de fonctionner

(English follows)

Le développement logiciel est déjà difficile et, pourtant, face à un choix entre une solution technologique difficile ou une sécuritaire, nous choisissons souvent l’option risquée, souvent accompagnées de bénéfices supérieurs.  Les raisons d’affaires derrière ce choix sont claires, mais que se passe-t-il avec l’engagement de l’équipe face à ce défis supplémentaire?  Regardons de plus près comment, en tant que membre d’une équipe ou en tant qu’équipe dans une organisation, notre engagement change radicalement dépendamment si nous partageons cette charge avec nos gestionnaires.  Ici, l’attitude du leader Agile est clé.

Pour illustrer ceci, regardons une scène du film Moneyball où Billy Bean, le directeur général d’une équipe de baseball, a une conversation avec Peter Brand, un jeune homme avec la folle idée de choisir en utilisant seulement les mathématiques.  Dans la scène, Billy et Peter observent la première pratique de leur équipe nouvellement formée de joueurs indésirables. Peter, clairement stressé par l’ampleur du risque qu’ils prennent, regarde les joueurs, alors que Billy vient vers lui et lui dit: “C’est mieux de fonctionner!” À ce moment, l’attitude de Peter passe d’un bon stress à une peur intense avec la réalisation que Billy est prêt à lui donner le blâme en cas d’échec.  Heureusement, Billy donnait dans l’humour et Peter peut donc retourner dans son état de bon stress, mais toutefois plutôt confus par le sens de l’humour noir de son patron.

Peter, sans une organisation créant un espace sécuritaire pour faire l’essai de sa théorie, n’aurait jamais travaillé sur son idée.   Aussi, Billy aurait pu dire à Peter de mettre en place son idée, tout en le prévenant qu’il serait (Peter) responsable en cas d’échec.  Dans ce scénario, Peter aurait soit refusé l’emploi, soit fait trop de compromis pour éviter l’échec.  En réalité, dans notre histoire, Billy avait vraiment créé un espace sécuritaire dans lequel Peter pouvait prendre des risques, vivre des échecs, apprendre de ces derniers et prendre de nouveaux risques.  Bien que Peter soit responsable de la réalisation de son idée, Billy est clairement imputable d’avoir pris cette nouvelle direction. Cette collaboration, basée sur la confiance, les engage vers un but commun.

Créer un espace pour votre équipe demande un bon effort.  Se joindre à eux dans cet espace est le vrai défi.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

This better work

Software development is hard enough, yet, when faced with the choice between a difficult or a safe technological path, we tend to choose the riskier one which often comes with better results.  The business reasons behind such a choice are obvious, but what about the team’s engagement toward this extra challenge?  Let’s take a particular look at how, as a team member or as a whole team inside an organisation, our commitment will change dramatically whether or not we are sharing the load with our leadership.  Here, the Agile leader’s attitude is key.

To illustrate this, let’s look at a scene from the movie Moneyball where Billy Bean, a baseball team general manager, is having a conversation with Peter Brand, a young guy with the crazy idea of selecting players using only math.  In the scene, Billy and Peter are witnessing the first practice of their newly formed team composed of unwanted players. Peter, clearly stressed by the huge risk they are taking, is observing the players as Billy Bean walks up to him and says : “This better work.”  At this moment, Peter’s mood changed from healthy stress to pure fear with the realization that Billy was ready to blame him personally if the plan fails.  Luckily, Billy was only joking and Peter could return to his healthy stress, now combined with the knowledge of his boss’s dark sense of humor.

Peter, without an organization creating a safe space to test his theory, would have never fully tried his idea.  Also, Billy could have initially told Peter to implement his idea while warning him that he (Peter) would be held responsible in case of failure.  In this scenario, Peter would have either not accepted the job or over-compromised in order to avoid failure.  In the actual story, Billy did create a safe space for Peter to take chances, fail, learn and try again.  Also, even though Peter is responsible for the implementation of his idea, Billy is clearly accountable for the decision of trying this new approach. This collaboration, based on trust, engages both of them in the same goal.

Creating a safe space for your team takes effort.  Standing in that space with them is the real challenge.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

Astéroïdes – un vrai jeu Agile!

En 1979, Atari lançait le jeu Asteroids… un vrai jeu Agile!

L’utilisation des métaphores et des analogies est une technique de coaching efficace et bien connue.  Elle permet de déplacer une personne de son environnement de travail vers un environnement autre, mais familier, et de discuter de concepts tout en réduisant les « oui, mais ça marche pas comme ça ici ». En voici une qui permet d’expliquer un grand nombre de concepts Agile dans un ensemble cohérent: Lire la suite

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é!

Mes notes suite au cours de Daniel Vacanti

danielvacanticlassroom
Avertissement

Ce billet a la pure intention de vous inciter à suivre les formations Intro Kanban et Kanban Avancé de Daniel Vacanti qui se tiendront à Montréal et Québec à la mi-novembre.

Si vous croyez tout savoir à propos de Kanban (comme moi dans l’temps), je vous encourage à lire ce billet jusqu’à la fin. La formation de Daniel Vacanti en mai dernier m’a permis de devenir meilleur dans ma mise en application de Kanban.

J’aimerais donc vous partager les notes que j’avais conservées lors de a formation:

  • If work is piling up, ask the customer to stop.
  • A shorter cycle time gives a shorter feedback loop.
  • Achieve self-improvement in your team by using cycle time. 
  • Spending more time estimating, means spending less time doing the work.
  • To get more done, work on fewer things at once.
  • Focus on the workflow versus the roles.
  • WIP is the biggest influencer of cycle time and throughput.
  • How much will it cost? as a function of how long it will take.
  • Kanban board = Reality board
  • The key insight of Lean is that inventory is perishable. It is not an asset. It is a liability.
  • Policies are helpful when it comes to handling variability.
  • When work is piling up, move the WIP down. 
  • The flow is more predictable if we can throttle the input and output of my Kanban system.
  • The backlog column doesn’t have a WIP Limit, so it’s not considered part of the Kanban system.
  • An expedite process kills your predictability. You have to set the bar high to get into the Expedite lane.
  • Rename the Expedite Lane, switch to Flow Destroyer Lane.
  • Stair steps on CFD are indicative of batch work.
  • 11-12 dots with a good management of WIP Limit to have a good scatterplot.
  • Drive out uncertainty by doing the work.
  • Queue replenishment meeting = Sprint planning.
  • Handoffs is the way known to create columns.
  • 2-tier Kanban board: Workflow within workflow.
  • Bigger epics are sagas, legends and bibles.

Si certaines phrases vous paraissent floues ou incompréhensibles dans la liste précédente, c’est peut-être un signe qu’il reste certaines zones à explorer dans votre connaissance Kanban. Personnellement, je crois que vous avez le meilleur prof Kanban, Daniel Vacanti, pour vous aider à grandir avec cette organisation du travail.

Les 10 meilleurs citations du livre de Daniel Vacanti

danielvacanti

Après avoir lu l’excellent excellent excellent livre Actionable Agile – Metrics for Predictability de Daniel Vacanti, j’aimerais vous partager les 10 meilleures citations du livre.

1. Delay is the enemy of flow.

2. Remember that being predictable is not completely about making forecasts. The bigger part of predictability is operating a system that behaves in a way that we expect it to.

3. Kanban cannot work because there are no commitments. Nothing could be further from the truth. It is just that the approach to commitment is very different than, say, Scrum.

4. The first thing to know about variation is that it will always exist.

5. Think about all the time you have wasted in your life doing estimation. Think about all the time wasting in « pointless » debates of whether a story is a two points or three points. Using these percentiles is a means to get rid of all that. Measuring to get an SLA allows us to adopt a much lighter approach to estimation and planning.

6. If a team follows all of the principles presented in this book, then the SLA can be used as a substitute for many upfront planning and estimation activities.

7. Use your Scatterplot’s percentiles to collaborate with your customers in choosing a Service Level Agreement (SLA) for your process.

8. Predictability is the ability to make a quantitative forecast about a process’s future state.

9. A forecast is a calculation about the future completion of an item or items that includes both a date range and a probability.

10. Whenever uncertainty is involved then a probabilistic approach is necessitated.

11. The older a work item gets, the greater chance it has of aging still more.

12. The second reason is that CFDs (Cumulative Flow Diagram) are for looking backward.

Je sais. Il y en a 12 finalement. Honnêtement, j’ai pris plus de 50 notes dans cet excellent excellent excellent livre. Je me suis arrêté après 12 mais j’aurais pu facilement vous les beurrer ici, vous auriez trouvé ça trop long pis seriez retournés sur Facebook regarder des photos de chats.

By the way, Vacanti sera au Québec dans la semaine du 14 novembre pour donner ses cours Kanban. Le 14 novembre, il donne le cours Kanban Avancé à Québec. Et les 17 et 18 novembre, il sera à Montréal pour donner son cours Intro Kanban. Des formations incroyables à ne pas manquer pour toute personne qui désire monter en compétences avec cette approche.

Bonne lecture!

Les Octas… WoW !

ChDmVNNUoAEonfA

Nous avons ouvert le bureau de Québec il y a maintenant bientôt 10 ans.  À ce moment, l’Agilité était une rumeur à Québec, peut-être même une légende.  Le genre d’histoire qu’on ne sait pas trop s’il faut y croire ou pas.  On en parlait un peu mais personne ne savait vraiment ce que c’était.  Cependant, presque tous s’entendaient pour dire qu’il était impossible d’implanter ces concepts dans les grandes organisations.

Facilité s’est établi à Québec avec comme objectif de faire les choses différemment, d’innover, de créer et de changer les façons de faire.  Immédiatement, les principes Agiles nous ont attirés.  Nous nous sommes donc investis dans cette aventure depuis le tout début de notre histoire.  Au départ, les gens nous trouvaient « weird », ils nous jugeaient même.  Mais c’était notre vision et personne ne pouvait nous arrêter.  Sur notre chemin, nous avons trouvé des conseillers super-héros qui se sont joints à nous pour penser le changement et nous avons eu le privilège de partager cette vision avec des clients précurseurs.

Aujourd’hui, nous sommes en nomination aux Octas pour notre mandat de transformation Agile à Revenu Québec en collaboration avec Pyxis.  Oui oui, à Revenu Québec…oui oui, en Agile!  Et oui oui, dans la catégorie « Transformation des processus organisationnels».  Le simple fait d’être en nomination est une immense victoire pour nous.  En plus de bien travailler, on nous dit, d’une certaine façon, qu’on est vraiment en train de changer les choses et ça, croyez-moi, ça vaut beaucoup.

Merci à tous les artisans de ce projet, merci à notre gang de super-héros crinqués, merci à notre client, Revenu Québec qui fait une job de feu pour nous permettre de penser les projets TI autrement.  Merci à ceux qui y ont cru et merci à ceux qui y croient.  À suivre… le 2 juin.

Allez VOTER maintenant! La période de votation se déroule du 9 au 28 mai !

Jeff #proud #agile #teamdefeu #FaciliteQc