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

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

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