De grandes fonctionnalités et de longs délais signifient que vous avez un diagramme de Gantt, pas une feuille de route
0 0
Read Time:7 Minute, 34 Second


6Q.AgileRoadmap
Plusieurs de mes clients ont des difficultés internes sur la façon de voir en interne l’avenir du produit. Les équipes souhaitent utiliser une approche agile afin d’intégrer l’apprentissage. Les managers veulent des feuilles de route rigides. Pourquoi? Parce que les managers veulent « savoir », les équipes vont tout livrer.

Cependant, les gestionnaires créent une feuille de route similaire à l’image ci-dessus. Cette feuille de route a de grandes fonctionnalités et de longs « délai ». (Remarquez comment toutes les entités se terminent sur une limite de quart ?)

Les gestionnaires ont créé un diagramme de Gantt comme une image, pas une feuille de route. Les managers pourraient même penser que cette feuille de route reflète une approche agile. Il n’y a rien dans cette feuille de route qui soit agile. Les managers pensent qu’ils ont besoin de « tout » au lieu d’utiliser le peu de réflexion pour créer un produit que les clients vont adorer.

Que pouvez-vous faire?

Plusieurs choses, et aucune d’entre elles n’inclut le fait de dire à vos gestionnaires qu’ils ont tort. Quelques possibilités :

  • Évaluer les risques du produit/projet pour choisir un cycle de vie. Vous pouvez décider si vous avez besoin d’une approche agile.
  • Implémenter par fonctionnalité.
  • Démo à cadence régulière.

Commençons par les risques liés aux produits.

Évaluez les risques de votre produit

ProblemDeterminismQuels types de problèmes ce produit résout-il ? Dans quelle mesure ce produit doit-il être innovant ?

Sur le côté gauche de cette image, nous avons des problèmes totalement déterministes. Nous n’avons pas à expérimenter.

Du côté droit, nous n’en savons pas assez – nous devons expérimenter pour découvrir ce qu’il faut offrir. Non seulement le produit changera, mais nous pourrions changer encore plus sur le produit. Cela inclut les clients, le but, tout. Je recommande une approche itérative et incrémentale là-bas. (Une approche agile fonctionnera mieux, mais une approche agile est un changement culturel, que vous force pas besoin.)

La plupart de mes clients travaillent dans la partie médiane du continuum. Ils commencent souvent plus près de la droite pour les nouveaux produits. Lorsqu’ils relâchent, ils se déplacent vers la gauche ou le milieu. De temps en temps, quelqu’un a une idée révolutionnaire et il se déplace à nouveau vers la droite.

Et si vous portiez un produit d’une plateforme à une autre ? Ou vous implémentez une bibliothèque avec une API déjà publiée ?

Ces produits peuvent être totalement déterministes, si vous souhaitez également recréer tous les anciens problèmes. C’est pourquoi je vous recommande de considérer le cycle de vie qui gérera les risques pour votre travail.

Les cycles de vie vous aident à vous organiser en fonction des risques

