L’Agilité sans tout casser

La transition vers l’Agilité est souvent perçue comme l’annonce d’une grande vague de changement.  Ça peut être le cas, mais ce n’est pas la seule option.  Même si les Scrum Masters sont souvent vus comme les porte-étendards des valeurs Agiles, ils ne sont pas nécessairement les seuls à pouvoir amener l’organisation à un autre niveau.  Si Scrum s’est présenté comme une révolution dans le monde des TI, Kanban se présente comme l’évolution.

Évolution vs dérangement

Ceux qui ont déjà entrepris une transformation Agile basée sur Scrum se rappelleront sûrement à quel point la structure initiale de l’organisation peut-être distante des ingrédients essentiels de la méthode.  Des termes comme Sprint, Carnet (Backlog), Scrum Master, Responsable de produit (Product Owner) se sont ajoutés au vocabulaire.  Le contrat implicite de protection de l’itération, la notion d’incrément livrable, récit utilisateur etc… Passer à Scrum résulte très souvent en un grand dérangement dont l’objectif est de dynamiser l’organisation vers une philosophie orientée sur la version de produit fini.

Dans un autre ordre d’idée, Kanban quant à lui nous invite à un démarrage plus progressif. La maxime « Start with what you do now » (Commencez avec ce que vous faites aujourd’hui) donne le ton.  La mise en place Kanban débute par l’identification de différents aspects de la situation actuelle, se doter d’un outil de suivi et d’une démarche d’amélioration.  Les équipes peuvent assimiler les changements initiaux et le reste de la transformation n’est qu’évolution.

Partenaires non-Agiles dans l’organisation ou hors organisation

Un autre défi, lors de transitions Agiles, réside dans le fait qu’une organisation ne peut changer en totalité en un instant.  Le changement se fait de façon progressive.  De nombreux départements non-Agiles, des clients ou des fournisseurs continuent d’alimenter les équipes et consommer leurs livrables.

Les notions d’itérations protégées créent de l’irritation à certains des contributeurs, donneurs d’ouvrages ou collaborateurs.  Il en va de même pour l’engagement.  Les calendriers de ces groupes ne sont pas nécessairement calqués sur les dates de début/fin de sprints.  Les contributions externes peuvent parfois faire la différence entre le succès ou l’échec d’un objectif de sprint.  Un glissement de quelques jours peut suffire à faire échouer ladite itération…

Dépendances non-cadencées

Au delà de la méthode de travail des partenaires, certaines contributions ne peuvent pas toutes être cadencées.  Si l’équipe dépend d’une pièce de matériel développée par une organisation ou même dans un autre pays.  Si un expert est difficilement disponible et que nous devions réagir dès qu’il a du temps pour soutenir l’équipe… Toutes ces réalités emprisonnent les équipes Scrum entre l’arbre et l’écorce.

Kanban offre une flexibilité qu’on ne retrouve pas dans les itérations de Scrum.  Le travail en flux continu devient très avantageux si des changements de priorités peuvent survenir dans la réalité quotidienne des équipes.  Si une tâche est bloquée par un expert ou un fournisseur qui a pris du retard de son côté, le reste du travail continue à couler de façon fluide dans le système et l’équipe continue de livrer.

Et la suite?

Kanban ou Scrum.  2 excellents outils.  Comme un marteau ou un tournevis.  Dans le bon contexte et avec la bonne connaissance de ce qu’ils peuvent offrir, une organisation peut à la fois avoir des équipes Scrum et Kanban sous le même toit, dans le même écosystème Agile.

Une belle façon d’élargir vos horizons serait de vous procurer les incontournables suivants:

guide-cover-sm

Titre: Essential Kanban – The Condensed Guide

LivreActionableAgile

Titre: Actionable Agile – Metrics for predictability

51deom263vl

Titre: Kanban

Une équipe peut apprendre Kanban de manière autodidacte grâce aux livres les plus connus ou encore faire appel à des experts.  Il se trouve d’ailleurs que dans le cadre de sa série de Formations Signature, Facilité Informatique organise la première formation sur la méthode Kanban à Québec, les 5 et 6 mai prochains. Daniel Vacanti, pionnier de la méthode, sera en ville pour expliquer comment mettre en application celle-ci. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Le Manifeste du BDD

BDD Manifesto

On voit des manifestes un peu partout ces jours-ci. Étant un passionné de BDD (Behavior-Driven Development), je me disais que cela serait pertinent d’en faire un à ce sujet.

