Méthodes agiles : "00 – Continuous Sprint 0", une simple "chek-list"

Premier volet d'une série de chroniques visant à présenter la démarche "Continuous Sprint 0 et au-delà". Le point sur le contenu "agilisé" de 12 cartouches détaillant des pratiques peu connues ou absentes des méthodes actuelles.

Des trous dans les raquettes

Comprendre ce qu’il "faudrait faire" est certainement la partie la plus aisée en matière de développement de systèmes d’information. La réelle difficulté réside dans la mise en oeuvre de solutions drastiquement différentes de celles employées jusqu’alors. Voilà ce que proposait l’agilité à ses débuts : une rupture de paradigme concernant tous les aspects organisationnels, et non une simple "amélioration continue" de type Lean. Depuis 2001, les vraies méthodes Agiles à l’origine du Manifeste ont simplement disparu (à l’exception de XP, approche malheureusement incomplète, trop technique, et trop extrême selon certains). Deux approches se référant du Lean se partagent désormais le marché :

  1. Scrum, se souhaitant méthode, mais se révélant un simple cadre d’amélioration continue (lotissement en Sprint et cérémonial de rétrospectives).
  2. SAFe, se présentant modestement comme un framework Lean, mais recouvrant en fait la plupart des critères caractérisant une méthode presque complète (en évolution permanente et scalable à l’échelle des organisations les plus importantes).

Des trous dans le filet

SAFe, à bien saisi l’opportunité de s’appuyer sur la base installée de Scrum. Il va même jusqu’à former et certifier ses propres ScruMaster et Product Owner ainsi que d’autres ressources (comme le RTE Release Train Engineer et le Product Management). D’autre part, SAFe n’hésite pas à embarquer XP pour l’ingénierie logicielle et Kanban pour l’organisation visuelle des activités. Ce pragmatisme s’avère efficace, mais l’analyse complète de la solution fait apparaitre une double problématique :

  1. En premier lieu (en bas à gauche de la "SAFe big picture"), il y a des trous dans le filet, car ni Scrum ni XP ne s’intéressent à une forme Agile de structuration des besoins applicatifs (d’où l’objet en 2008 de ma proposition PUMA Essentiel).
  2. En second lieu (en haut à gauche), malgré la pléthore de techniques dont SAFe recommande l’usage, il manque toujours "l’anticipation rationnelle du changement" (technique proposée en son temps par PUMA Entreprise).

Note : Détail amusant avec du recul, le Forrester Research (le spécialiste du domaine), considéra dans son rapport 2013 PUMA, comme l'une (avec SAFe) des deux approches d'adaptation Agile au niveau de l'entreprise. Depuis, comme la méthode RAD bien avant lui, PUMA (Processus Urbanisant les Méthodes Agiles) qui nécessitait un minimum de rigueur est tombé dans l’oubli.

Dimensions humaines et financières

Selon mon expérience, la seule méthode digne de ce qualificatif reste SAFe. En revanche, son application actuelle implique des "trains" de 50 à 125 personnes, et nécessite pour sa mise en oeuvre d’aligner une demi-douzaine des zéros après le chiffre significatif. Voilà une raison supplémentaire pour penser qu’entre les deux extrêmes de Scrum et de SAFe se situe certainement un besoin que se propose de couvrir "Continuous Sprint 0 et au-delà".

Concepts complexes à matérialiser graphiquement

La notion "d’au-delà" implique que notre simple check-list dépasse la notion classique de Sprint 0 ponctuel pour intégrer celle de "continuous". D’une part elle explore le "nécessaire et suffisant" à prendre en compte lors de l’émergence de solutions novatrices impliquant le risque de la remise en question continue.  D’autre part elle inclut les techniques du véritable mode incrémental-itératif-adaptatif permettant l’acceptation continue du changement mesuré sans lequel l’agilité réelle n’existe pas. Si Scrum n’a jamais tenté de maîtriser ces notions, SAFe par contre en a formaliser le principe "Assume variability, préserve options" et organise sa mise en œuvre systématique lors de l’itération "Innovation and Planning" clôturant chaque incrément.

Les éléments de la check-list "Continuous Sprint 0"

Les composants méthodologiques de notre check-list se répartissent sous quatre aspects adressés par une conduite de projet Agile (étendue et en continue) : Exploration, Design, Solution, Delivery. Voici une présentation sommaire (et en première version) de ces douze "cartouches de connaissances“.

1. Continuous Exploration

Ce triptyque a pour principale valeur de permettre à l’organisation apprenante d’organiser un mode coopératif et bénévole de projection rationnelle s’appuyant sur l’engagement de ses ressources humaine dans une captation des événements conditionnant l’évolution de sa transformation. La formalisation de cette différenciation concurrentielle comme sa justification économique en découle naturellement, mais doit simplement être simplifiée et agilisée.


2. Continuous Design

Ce triptyque se base sur des ateliers agiles lors desquels "l’expérience client" servira de guide d’alignement métier pour concevoir une vision produit minimum agilement modélisée.

3. Continuous Solution

Ce triptyque, sans être révolutionnaire, transformera la vision en exigences de fonctionnalités à produire. Ses techniques, bien que réellement réellement itératives, permettront la constitution d’un vrai "contrat agile" entre métier et équipe de développement.

4. Continuous Delivery

Ce triptyque, se développant parallèlement à la réalisation, offrira une mesure fiable de l’état de la construction d’une solution validée en permanence (techniquement comme fonctionnellement).

Synthèse

Ces "cartouches de connaissances" permettent simplement de compléter en l’agilisant une vision souvent trop élémentaire ou trop élaborée de certains sujets. Pour des organisations très avancées dans l’étude de ces aspects méthodologiques, cette check-list n’apportera que quelques compléments ou idées d’usage. En revanche, d’expérience je sais que dans de nombreuses entreprises ne disposant pas de cellule méthode suffisamment spécialisées, Continuous Sprint 0 offrira une base de travail structurée et permettra le gain d’un temps de réflexion lors de la mise en œuvre d’une structure de développement vraiment Agile. Les prochains articles détailleront ces aspects.