Le mode Agile adaptatif maîtrisé

Ce dixième article de la boîte à outils méthodologiques "Continuous Sprint 0 et au-delà" se situe dans la partie "au-delà " et traite du contrôle opérationnel indispensable à la maîtrise d’une réalisation en mode Agile réellement "adaptatif".

Lors d’un développement en mode réellement Agile, l’équipe détermine son propre objectif en termes de production. Cet engagement (de principe) - exprimé en unités d’œuvre - s’effectue lors d’un jeu d’estimation consensuelle (Planning Poker Game, PPG) et aboutit à une autoévaluation de la capacité de la « Team » à produire les éléments du « Backlog de produit ». L’exécution de ce contrat (moral) se matérialisera lors d’une réalisation respectant cette évaluation de compétence productive.

Auto-estimation et auto-contrôle

Note : ce dixième cartouche de la boîte à outils méthodologiques "Continuous Sprint 0 et au-delà" se situe dans la partie « au-delà » et traite du contrôle opérationnel indispensable à la maîtrise d’une Réalisation en mode Agile réellement « Adaptatif ». 

Selon les actuels préceptes représentatifs de l’agilité en développement de SI, le propriétaire du futur produit (Product Owner, PO), dispose à tout instant d’une connaissance lui permettant d’apprécier l’état d’avancement du « concrètement livré » (Done). Dans la réalité, cette préoccupation se limite fréquemment au bon vouloir de l’équipe de réalisation, de son chef de projet (et oui, il en reste de survivants), ou du ScrumMaster. Ce dernier s’avérant généralement aussi un membre de la Team (et oui, cela se passe bien souvent ainsi). En revanche, la priorisation opérationnelle - officiellement acceptée comme Agile - sera évidemment celle proposée par le PO ; lequel se basera sur la valeur métier attribuée aux récits utilisateurs (US, Users Stories,). Principale raison d’être de la recherche d’agilité, l'acceptation des demandes de changements - le mode « adaptatif » - doit permettre au client de modifier ses exigences et sa planification opérationnelle à tout moment du projet (dernière et quatrième des valeurs agiles). Cette facilité aura pour conséquence l'éventualité d'un périmètre variable. La plupart des développements utilisent néanmoins (plus ou moins explicitement), d’autres variables d’ajustement influençant des combinaisons de planifications stratégiques. Lesquelles se basent depuis toujours (et encore) sur les délais, les coûts, les compétences et la disponibilité des ressources, etc. 

Maîtrise de la réalisation

Le seul réel indicateur de succès

Pratiquant la chose Agile depuis 1991, je peux vous assurer que « le seul indicateur indispensable au constat d’une réussite des développements demeure le simple constat de cette réussite ». Cet unique KPI (Key Performance Indicator, pour les initiés du grand bluff pseudo agile) se nomme Graphe d’avancement des fonctionnalités acceptées (Done). Comme par hasard, il devient de plus en plus rare d’observer son affichage, y compris dans les mises en œuvre de SAFe, ce framework basé sur le Lean, mais déguisé très consciencieusement en méthode pseudo agile. Cette proposition de certifications multiples à l’échelle d’une grande organisation s’avère d’ailleurs réellement agile, durant 2 jours tous les trimestres grâce à la PIP (Planification d’Incrément de Programme), mais uniquement  lorsqu’elle investit pour se réaliser en présentiel.  Il n’en demeure pas moins que cette organisation des développements représente actuellement la meilleure proposition d’un retour au professionnalisme formalisé dans un contexte d’agilité à l’échelle. 

Notes : pour en revenir au produit à réaliser, sa spécification lors du Sprint 0 ne nécessite évidemment pas systématiquement la totalité des pratiques proposées dans les 9 premiers cartouches de connaissances du Continuous Sprint 0. Souvent, la légèreté d’un simple atelier de Design Thinking permettra de s’assurer du besoin réel « métier ». Par contre, acceptons le principe de consacrer un peu de temps à une ou deux autres informations de contrôles – telles les anomalies détectées après le DONE par exemple - pour s’assurer de la qualité applicative, qu’elle soit fonctionnelle ou technique.

Les graphes d’avancement du produit

Gestion basique : la maîtrise des délais (Time To Market)