L’objectif, pour moi, est de pouvoir résumer rapidement la technique avec des exemples, et surtout de faire prendre conscience que le BDD n’est pas une histoire d’outils avant tout. En fait, l’outil peut même s’avérer facultatif et arriver dans un deuxième temps.

Bref, afin de comprendre rapidement ce qu’est le BDD, voici mon manifeste :

Combler le fossé de communication entre le domaine d’affaires et le développement
plus que
Développer sans connaitre les objectifs et la vision affaires

L’équipe de développement est responsable de la qualité
plus que
C’est la responsabilité du testeur

Se valider fréquemment à l’aide d’exemples et d’explorations
plus que
Découvrir les bogues plus tard dans le processus de développement

Obtenir une documentation vivante des spécifications de notre système
plus que
Avoir une documentation lourde et coûteuse  à mettre à jour

Avoir des communications efficaces, rapides et avec des perspectives différentes
plus que
Travailler de manière hiérarchique et en silos

Établir des scénarios et des exemples concrets, accessibles et abstraits
plus que
Établir des scripts de tests détaillés et complexes

Automatiser l’exécution des tests fonctionnels
plus que
Réaliser manuellement tous les tests fonctionnels

Qu’en pensez-vous ?

Vos commentaires et critiques sont très appréciés afin d’améliorer ce manifeste.

Vous voulez en savoir davantage ? Il y aura une formation pour le côté fonctionnel et technique « Introduction au BDD » bientôt chez notre partenaire AFI.

Autres manifestes:

Références BDD:

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.

AtelierCollaboration

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

CanvasCollaboration

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.

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.

Un Scrum Master en position d’autorité: une option à ne pas écarter

J’ai trouvé le dernier billet de Mike Cohn fort intéressant car il adresse un enjeu avec lequel je suis constamment confronté sur le terrain.  Que faire si le Scrum Master est aussi en lien d’autorité avec son équipe ?

common advice in the Scrum community is that a team should never, ever report to their Scrum Master

Le piège le plus souvent cité est la possibilité que l’équipe ne soit pas très transparente envers son manager. De plus, en situation de stress, le manager se sentant imputable des résultats de l’équipe pourrait être tenté par le micromanagement. Ceci étant dit, qu’enseigne-t-on aux gestionnaires Agiles?  Quelle est la principale qualité du manager Agile?

Mener votre organisation comme si vous n’aviez aucune autorité » (Kan Higashi)

Une équipe a-t-elle  avantage à cacher de l’information à son manager?  Comment peut-il aider et soutenir l’équipe s’il n’a pas accès à la bonne information?

With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue

If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it.

Le rôle de Scrum Master aurait-il été créé pour camoufler une dysfonction de notre système de gestion traditionnel?  Est-ce qu’on a « tassé » les gestionnaires dans les transformations Agiles, ou est-ce qu’on les accompagne individuellement dans la transformation de leur style de leadership?  je crois qu’il faut faire la même chose avec les chefs d’équipe et chargés de projet, les aider à ajuster leurs postures pour supporter des équipes auto-organisées, les aider à devenir des leaders 3.0, les aider à devenir des Scrum Masters.

With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world.

And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.

Après tout, ne valorisons-nous pas les individus davantage que le processus (et les descriptions de rôles qui viennent avec) ?

Blog original

When I first started doing Scrum, I was what we’d call today the team’s ScrumMaster and product owner. But we didn’t have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both. I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.

I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP — but I should not have been both at the same time to the same team. (And to be clear, everything I’ll write here is going to apply to any personnel manager, whether that’s a manager, director, vice president or even CEO.)

While I don’t think it’s desirable to have team members also have a reporting relationship to their ScrumMaster, I don’t think it is always horrible. Much depends on the person who is filling both roles. One of the common arguments against a manager as the team’s ScrumMaster is that team members will become reluctant to raise issues. For example, a programmer who is behind on a task will not be willing to say so in the daily scrum if his or her manager is also the ScrumMaster. That’s simply not true. With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue. If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it. If the wrong person is in place, there are lots of problems.

But it’s time to stop defining processes to prevent problems and create workarounds for the troublesome people in the organization. Instead, assume the right people are in place and then work to create a culture that puts the right people in place. With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world. And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.Doing that will help your team succeed with agile.

Mike Cohn

The Tyranny of the timebox

Le titre révèle tout. Dans sa présentation en 2014 intitulée « 10 years of Kanban – What have we learned », David J. Anderson rappelle le concept du « Tyranny of the timebox » proposé à Agile 2009.

KanbanTyrannyTimebox

Plus loin dans sa présentation, Anderson mentionne que la méthode Kanban a passé le chasm en 2012.

