Adaptation de Scrum — Retour d’expérience 2/7

(English follows)

Dans le deuxième article de cette série, nous allons expliquer pourquoi une hiérarchie a été mise en place dans les équipes Scrum, pourquoi cette pratique s’applique dans plusieurs contextes et, pour finir, comment elle peut s’aligner avec le cadre Scrum.

L’objectif de cette série de blogues est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires. Voici la liste des articles de cette série et les liens des articles déjà publiés :

  1. Mise en contexte.
  2. Il y a une hiérarchie dans l’équipe Scrum (cet article).
  3. Plusieurs équipiers ont une spécialisation.
  4. Les changements, en milieu de Sprint et impactant l’objectif de sprint, sont acceptés.
  5. Les projections ne sont pas basées à 100 % sur l’empirisme.
  6. La décision d’annuler un Sprint n’est pas prise seulement par le PO.
  7. Des personnes externes à l’équipe Scrum peuvent influencer la planification de Sprint.

Métier, organisation et leadership

Il est très rare que tous les membres d’une équipe agile soient des experts, vétérans ou séniors. La plupart du temps, on retrouve un mélange de juniors, intermédiaires et séniors qui, ensemble, cumulent « toutes les compétences nécessaires »[1] à la réalisation des items du carnet de produit. Mais qu’est-ce que ça veut vraiment dire « toutes les compétences nécessaires » pour une équipe agile? Selon mon expérience[2], les compétences nécessaires sont composées de deux parties : l’autonomie métier et l’autonomie organisationnelle.

Lire la suite

Adaptation de Scrum — Retour d’expérience 1/7

(English follows)

L’objectif de cette série d’articles de blogue est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires.

Introduction

Même si l’on respecte un cadre (ou une approche) Lean-Agile, la simple application de certaines pratiques plutôt que d’autres crée souvent une mésentente entre praticiens et praticiennes. Cette mésentente est décuplée s’il est suggéré de sortir du cadre. Comme exemple, j’ai choisi Scrum, car c’est le cadre Agile avec lequel j’ai le plus d’expérience, bien que j’applique aussi Kanban, Lean-Flow and SAFe.

Lire la suite

Retrouvez nos experts aux Agile tours Québec et Montréal !

Les Agile tours de Québec et Montréal arrivent à grands pas et comme chaque année, nos experts québécois contribuent fortement à faire de ces évènements les grands rendez-vous agiles de l’année. Scrum, SAFe, l’amélioration continue, la gestion de la qualité, les flux de valeur et l’agilité organisationnelle : voici la palette très étendue des sujets que nous allons aborder avec vous, dans la salle ou derrière votre écran !

Lire la suite

Continuons d’évoluer, révisons notre utilisation des points de récits utilisateurs !

Relisez le guide Scrum. Il n’y a pas de notion de vélocité ou de points de récits utilisateurs. Ce fait, qui m’a été rappelé récemment par un collègue, m’a permis de réaliser les multiples biais injectés dans les fondamentaux Scrum et Agile pour répondre à des besoins de métriques.

Amusez-vous à lire cet article.

L’un des biais les plus flagrants est, pour ce billet, la notion de point pour un récit.

“Working software is the primary measure of progress.” – Manifeste Agile

Lire la suite

Ma critique du guide Scrum

Cette semaine, j’ai choisi le guide Scrum édition novembre 2017 de Ken Schwaber et Jeff Sutherland. Une lecture courte (22 pages) et très intéressante sur le sujet d’un « cadre de travail pour résoudre des problèmes complexes d’adaptation, tout en livrant de manière productive ». Je l’ai lu en détail et je me prête au jeu de l’analyser comme s’il avait été écrit récemment.

Un mot sur l’auteur

Mon expérience du Scrum est très limitée. J’ai lu le guide Scrum pour la première fois en diagonale cette année. Ma formation académique est technique et mon expérience professionnelle est essentiellement du côté de la gestion de projet en mode chaotique.

J’explore depuis récemment (2010) le Lean Management, le Kanban et la gestion quantitative. Je lis beaucoup sur l’Agilité depuis les débuts du manifeste, mais j’ai surtout exploré Extreme Programming du temps où je produisais encore de la valeur pour mes clients. Toute opinion comprise dans ce texte est un reflet de ce cheminement.

Lire la suite

MVP (Produit Minimum Viable), si simple et si confus à la fois !

En équipe, vous êtes en train de faire votre plan de livraison durant la phase de préparation d’un projet X. Celui-ci est basé sur vos cas d’utilisation ou encore de vos histoires, et lorsqu’est venu le temps de déterminer votre MVP, votre PO vous indique que son produit minimum viable (MVP) constitue la livraison de l’ensemble des fonctionnalités.

Vous lui faites alors remarquer que l’essence même de l’Agilité est de piloter par la valeur, et non par le plan. Ceci implique de rendre l’investissement et le temps de développement fixe, tout en laissant la latitude d’estimer la portée qui nous permettra possiblement de faire émerger le produit minimum viable.

Votre PO vous mentionne alors que le demandeur a émis des objectifs (sur lesquels la portée a été basée) et que, pour être viable, il doit tous les rencontrer, donc il doit tout livrer!

Lire la suite

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

Avez-vous l’impression que l’agilité a atteint un plateau dans votre organisation?

Une amertume perdure chez certains leaders Agiles : une impression que l’agilité ne va pas au bout de ses promesses et qu’il y a encore beaucoup de place à amélioration. Avez-vous cette impression?

2001 a vraiment marqué un tournant dans l’histoire du développement logiciel avec la parution du manifeste Agile (agilemanifesto.org). À l’époque certains la voyaient simplement comme une mode passagère qui s’estomperait avec le temps. Aujourd’hui, 16 ans plus tard, l’Agile est plus présente que jamais et est maintenant utilisée dans la plupart des organisations qui cherchent à augmenter l’efficience de leurs activités de développement logiciel et s’étend même à d’autres secteurs d’activités.

Malgré ce succès, je constate qu’une amertume perdure chez certains leaders Agile : une impression que l’agilité ne va pas au bout de ses promesses et qu’il y a encore beaucoup de place à amélioration. Avez-vous cette impression ? Croyez-vous que l’utilisation des approches Agiles a atteint un plateau dans votre organisation ? Plusieurs facteurs peuvent expliquer ce phénomène et nous nous attarderons ici sur les trois principaux, soit :

  • Une utilisation des approches Agiles localisée aux équipes de développement.
  • Un déploiement de l’Agilité appuyé seulement par Scrum.
  • Une inattention à l’impact culturel du changement provoqué par l’Agilité.

Lire la suite

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

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