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

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:

MonteCarloSimulation

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.

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.

Lire la suite

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