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

Mesurer l’agilité

(English follows)

Êtes-vous agile ? Que dire de votre équipe ou de votre organisation ? Une approche populaire pour répondre à cette question est de « mesurer » le niveau d’agilité par le biais d’une liste de contrôle contenant des actions et conditions agiles. Une fois cette liste complétée, on peut malheureusement être tenté de l’utiliser pour séparer les agilistes des non agilistes.

Mesurer l’agilité en se concentrant sur les actions et les conditions du contexte est semblable à mesurer les compétences d’un alpiniste selon sa position sur la montagne. Face à une nouvelle montagne, l’alpiniste d’expérience doit commencer au bas, faire son chemin vers le haut et s’adapter à l’environnement. De sa perspective, plusieurs types de terrain ne seront probablement pas rencontrés et donc plusieurs techniques de grimpe ne seront pas utilisées. Il va de soi que l’inventaire de techniques utilisées ne nous donne de l’information que sur le chemin parcouru, mais pas beaucoup sur l’ensemble de la montagne et encore moins sur l’alpiniste.

Alors… que peut-on mesurer ?

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

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

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

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

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