Votre méthode a déjà des rétrospectives. Elle les appelle des rapports de leçons apprises.

Le Waterfall a-t-il des rétrospectives ?

Oui, sous un autre nom. PRINCE2 nomme « apprendre de l'expérience » comme l'un de ses sept principes¹. Il tient un registre des leçons, créé pendant la phase de démarrage dans une activité appelée Capture des leçons précédentes, et un rapport de leçons est généralement inclus dans chaque rapport de fin d'étape². Si vous exécutez PRINCE2, vous tenez déjà une revue structurée à la fin d'une étape et vous notez ce que vous avez appris. C'est une rétro.

On vous a probablement dit le contraire. L'idée que les équipes traditionnelles « ne font pas de rétros » est l'une des affirmations les plus répétées et les moins examinées du marché des outils de livraison. Elle ne survit pas au contact des manuels. Ce qui manque aux équipes traditionnelles n'est pas la pratique. Ce sont les outils.

Pensez à l'endroit où un rapport de leçons va réellement. Quelqu'un l'écrit à une limite d'étape, généralement sous pression temporelle, généralement après que les détails intéressants se sont déjà estompés. Il est joint à un rapport de fin d'étape, classé sur un lecteur partagé, et lu par à peu près personne au début de l'étape suivante. L'apprentissage est capturé puis abandonné.

Pour être juste, les équipes agiles ne sont pas manifestement meilleures à cela. Un tableau de rétro rempli de notes autocollantes est photographié et abandonné tout aussi souvent. Aucun groupe n'a résolu le problème de faire en sorte que la leçon du mois dernier change le comportement du mois prochain. La différence est que l'un de ces groupes a passé quinze ans à construire des logiciels pour cela, et on a dit à l'autre que le logiciel n'était pas pour lui.

Quelle que soit votre méthode, PRINCE2, un processus de jalons interne, ou quelque chose que votre organisation a assemblé sur deux décennies, la forme est la même. À la fin d'une phase, vous examinez ce qui s'est passé et vous l'écrivez. La question ouverte n'est jamais de savoir si vous le faites. C'est de savoir si quelque chose arrive à ce que vous avez écrit.

À quoi correspondent les cérémonies agiles dans la livraison traditionnelle ?

Chaque cérémonie agile a un équivalent traditionnel, et la plupart des équivalents sont venus en premier. Les rétrospectives correspondent aux revues de leçons. Les mêlées quotidiennes correspondent aux rapports de statut. Les démos correspondent aux revues de jalons de validation. L'estimation correspond aux chiffres déjà présents dans votre structure de répartition du travail. Le vocabulaire est différent. Le travail est le même, et vous le faites déjà.

La colonne de gauche est un vocabulaire que vous n'avez pas choisi et dont vous n'avez pas besoin. La colonne du milieu est un travail que vous faites déjà, selon un calendrier fixé par quelqu'un d'autre, généralement dans un modèle. Simyl Flow automatise la colonne du milieu. La colonne de gauche n'est que ce que les boutons disent.

Vous pouvez utiliser le produit pendant un an sans jamais prononcer le mot « sprint » à voix haute.

Simyl Flow exige-t-il des sprints de deux semaines ?

Non. Un sprint dans Simyl Flow est une plage de dates nommée avec un début et une fin. Aucune durée n'est imposée nulle part dans le produit. Une phase de six semaines, une version trimestrielle ou un jalon dont la date de fin a déjà glissé deux fois se comportent tous de la même manière, car chaque métrique est calculée à partir des horodatages sur vos tickets et commits plutôt qu'à partir de la longueur du conteneur.

Cela compte plus que cela n'en a l'air. Si un outil suppose deux semaines, cette hypothèse se propage dans tout ce qui suit : les graphiques, les comparaisons, les seuils qui décident de ce qui compte comme lent. Les outils construits de cette façon ne conviennent vraiment pas à une organisation basée sur des phases, et la réponse raisonnable est celle que vous aviez déjà.

Ici, le conteneur est une étiquette sur une plage de dates. Appelez-le Phase 3. Appelez-le Version 4.2. Appelez-le Durcissement T3. Le temps de cycle est toujours l'intervalle entre le début et la fin d'un ticket. Le taux de bugs est toujours un ratio. Aucun ne devient dénué de sens parce que votre phase a duré onze semaines au lieu de deux.

Que pouvez-vous mesurer sans changer la façon dont votre équipe travaille ?

Connectez votre gestionnaire de tickets et votre dépôt de code, et six métriques apparaissent sans que personne n'assiste à une nouvelle réunion : Vélocité, Temps de cycle, PR fusionnées, Commits, Taux de bugs et Travail non planifié. Chacune est dérivée des enregistrements que votre équipe crée déjà dans le cours de son travail. Aucune session d'estimation, aucune mêlée quotidienne et aucune rétro n'est requise pour produire l'une d'entre elles.

C'est le point d'entrée honnête, et c'est celui que nous recommanderions même si vous étiez enthousiaste à propos des cérémonies. Personne n'a à apprendre un nouveau vocabulaire. Personne n'a à être convaincu d'une philosophie lors d'une réunion du lundi. Les données sont déjà dans Jira et GitHub, là, décrivant comment votre livraison se comporte réellement.