Le graphe précédent (partie gauche de l’illustration) représente le minimum acceptable permettant au PO de visualiser l’état de l’avancement en termes de délais. Par facilité, les sprints se calent généralement sur un jour déterminé (le lundi toutes les deux semaines calendaires par exemple). D’autre part, les colonnes (time box) se représentent le plus souvent de largeur fixe. Ce format simpliste s’avère en revanche insuffisant à raisonnablement tracer les modifications ou abandons demandés. Dans la seconde représentation (partie droite de l’illustration), la productivité réelle se détermine alors ainsi : Unités d’œuvre livrées utiles + UE réalisées mais abandonnées = Total UE livrées. Ce calcul simpliste s’avère à ma connaissance le seul moyen formalisé d’accepter le « changement », cette valeur Agile suprême et nécessaire à la satisfaction du « métier » ; ce, sans perte de contrôle pour l’équipe de son engagement initial. L’analyse du graphe ainsi obtenu permet alors de comprendre l’incidence des modifications imposées sur le « livré utile ». Il est aussi possible de varier la largeur des colonnes afin de mettre en évidence les durées et les capacités réelles des sprints, dans le cas où celles-ci varieraient au gré des périodes.

Note : en cas d’absence de cette information minimum caractéristique des évolutions d’objectifs, il faudra alors envisager l’impact des problèmes découlant des refus de modifications ; lesquels interviennent lorsque les dérapages sans traçabilité se matérialisent. Cette situation, aussi classique que fréquente, conduit inexorablement à de mauvaises relations entre équipe et métier, ou à des procès lorsque des prestataires externes sont impliqués. Dans tous les cas l’ambiance devient délétère, puis les dissimulations mensongères conduisent alors à la disparition de la fameuse bienveillance, puis ensuite à des blocages en tout genre.

Gestion avancée : la maîtrise budgétaire (Design To Cost)

Dans les deux graphes précédents (essentiellement représentatifs des délais), la notion de coût de réalisation (le budget concrètement utilisé) n’apparaissait pas ; une simple information additionnelle permet de la matérialiser. Le graphe suivant- précisant la capacité utilisée réellement- met en évidence l’excellente performance de l’équipe (alors même que le périmètre livré utile apparaît comme inférieur à l’attente initiale). La justification de ce point pourra s’attribuer, par exemple, à l’impact de ressources ayant quitté le projet (démission, maladie, etc.) en affectant la capacité engagée (donc les délais), mais dont l’absence non rémunérée ne grèvera pas le budget.

La technique de traçage des changements permet alors au contenu fonctionnel d’être modifié, en permanence et même en cours de développement (voire abandonné), par le propriétaire du produit. Dans les cas moins évidents, l’observation de la liste des « Freins et Obstacles » justifiera les éléments responsables de la situation visualisée. Ainsi se caractérise la transparence totale d’un véritable management de réalisation.

Note : il est préférable de réaliser ces graphes manuellement à partir de PowerPoint sur lequel seront dupliqués et positionnés par copiés-collés des segments de droites. Une feuille Excel (figure précédente) permettra de sauvegarder et fiabiliser ces données, surtout si le nombre de sprints est conséquent.

Comment créer le graphe optimum

Lors de l’estimation consensuelle, l’équipe aidée du Product Owner - afin d’appréhender une vision globale du développement - s’appuie sur un Backlog relativement exhaustif (MVP), mais non nécessairement détaillé (le niveau Ready). L’estimation réalisée s’exprime en unités d’œuvre (journées non idéales ou points de complexité standardisée de SAFe) et se trouve alors mise en regard des ressources disponibles ou des contraintes de temps. S’en déduit un nombre de Sprints intégrant les capacités prévisionnelles des périodes couvertes (figure suivante). Sur ces bases le Burn Up chart pourra alors se construire.

Bien évidemment, le contenu fonctionnel peut ensuite être modifié, en permanence et même en cours de développement par le métier (troisième des quatre valeurs agiles). Chaque modification sera alors tracée sur la fiche de récit utilisateur de la fonctionnalité modifiée ou même abandonnée. Les parties de développement réutilisables sont ensuite réintégrées dans l’évaluation formelle des modifications ou des nouvelles fonctionnalités. Quelques petites règles à respecter pour ne pas pénaliser l’équipe ou le métier sont alors à prendre en considération.

Le Post-it minima indispensableLe Post-it nécessaire à l’aspect « adaptatif » d’une production agile contrôlée, comme le montre la figure suivante, est en pratique un peu plus structuré que ce qui se trouve généralement sur les murs. La fonctionnalité complète et ses cas de tests réels y sont rarement détaillés. De plus, l’aspect éphémère et fragile du Post-It autocollant impose que ces informations soient conservées sur un support plus pérenne (Excel ou outil spécialisé). Parmi les détails à observer, le nombre d’unités d’œuvre livrées (Estimation initiale) permet de présenter graphiquement la productivité obtenue pour chaque Incrément livré. Dans le cas d’abandon (total ou pour modification ultérieure) en cours de développement (ou après la livraison), ce sera le réel (Charge consommée) qui sera prise en compte.