Situez votre pratique dans ces formes étranges du reporting agile

Le cas 2, le plus utilisé  (lorsqu’utilisé), apporte le premier niveau de contrôle sérieux en se basant sur l'engagement de l’équipe au sujet d’un périmètre initial qu’elle a elle-même estimé (de préférence lors d’un Planning Poker).   Cette étape d’évaluation  détermine la  « vélocité théorique initiale » que le graphe (BurnUp chart de préférence), utilisera  pour matérialiser la diagonale d’un contrat projet.  Les informations se présentent alors ainsi :

1. Verticalement calibré en d’unité  d’œuvre, que certains nomment des Journée Idéale mais qui selon moi seraient plutôt des Journées NON idéales (des vraies journées permettant une vraie estimation en fonction du vrai contexte et des vraies compétences et motivations), sera portée l’estimation initiale à partir de laquelle se calcule - en intégrant le nombre de ressources et la durée d’une « boite de temps »  - le nombre de sprints prévus (dont le résultat se représentera  ensuite par des  segments de droite dans les colonnes).
2. La seconde information (matérialisée par les segments  d’avancement), se construira  de sprint en sprint en prenant en compte les unités d’œuvre  livrées et acceptées comme conformes aux attentes par le métier. 

Ce cas 2  permet donc de comparer un prévisionnel initial à la réalisation en cours, offrant par la même une indication du respect des délais (et généralement des couts) de construction du produit. Par contre, si un décrochage se visualise, rien ne permet à ce niveau d’en comprendre les raisons. Lesquelles se trouveront peut-être sur la liste des obstacles et des freins, si ce document qui devrait être impérativement le premier à être visible sur le mur  existe.

Note sur  un Enfumage scrumisant : Le cas 3 s’appuie sur le cas 2 - qui correspondrait à une réalité nécessaire et suffisante - si les préconisations intenables de Scrum étaient réalistes et observées. Je parle de l’interdiction de modifier sérieusement le contenu d’un sprint. Je n’ai pas écrit l  «d’une itération » car cette expression s’avère une grosse supercherie lorsqu’utilisée dans le cadre de Scrum. Dans ce framework, ce qui est livré est un Incrément et la boite de temps de sa production se qualifie de Sprint. D’ailleurs à ce sujet, il est pour moi évident que l’utilisation de deux mots aussi différents de sens pour une seule réalité a pour but grossier de faire croire que Scrum est bien itératif, ce qui n’est pas le cas au niveau des Sprint (mais, depuis 2010, une simple possibilité de modification mineure à l’intérieur d’un sprint). Ce principe battant en brèche une des valeurs fondamentales de l’agilité :  l’acceptation du changement.

3 - La forme efficiente et assertive

Le cas 3 est celui que je proposais déjà dans la chronique intitulé  « Une solution agile au problème contractuel des changements » (la troisième en partant de la plus ancienne).

Le cas 3 s’appuie sur les informations présentes dans le cas 2 (pourquoi réinventer la roue). Par contre, une technique proposée en complément permet au contenu fonctionnel d’être modifié, en permanence et même en cours de développement (voir abandonné), par le propriétaire du produit. Chaque modification ou abandon sera tracée sur la fiche de récit utilisateur (post-it) de la fonctionnalité modifiée ou abandonnée. Les fiches en question seront conservées comme justifications. Les parties éventuellement réutilisables seront ensuite (si possible) réintégrées dans l’évaluation formelle des modifications à intégrer ou des nouvelles fonctionnalités.

Dans ce contexte, l’équipe aura pour obligation de livrer en fin de « projet » ou de « boite de temps globale »  un nombre d’unité d’œuvre au minimum égal à la vitesse nominale prévue.  Soit :  (nombre de personnes * nombre de jours ouvrés de travail sur l’incrément). Le nombre d’unité d’œuvre (UE) permettant de présenter graphiquement la productivité obtenue pour chaque incrément (BurnUp chart) se composera alors ainsi : UE livrées au total = UE livrées utiles + UE livrées abandonnées.

4 - Une autre réalité complémentaire

Dans la réalité des projets, il arrive effectivement que le périmètre puisse être en partie (hors du Minimum Viable Produit) considéré comme variable d’ajustement. Bien souvent ce n’est pas envisageable et si la planification opérationnelle « par la valeur » reste valable,  le choix d’une autre variable d’ajustement doit être considéré. Classiquement, en fonction du contexte il faudra choisir entre sacrifier délai de livraison ou budget. Le « ou » devenant exclusif si une nécessité de « Time To Market » l’impose. Si la contrainte à surveiller est le budget (figure accolée), les largeurs de colonnes variables - en fonctions du temps réellement imputé dans les sprints - vous apporteront un début de solution.

Conclusion et humour

Voilà, cette chronique paraîtra peut être évidente à ceux qui pratique déjà ainsi, mais selon mes  nombreuses expériences, c’est très loin d’être le cas pour la majorité des développements. Je présume donc, vu que l’approche Incrémentale et Itérative fut publiée sous la forme d’une méthode en 1991 et que Scrum fit ensuite l’objet d’une révélation (Schwaber et Beedle)  en Octobre 2011, soit 8 mois après l’Agile Manifesto, que ces manquements doivent servir de base secrète à l'obtention de réussites miraculeuses.

Pour conclure avec un peu d’humour, c’est en tant que professionnel IKO, bénévole et intermittent  du KiteSurf, que je vais vous expliquer pourquoi j’aime ce genre de sport dont la « transparence » s’apparente à celle d’une valeur Agile : Lorsqu’un débutant tente vainement de sortir de l’eau en prenant de petits bouillons, ou lorsqu’un confirmé fait de même en ratant une figure, personne sur la plage ne songe à se moquer de l'un d'entre eux. Sauf, bien évidemment, s’il revient mouillé en prétendant être sec !