(fr)agile, No Scrum No Win ? – #2

Product Ower, Backlog Product, Sprint, Poker, Daily scrum, Warm-up, workload, Scrum master… tous ces anglicismes ont et continuent d’envahir nos méthodes de gestion de projets d’évolutions et de transformations de systèmes d’informations.

Leur objectif : rendre agile.

Comment ? en permettant de délivrer des « morceaux » cohérents d’applicatif de façon itérative jusqu’au produit final.
La promesse ? Accélérer le time-to-market, éviter les effets tunnel par des validations successives et souplesse dans la décision des priorités métier.

Pour continuer mes analogies sur le Rugby où la tendance est également à la multiplication des temps de jeux (sprint), à plus de vitesse, plus de fluidité entre les avants et les 3/4 (devOps), plus de temps effectif de jeu, je dirai là encore qu’un tel schéma de jeu n’est possible qu’avec une maîtrise complète des fondamentaux :  l’engagement et l’adhésion de tous à  cette philosophie de jeu, la discipline, les phases de conquêtes que sont notamment la touche et la mêlée, la technique balle en main – pour faire des passes – certains de ces secteurs sont complexes, paraissent fastidieux, et ne sont pas forcément « agréables » 🙂

« no scrum no win ».

Qu’est ce que cela nous dit ?
Que sans une culture forte et une vraie maîtrise technique, et un réel pilotage votre projet Agile ne fonctionnera pas.

Une User Story n’est pas un Use Case.

Identifier les users stories qui doivent pouvoir être embarquées de façon indifférenciée dans les sprints représente un vrai travail d’analyse.
Lister les étapes des UC avec leurs plans de validation est également un travail de formalisation à part entière.

Une pratique répandue consiste à penser une story comme INVEST.
I : indépendante (des autres story)
N : négociable (c’est le pourquoi et pas le comment qui peut/doit être discuter )
V : valeur (métier)
E : estimable (suffisamment explicite pour être chiffrée)
S : simple (veillez à ce que chaque story puisse être faite dans un seul sprint)
T : testable (ces tests doivent être disponibles avant le sprint)

Confondre, ou se passer de l’un ou de l’autre vous conduira au mieux à faire du lotissement classique et au pire à perdre petit à petit la maîtrise fonctionnelle de votre projet.

Les hommes changent moins vite que les méthodes

le pair programming, les daily scrum, les sprint review et l’ensemble des pratiques Agile favorise la collaboration des parties prenantes, cela est l’essence de ces méthodes mais peut s’avérer contre-productif sans contrôle (pas de documentation, conflits internes,…).

Le design-to-cost n’est pas du forfait

Ne vous leurrez pas, même si vous avez fait l’effort de faire un product backlog complet avant le début des sprints et qu’un workload a été fait sur l’ensemble des items. Il vous sera difficile d’obtenir des engagements, car votre prestataire ne sait pas de quelles user stories sera composé le sprint ni même si après le sprint il y aura des ajustements (c’est le principe même de l’Agile).

Le risque est donc un glissement budgétaire de votre projet si vous n’avez pas assez impliqué les métiers (ou une autre partie prenante) dans la définition des user stories ou si le product owner n’a pas suffisamment spécifié.

Ce n’est là que quelques illustrations, vous devrez sans doute éviter d’autres pièges.

En bref, avant de lancer un projet structurant en mode agile assurez-vous
> d’avoir une vision claire et maîtrisée des objectifs (exigences)
> de ne pas négliger les phases de conception
> de ne pas laisser le product owner seul aux commandes
> d’avoir une équipe de dév au niveau le + homogène possible
> d’avoir mobilisé et motivé l’ensemble de l’équipe !

Mon conseil est de considérer tout d’abord dans vos projets les méthodologies agiles comme des pratiques de développement.

Cela vous permet de conserver des phases amont et aval plus formalisées avant de vous lancer dans le grand bain.