KanbanCrossingTheChasm

Pour ceux qui connaissent le livre Crossing the chasm, ce terme veut dire qu’une technologie est passée du stade d’adoption à celui d’être mise en place par la majorité de la population.

Et vous, où êtes-vous par rapport à votre adoption de la méthode Kanban dans vos équipes?

Dans le cadre de ses 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 sera à Québec pour expliquer comment mettre en application cette méthode. Je vous invite chaleureusement à profiter de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle.

Monte Carlo, le CH et Kanban

Dans l’édition du 19 février du journal La Presse, on y publiait un article à propos des chances du Canadiens de Montréal de faire le tournoi printanier. On pouvait y lire qu’Alain Bonnier, physicien consulté par le journal, donnait très peu de chances aux Canadiens à se rendre en série.

Alain Bonnier estime à 3,9 % les chances du Tricolore de participer au prochain tournoi printanier.

Il s’agit de la 94e prédiction de la part de ce physicien, qui a effectué sa première prédiction pour La Presse en janvier 1989. Or, 92 de ses 93 premières prédictions se sont avérées !

Pour arriver à cette prédiction, M. Bonnier s’est servi d’un outil mathématique qui se nomme les simulations de Monte Carlo:

C’est un calcul de probabilités par la méthode de Monte-Carlo, explique M. Bonnier au téléphone. On part des résultats de tous les matchs depuis le début de la saison. À partir de ça, on simule le reste de la saison. J’ai donc simulé 30 000 fois le reste de la saison. À la fin des 30 000 simulations, on compile les résultats pour voir le pourcentage de chances de participer aux séries.

Les simulations de Monte Carlo sont utilisées dans une multitude de domaines pour aider à prendre une décision. Dans son excellent livre Actionable Agile- Metrics for predictability, Daniel Vacanti mentionne cela:

It has proved a useful tool in all kinds of fields like nuclear physics, oil and gas exploration, finance, insurance, etc. Given the uncertainty in knowledge work it seems strange that our industry has been rather late to the Monte Carlo game.

Sachant que la méthode Kanban utilise le diagramme de flux cumulatifs pour visualiser l’historique de notre système Kanban, les experts Kanban se tournent vers les simulations de Monte Carlo pour prévoir avec un pourcentage, comme pour les Canadiens, les probabilités de date de livraison d’un item de travail. Grâce aux outils de Focus Objectives, on peut exécuter ces simulations de Monte Carlo.

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 celle-ci. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle!

Rétrospective en 4 actes

Ce mercredi 24 février, une équipe de 5 coachs vous a présenté, dans le cadre des conférences mensuelles d’Agile Québec, l’atelier « Rétrospective en 4 actes ».

Dans cet atelier, Nicolas, Valéry, Martin, Frédéric et Christian ont mis à profit tout leur talent d’acteur (on le sait, c’est discutable!) et ont tenté de vous démontrer comment votre choix de type de rétrospective et la façon de l’animer influenceront la résultante et l’orientation du plan d’action.

Vous avez assisté à la conférence (ou pas) et aimeriez avoir un peu plus d’informations sur les enjeux et la façon de les aborder dans le cadre d’une rétrospective? L’équipe a mis en ligne un outil afin de vous aider. N’hésitez pas à utiliser la zone de commentaires afin de le bonifier pour le bénéfice de tous.

En espérant que vous ayez apprécié l’exercice!

Si vous souhaitez consulter le matériel présenté, le voici:

Les derniers articles de Mary Poppendieck

Mary Poppendieck, une de mes auteures préférées en TI, a rédigé deux excellents articles depuis les 6 derniers mois. Je trouve que ses articles valent toujours le temps que l’on y consacre. Je vous les propose si vous avez un bon 30 minutes de libre devant vous.

Friction

Dans cet article, Mary parle de friction dans toutes sortes de domaines relatifs au TI. La deuxième moitié de l’article est principalement centrée sur la friction dans les gouvernements. J’ai fait ressortir quelques extraits et me suis permis de mettre en gras certains passages:

Uber is among the largest of a new crop of startups – investor Chris Dixon calls them full stack startups – that bypass incumbents and reinvent the entire customer experience from start to finish with the aim of making it as frictionless as possible. Full stack startups focus on creating a world that works the way it should work, given today’s technology, rather than optimizing the way it does work, given yesterday’s mental models.

Large companies have the same full stack of capabilities as startups, but these capabilities lie in different departments and there is friction at every department boundary.