Les cérémonies existent dans le produit. Vous pouvez les activer quand vous voulez, ou jamais. Une équipe qui connecte deux systèmes et n'ouvre rien d'autre obtient toujours une tendance de temps de cycle, ce qui est plus que ce que la plupart des organisations traditionnelles ont aujourd'hui.

Ce qui tend à surprendre les gens, c'est où l'attente apparaît. Pas dans le développement. Dans les transferts entre phases, dans l'écart entre « code terminé » et « environnement de test disponible », dans la semaine qu'un ordre de modification a passée à attendre une signature.

Que ne vous dit pas la vélocité?

La vélocité vous dit combien de travail a été fermé dans une période. Elle ne peut pas vous dire si ce travail est resté fermé, combien de temps il a attendu avant que quelqu'un ne le prenne en charge, ou ce qu'il a coûté pour sortir. Une phase peut atteindre exactement son objectif de vélocité et quand même livrer des défauts qui rongent la phase suivante. Le chiffre a la même apparence dans les deux cas.

Ce n'est pas un argument contre la vélocité. C'est un chiffre véritablement utile, et le suivre vous place devant les nombreuses organisations qui ne suivent rien du tout. Le problème n'est pas que la vélocité soit fausse. C'est que la vélocité est généralement seule.

Imaginez deux phases avec une vélocité identique. Dans la première, le travail a avancé régulièrement, la révision a pris un jour, et presque rien n'est revenu. Dans la seconde, tout est resté en révision pendant neuf jours, a été livré dans une rafale la dernière semaine, et un tiers est revenu sous forme de défauts en moins d'un mois. La vélocité enregistre ces deux phases comme équivalentes. Le temps de cycle, le taux de bogues et le travail non planifié ne le font pas.

Le travail non planifié est généralement celui qui frappe le plus fort dans une organisation basée sur les phases. C'est le chiffre qui explique finalement pourquoi le plan a dérapé alors que personne dans l'équipe n'a rien fait de mal. Vous avez planifié pour le travail que vous connaissiez. Quelque chose d'autre est arrivé. La plupart des processus de planification n'ont aucun moyen de montrer cela, donc le dérapage est attribué aux estimations, ou aux gens, et la même chose se produit à la phase suivante.

Vous pouvez voir comment les six dimensions s'articulent sur la vue d'ensemble de l'efficacité.

Nous ne menons pas une arnaque à long terme

Il n'y a pas de phase deux où nous vous demandons d'adopter Scrum.

La mesure fonctionne parce que vos phases ont des dates et vos tickets ont des horodatages. Elle ne fonctionne pas à cause du cadre imprimé sur le mur. Si vous connectez vos systèmes, ne tenez jamais de rétro dans ce produit, et n'estimez jamais un seul élément dedans, il vous dit quand même si la livraison devient plus rapide ou plus lente et où l'attente se produit.

Nous préférons vous être utiles tel que vous travaillez déjà plutôt que d'attendre que vous deveniez quelqu'un d'autre d'abord.

Pas un entonnoir de conversion. Un outil de mesure.

Foire aux questions

Devons-nous adopter l'agilité pour utiliser Simyl Flow?

Non. Le produit lit les dates de votre outil de suivi des problèmes et les horodatages de votre dépôt. Ni l'un ni l'autre ne dépend d'un cadre. Les équipes qui exécutent des phases, des jalons de validation, ou un processus interne sur mesure obtiennent les mêmes métriques que les équipes qui exécutent des itérations de deux semaines, parce que les enregistrements sous-jacents sont les mêmes dans les deux cas.

Simyl Flow exige-t-il des sprints de deux semaines?

Non. Un sprint est une plage de dates nommée avec un début et une fin, et aucune durée n'est imposée. Une phase, un jalon, une version, ou un trimestre fonctionnent tous. Les métriques sont calculées à partir des horodatages sur les tickets et les commits, donc la longueur du conteneur ne change pas la façon dont elles sont calculées.

Nous utilisons PRINCE2. Où cela s'intègre-t-il?

Votre rapport de fin d'étape est l'endroit naturel. PRINCE2 place déjà une revue des leçons à cette frontière, donc les fonctionnalités de rétrospective ont un endroit évident où vivre si vous les voulez un jour. Vous n'avez pas besoin de les utiliser. Connectez vos outils et les métriques de livraison fonctionnent quel que soit le processus qui les enveloppe.

Nous ne tenons pas de rétrospectives. Est-ce quand même utile?

Oui. Le temps de cycle, le taux de bogues, le travail non planifié, les PR fusionnées et les commits sont tous dérivés de vos tickets existants et de l'historique du code. Ils ne nécessitent aucune réunion et aucune facilitation. Les rétrospectives ajoutent un endroit pour agir sur ce que les chiffres montrent, mais les chiffres arrivent que vous en teniez une ou non.

Quelle est la configuration minimale?

Un outil de suivi des problèmes ou un dépôt de code. Connectez-le, choisissez une plage de dates qui correspond à la façon dont vous planifiez déjà, et les métriques se remplissent à partir de l'historique. Rien ne change dans la façon dont votre équipe travaille cette semaine-là, ce qui est le but.

Sources