MMF ou incrément ?

La communauté "Kanban" se fait entendre de plus en plus fort dans la sphère agile. Le ton monte parfois entre ses principaux représentants (David J. Anderson, Corey Ladas) et le reste de la communauté agile. Pour preuve certains débats sur le groupe de discussion yahoo kanbandev, ou les critiques de David J. Anderson sur Scrum.

Cette communauté introduit son jargon avec des termes comme Kanban ou Minimum Marketable Feature (MMF). Attardons-nous sur les MMF. Qu'est-ce qu’une MMF ? En quoi une MMF se différencie d’un bon vieil incrément agile ? En quoi l’outil MMF peut considérablement améliorer la valeur délivrée ?

Des définitions

Le livre "Sofware by Numbers" à l’origine du terme " Minimum Marketable Feature " en donne la définition suivante :

" MMF are units of software value creation. They represent components of intrinsic marketable value. […] Typically an MMF creates market value in one or more of the following ways : - Competitive differentiation - Revenue generation - Cost saving - Brand projection - Enhanced user loyalty "

Corey Ladas, figure du Lean Software Development fait aussi le parallèle avec l’outillage agile classique :

" A Minimum Marketable Feature is the smallest unit of work that has recognizable value to the customer. […]. The Minimum Marketable Feature is the most valuable product of Rolling Wave Planning. A Minimum Marketable Feature can be decomposed into User Stories, Use Cases, BDD Scenarios, etc. for detailed work scheduling. […]. A Sprint Goal is a substitute for having a real business-valued goal. A Minimum Marketable Feature is the real thing. "

Quelles différences par rapport au développement itératif et incrémental ?

Commençons par le plus évident : une MMF n'est pas une user stories. Une MMF est un ensemble logiciel livrable et autoportant (en production) du point de vue utilisateur, tandis qu'une user story l'est extrêmement rarement puisqu'elle se plie aux contraintes INVEST (effort de développement de quelques jour, testable...).

Plus ardu : quelle différence entre une MMF et un bon vieil incrément agile ?

Alistair Cockburn nous donne la définition suivante du développement incrémental : " Incremental development is a staging and scheduling strategy in which various parts of the system are developed at different times or rates, and integrated as they are completed. "

L'incrément désigne donc un ensemble logiciel cohérent faisant des compromis de conception et d'intégration pour ne pas livrer le produit final et permettre des livraisons intermédiaires. L’apport des incréments en termes de réduction des risques " projet " est évident. Pour autant, ces incréments au sens de Cockburn n’apportent pas nécessairement un avantage compétitif, un revenu supplémentaire ou une diminution des coûts…

Lacher la proie pour l’ombre

Les MMF recadrent les objectifs premiers du développement logiciel : les MMF (et la mesure de leur délai le temps de cycle) sont la vraie mesure du succès. Tous les autres artefacts sont secondaires, notamment les livraisons d'itération ou les incréments réduisant des risques projet. Tous les autres indicateurs sont secondaires, notamment la très " myope " vélocité.

Malheureusement, cet enfonçage de porte ouverte n’est pas une évidence sur tous les plateaux agiles. Ainsi, certaines équipes se mesurent leur performance à l'aune de la seule vélocité ou axent les principaux efforts d'amélioration sur cette métrique.

Quelques questions permettent de mesurer la focalisation sur les MMF dans nos projets agiles :

• Les acteurs projet (sponsor, product owner, développeurs) sont-ils tous conscients et alignés sur le suivi des temps de cycle et des MMF (temps de cycle moyen, prochaine MMF, respect du planning MMF...) ?
• Quelles sont les améliorations en cours pour améliorer le temps de cycle ?
• Quelles améliorations permettraient d'améliorer le temps de cycle sans passer par une amélioration de la vélocité ?
• Est-ce que le plan des MMF est remis en cause régulièrement ?

Qu’on ne s’y trompe pas, la vélocité reste un indicateur extrêmement pertinent, quant à la motivation de l’équipe de développement, l’accumulation de dette technique etc, mais il ne doit pas être l’indicateur principal de pilotage projet et de mesure de la performance globale de l'ensemble de l'équipe projet.

Ainsi, se focaliser sur le temps de cycle global permet d'entrevoir des améliorations complètement invisibles du point de vue vélocité. Par exemple l'amélioration de " l'exploitabilité " du livrable (packaging pour faciliter le déploiement, interfaçage aux outils de supervision...) peut réduire grandement le temps de cycle sans aucune incidence notable sur la vélocité (voire une baisse de vélocité).

Attraper la proie

Bien sûr, parler de MMF plutôt que d'incrément n'améliore pas les temps de cycle en soit. En revanche, tout ce qui suit améliore les temps de cycle et le ROI :

• focaliser l'attention de toute l'équipe sur les objectifs premiers de la livraison des MMF (les autres objectifs sont secondaires) ;
• piloter par les MMF (donc par le temps de cycle, les autres indicateurs sont secondaires) ;
• concevoir de meilleures MMF (encore plus maigres, encore plus plus valorisables et encore plus orientées utilisateur) ;
• agencer continuellement le séquencement des MMF (l’intégration continue est une bonne chose, pourquoi la planification continue ne le serait pas ?).

Conclusion

OCTO est arrivé depuis un an à la même conclusion qu'Allan Kelly et son "Doing the things Right before Doing the right things" : à l'issue d'une stabilisation du processus de production logicielle par les pratiques de développement agile, le goulet d'étranglement se déplace vers la maîtrise d'ouvrage.

Malheureusement le corpus Scrum/XP est d’une aide faible pour adresser ces enjeux, comme le déplore Corey Ladas dans son livre Scrumban : " I also think that the Product Owner role is an especially egregious error that trivializes the problems of product planning, product design, and requirements analysis and hides them behind a black-box role that encompasses at least much complexity as the "development" part of the software creation process. […] I address that problem by admitting a much larger definition of « team » than the very programmer-centered model of early Agile thought. "

L'offre " MOA agile " d'OCTO adresse ce nouveau challenge en outillant les MOA pour les aider à planifier, concevoir, recetter et réceptionner plus efficacement dans leurs projets agiles.

Les MMF sont une arme de ce nouvel arsenal. Arme à manipuler avec précaution puisqu’elle met en branle la maîtrise des enjeux métier, le respect des contraintes SI et la dynamique de l’équipe projet au sens large.