Les cycles de vie offrent aux personnes qui effectuent le travail deux grandes façons de gérer les risques :

  • Visualisez lorsque vous itérez pour réduire les risques. (Vous pouvez parcourir plusieurs ensembles de fonctionnalités pour ensuite sélectionner une architecture. Vous pouvez ensuite créer des jalons qui vous aident à voir quand il peut être plus sûr de sélectionner l’architecture « finale ».
  • Créez des jalons pour déterminer quand vous fournirez quel type de valeur. (Si vous utilisez des itérations, comme dans Scrum, vous livrez au moins aussi souvent qu’à la fin de chaque itération.

Les cycles de vie vous aident à organiser les livrables du projet, que ces livrables soient prédéterminés ou non.

Si vous pensez que vous n’avez pas trop de problèmes à découvrir, vous pouvez utiliser en toute sécurité une approche incrémentielle. (Voir Quel cycle de vie ou approche agile correspond à votre contexte ? Partie 3, Cycles de vie incrémentiels.) Vous n’êtes pas obligé d’utiliser une approche agile, surtout si vos responsables veulent une feuille de route qui est vraiment un diagramme de Gantt déguisé.

Une approche incrémentielle vous aidera à libérer de petits morceaux de valeur tout le temps. Si vous apprenez également à créer de petites tranches verticales afin de pouvoir les implémenter par fonctionnalité, vous pouvez fournir quelque chose d’utile intérieurement tous les jours. Ensuite, la libération devient une décision commerciale.

Vous n’avez pas à vous soucier des délais car vous en libérez suffisamment chaque semaine. (En supposant que vos histoires soient petites.)

Et si vous deviez apprendre au fur et à mesure ? Vous pourriez avoir besoin d’une approche itérative et incrémentielle mais pas agile.

Chacune de ces options de cycle de vie vous offre de nombreuses opportunités pour créer de petites tranches verticales et libérer le travail fini en interne. C’est ce qu’on appelle la planification basée sur les livrables. Vous obtenez une planification basée sur les livrables avec de petites tranches verticales de fonctionnalités.

Créer de petites tranches verticales par fonction

implémenter par fonctionnalitéCette image est ce que j’entends par « Implémenter par fonctionnalité ».

Notez que les fonctionnalités (en rouge, vert et bleu) sont petites et traversent toute l’architecture. (J’ai écrit beaucoup plus à ce sujet dans Agile and Lean Program Management et Create Your Successful Agile Project.)

Et si vous aviez des équipes composantes ? Voir Rôles de produit, Partie 5 : Équipes de composants pour créer des tranches pour quelques idées.

Si vous voulez « respecter » les délais, les équipes doivent finir de petits éléments à travers l’architecture tous les jours ou plusieurs fois par semaine.

Et si vous n’avez pas de petits livrables ? Si vous avez vraiment besoin de respecter des délais, apprenez à passer à la réflexion « combien peu ».

Chaque fonctionnalité importante a plusieurs livrables. Apprenez à terminer un de ces livrables chaque jour ou deux. (Oui, les approches agiles utilisent aussi cette idée, mais vous pouvez utiliser cette idée dans un cycle de vie incrémentiel. C’est ce que j’ai fait à partir des années 70. Une vieille idée. Pourquoi les gens ne l’utilisent plus ? Parce que les galets en pouces créent beaucoup aussi de nombreux détails dans un diagramme de Gantt.)

Vous pouvez implémenter par fonctionnalité dans tout cycle de vie. Même dans une cascade. Ce qui signifie que vous pouvez faire une démonstration à volonté.

Démo tôt et souvent

ProductBacklogburnup
Tableau d’avancement du backlog de produit (plusieurs itérations/jalons)

Si vous voulez faire passer vos managers de la pensée « nous avons besoin de tout » à la pensée « combien peu », faites une démonstration à chaque fois que vous publiez une tranche.

De plus, créez une cadence pour les démos, comme le mercredi matin à midi ou juste avant. Enregistrez la démo.

Lorsque les managers vous demandent où vous êtes, demandez : « Avez-vous déjà vu la démo ? Avez-vous vu ce que nous avons fait pour vous ? (HT à Chris Li, qui a dit cela le premier.)

Vous pouvez effectuer chacune de ces opérations, en supposant que vous utilisiez une approche incrémentielle ou agile.

Si les managers disent : « Non, je suis trop occupé pour regarder la démo », vous pouvez dire :

  1. « J’aimerais vraiment que vous le regardiez avant de poser d’autres questions. La démo fait partie de vos données. Je peux proposer d’autres données, mais la démo compte plus que toute autre chose.
  2. « Étant donné que nous livrons quelque chose tous les deux jours, et certainement chaque semaine, nous sommes sur la bonne voie. Nous travaillons aussi vite et aussi bien que possible. Vous voulez voir une prévision ? »
  3. « D’accord, si vous êtes vraiment occupé, voulez-vous le rapport d’état de 30 secondes, 60 secondes ou 5 minutes ? » Le rapport de 30 secondes est le graphique de burnup du backlog de produit, comme ci-dessus. Le rapport de 60 secondes est le graphique plus la démo la plus récente. Le rapport de 5 minutes est les deux précédents plus les prévisions pour le prochain mois de travail. (Vous pouvez proposer d’autres données.)

Dites tout cela d’une manière respectueuse. D’après mon expérience, la raison pour laquelle vos managers veulent tout, c’est parce qu’ils sont sous pression. Vous pourriez poser des questions sur la pression qu’ils ressentent et sur ce que vous pouvez faire pour atténuer cette pression.

Vous aimerez peut-être certaines des idées de Quelle décision prendrez-vous en fonction de ces données ?

Compte tenu de ce qui se passe chez mes clients, je soupçonne que les gestionnaires ne réalisent pas à quel point ils pourraient avoir de liberté s’ils passent de la certitude à plus d’ouverture.

Moins de prédictivité, plus d’options

Un gros problème que je vois est que les managers sont récompensés pour la certitude et « leurs » livrables. Ces idées sont anti-agiles.

J’ai donné une conférence à Agile 2018 intitulée : « Feuille de route Agile et Lean : Incorporer le changement à tous les niveaux de planification.  » Je l’ai basé sur la série de feuilles de route Agile et Lean.

Cependant, je vois encore beaucoup de fonctionnalités importantes et de longs délais dans trop d’organisations supposées agiles. Si vous avez ce problème, réfléchissez à ce que vous voulez demander à vos gestionnaires. Et considérez que le cycle de vie vous offrira les meilleures options.

N’oubliez pas : les feuilles de route offrent des options. Une feuille de route prédéterminée est un diagramme de Gantt. Peut-être que si vous dites ces mots à vos managers, ils pourraient envisager des alternatives.

(Cet article est lié à Avec des approches agiles, pas besoin de « respecter » ou de « faire respecter » les délais.)

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

Laisser un commentaire