2017-01-23 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

2016-03-17 Christian Savard

Rétrospective sur la collaboration

Récemment, je devais tenir une rétrospective dont le sujet principal était la collaboration entre trois équipes. On parle régulièrement de la collaboration au sein d’une équipe, mais force est de constater que la collaboration inter-équipes est un sujet qu’on aborde moins souvent.

J’ai donc parcouru internet à la recherche d’idées dans l’espoir que la rétrospective que j’allais tenir porte ses fruits.

Je suis tombé sur un article de blog publié par Renzo Venini sur le site de Scrum Alliance. Dans son article, M. Venini présentait une méthode basée sur des souhaits et des offres pour finalement converger vers des actions. Je vous laisse lire l’article original si vous souhaitez en savoir un peu plus sur sa technique.

Très intéressé par sa technique, j’ai tenté une approche afin que les équipes identifient leurs souhaits en considérant d’autres axes que ceux qu’ils emploient habituellement.

En me basant sur le Team Trust Canvas élaboré par Alexey Pikulev, j’ai créé un canvas identifiant les axes de collaboration inter-équipes.

J’ai détaillé ma version de la technique de rétrospective dans la section outils du site. Je vous invite à consulter la page correspondante par ici.

2016-03-15 Louis-Philippe Carignan

L’engagement en Kanban vs Scrum

Je lis actuellement l’excellent excellent excellent livre de Daniel Vacanti, Actionable Agile, Metrics for Predictability, que vous pouvez acheter sur Leanpub.com.

J’ai adoré cette citation à propos de l’engagement de la méthode Kanban versus Scrum.

Kanban approach to commitments is very different than, say, Scrum. Scrum commitments are made at the sprint level. At the beginning of a sprint, a team commits to getting some number of stories finished by the end of the sprint. That commitment is based on more upfront estimation and planning.

In a flow-based approach, teams commit at the individual work item level. Once an item is pulled into the process a commitment is made as to when that item should be done. That commitment is based more on measurement and observation rather than planning and estimation.

Ce que j’aime de plus en plus dans la méthode Kanban, c’est l’effort mis pour comprendre son système à l’aide d’observations et de mesures pour le rendre prévisible.

Et voici un exemple d’un engagement selon Vacanti pour un item de travail qui passe dans un système Kanban:

We expect this item to flow all the way through the process and exit in 14 days or less with an 85% probability of success.

Pour ceux et celles qui se demandent comment je fais pour prédire cet engagement en Kanban, je vous réfère à l’ensemble d’outils de Focused Objectives sur GitHub dont le fichier Excel Single Feature Forecaster.xlsx qui nous génère un tableau:

Dans le cadre de sa série de formations Signature, Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti, pionnier de la méthode, sera à Québec pour expliquer comment mettre en application cette méthode. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle.

2015-12-01 Louis-Philippe Carignan

La rétrospective positive

Selon le guide Scrum, la rétrospective de sprint est « une occasion pour l’Équipe Scrum de s’inspecter et de créer un plan d’amélioration qui sera mis en place au cours du Sprint suivant. »

Au début de ma carrière de Scrum Master, je suivais cette définition assez rigoureusement. Cette rencontre était employée pour identifier nos problèmes et les régler. Cependant, en progressant dans ce rôle, j’ai remarqué que les gens devenaient fatigués d’être constamment mis au défi pour trouver des pistes d’amélioration. En creusant de plus en plus, on rencontrait des problèmes organisationnels ou professionnels qui ne pouvaient tout simplement pas être résolus. Cela minait l’humeur des gens. Curieusement, lorsque les commentaires restaient positifs à la rétrospective, l’équipe se dressait plus facilement un plan d’actions. Lorsque les gens se sentaient bien et fier d’eux-mêmes, ils travaillent plutôt à s’améliorer davantage.

J’ai aussi découvert que les rétrospectives positives se déroulaient mieux lorsqu’on utilisait un artéfact pour démarrer les conversations. Simplement démarrer la rétrospective en demandant aux participants de parler des aspects positifs du sprint était bizarre. Il fallait mettre la table, voir casser la glace.

Pour orienter les conversations positives, j’utilise habituellement deux outils: le calendrier niko-niko et le mood board. Le calendrier niko-niko est un outil bien documenté où on demande à chaque membre de l’équipe d’inscrire son état d’esprit général à chaque jour du sprint. On peut alors effectuer une rétrospective sur le niveau de bonheur de l’équipe à la fin du sprint.

Dans l’éventualité où un tel outil n’a pas été mis en place, je considère le mood board comme étant une bonne alternative pour démarrer des conversations positives. En somme, le mood board est un graphique où l’axe des X est la ligne du temps et l’axe des Y est le niveau de bonheur à travers le temps. Puisque ceci est un outil très scientifique, on peut remarquer que le niveau de bonheur maximal est le gros bonhomme Sourire dans la photo qui suit:

Il y a aussi des couleurs différentes pour illuster le parcours de chaque membre de l’équipe. Lors de ce projet, nous avons substitué plusieurs joueurs, d’où le début des courbes à différents moments. Une fois leurs courbes tracées, je demande aux participants dans la salle d’identifier des moments positifs en lien avec cet artéfact.

Dans la photo ci-haut, on remarque que le niveau de bonheur est à son plus bas aux itérations 5 et 6. Bien qu’on aurait pu s’enlisser dans les raisons qui nous amenées là, l’objectif de la rencontre était de rester positif. Les membres de l’équipe se sont donc mis à parler d’événements positifs qui les ont fait passer à travers cette période. Jean-Sébastien (ligne verte) a parlé de la venue positive de Martin #2 (ligne mauve). Et les conversations ont continué à être positives pour le reste de la rencontre.

Au final, aucun plan d’actions tangible n’est sorti de cette rencontre. Seulement de bonnes appréciations envers les membres de l’équipe. Et des fois, la reconnaissance par les pairs est ce qu’il faut discuter lors de la rétrospective d’équipe.

2015-09-01 Jean-René Rousseau

Rôles et responsabilités: voir au delà de Scrum

L’enjeu entourant la définition des rôles et responsabilités est systématiquement un enjeu majeur lorsqu’on implante l’agilité dans une organisation. Et plus l’organisation est bâtie sur un modèle de spécialiste, plus il y a de la confusion. En effet on sait que Scrum nous propose simplement 3 rôles: PO, SM et Équipier. Sachant que certains cadres méthodologiques traditionnels nous propose une vingtaine de rôles différents on peut imaginer la confusion pour « l’analyste en sécurité » ou « l’architecte en modélisation de données » et autres rôles très spécialisés. En fait, même la simple distinction programmeur et analyste peut parfois être difficile à démêler pour une équipe novice en agilité ou la culture de la co-responsabilisation n’est pas au rendez-vous.

Pour vous aider à appuyer les discussions autour des rôles, je vous propose trois listes de rôles Agile qui vont un peu plus loin que Scrum tout en restant aligner avec les principes directeurs de l’agilité, donc sans tomber dans l’excès de la spécialisation.

2015-08-13 Nicolas Mercier

Scrum de Scrums

Les équipes travaillant en mode Agile sont plus que familières avec la mêlée quotidienne ou le daily Scrum. C’est le point d’inflexion entre deux journées de travail pour une équipe Scrum ou Scrumban. C’est le moment où l’on se réunit pendant 15 minutes, debout, souvent autour d’un tableau, qu’on se synchronise en équipe, qu’on soulève nos bloquants et qu’on s’engage sur un plan de match pour les 24 prochaines heures. Lire la suite