Code bases created and maintained by full stack teams are much more resilient than the large and calcified code bases created by the project model precisely because people pay attention to (and change!) the internal workings of “their” code on an on-going basis.

Broadly speaking, these fiascoes are caused by the process most governments use to procure software systems – a high friction process with a very high rate of failure.

One country that does not have an IT fiasco story is Estonia, probably the most automated country in the world. A few years ago British MP Francis Maude visited Estonia to find out how they managed to implement such sophisticated automation on a small budget. He discovered that Estonia automated its government because it had such a small budget.

The UK government changed – seemingly overnight – from high friction processes orchestrated by procurement departments to small internal teams governed by simple metrics. Instead of delivering “requirements” that someone else thinks up, teams are required to track four key performance indicators and figure out how to move these metrics in the right direction over time.

It turns out that when governments move from the old mental model to the new mental model, many of the things that were considered “good” or “essential” in the past turn out to be “questionable” or “to be avoided” going forward. These are

  • Requirements generate friction.
  • Handovers generate friction.
  • Organizational boundaries generate friction.
  • Estimates generate friction.
  • Multitasking generates friction.
  • Backlogs generate friction.

Teams need only three lists: Now, Next, and Never. There is no try.

Once upon a time, governments assumed that obtaining software systems through a procurement process was essential, because it would be impossible to hire the people needed to design and develop these systems internally.  They were wrong. They assumed that having teams scattered about in various government agencies would lead to a bunch of unconnected one-of systems. They were wrong. They were afraid that without detailed requirements and people accountable for estimates, there would be no governance. They were wrong. Once they abandoned these assumptions and switched to the low friction approach pioneered by Estonia, governments got better designs, more satisfied consumers, lower cost, and far more predictable results.

Lien vers l’article complet: Friction

Five World-Changing Software Innovations: How They Happened

Dans cet article, Mary raconte les 5 innovations que nous n’avons pas suivi pendant que nous parlions d’Agilité depuis 15 ans. Celles-ci sont:

  1. The Cloud
  2. Big Data
  3. Antifragile Systems
  4. Content Platforms
  5. Mobile Apps

Voici quelques citations pour vous donner le goût de lire l’article:

Concernant le Cloud:

The idea that infrastructure is context and the rest is core helps explain why internet companies do not have IT departments. For the last two decades, technology startups have chosen to divide their businesses along core and infrastructure lines rather than along technology lines. They put differentiating capabilities in the line business units rather than relegating them to cost centers, which generally works a lot better. In fact, many IT organizations might work better if they were split into two sections, one (infrastructure) treated as a commodity and the rest moved into (or changed into) a line organization

À propos du Big Data, Mary raconte la petite histoire du Big Data depuis 2001:

Netflix, which has a good number of reliability engineers despite the fact that it has no data centers.

En ce qui a trait au Content Platforms:

Three entrepreneurs – Chad Hurley, Steve Chen, and Jawed Karim – tried out an interesting use case for video: a dating site. But they couldn’t get anyone to submit “dating videos,” so they accepted any videos clips people wanted to upload. They were surprised at the videos they got: interesting experiences, impressive skills, how-to lessons – not what they expected, but at least it was something. The YouTube founders quickly added a search capability. This time they got the use case right and the rest is history.

Video is the printing press of experience.

À propos des Mobile Apps:

 By 2014 (give or take a year, depending on whose data you look at) mobile apps had surpassed desktops as the path people take to the internet.

The nature of mobile apps changes the software development paradigm in other ways as well. As one bank manager told me, “We did our first mobile app as a project, so we thought that when the app was released, it was done. But every time there was an operating system update, we had to update the app. That was a surprise!

Lien vers l’article complet: Five World-Changing Software Innovations: How They Happened

Des formations Agiles plus techniques ça existe?

Vous êtes développeurs, architectes et vous avez l’impression que la majorité des formations Agiles ne parle que de processus, valeur, culture, gestion, ….?

Vous vous dites « Me semble qu’à la base de l’Agilité il y a l’excellence technique? »

Hé bien vous avez raison!  C’est pourquoi nous avons pris un soin jaloux de couvrir l’ensemble des perspectives reliées à l’Agilité  lors du développement de notre cursus de formation.  Et vous savez quoi?  Février vous offre deux belles opportunités pour aiguiser vos réflexes d’ingéniéries Agile avec :

Le développement piloté par les tests (TDD)  le 5 février à Québec et;

Architecture organique Agile et ouverte les 8 et 9 février à Québec.

Faites vous former par nos conseillers experts en techniques d’architecture et en développement Agile et saisissez la vague Agile !