Seule, l'Agilité n'a aucun sens.

Qu'est-ce que l'Agilité, au fond ? Par certains aspects, elle peut sembler protéiforme, d'autant que son message est brouillé par le "bruit" des sprints et autres estimations. S'il fallait la résumer en une phrase, je dirais que c'est la recherche d'efficience dans le développement logiciel, dans un contexte où le changement est la norme. L'Agilité, c'est l'art du "comment" : comment shipper rapidement du logiciel de bonne qualité, sachant que le besoin se découvre au fur et à mesure et que la capacité à produire est limitée.

L'Agilité trouve ses racines dans l'eXtreme Programming, qui contenait tout : rien ne sert de découper en user stories si l'on n'est pas en mesure de mettre en production très fréquemment. D'où l'intégration et le déploiement continus, et, si l'on tire encore le fil de la pelote, les sujets de testabilité, de modularité et de Clean Code. Agilité, DevOps et Craftsmanship sont tous trois nécessaires pour "faire en sorte que ça marche".

En revanche, que sait-on du "quoi" ? J'entends l'explicitation des besoins, savoir quoi développer, viser juste. Cela comprend des activités variées, parmi lesquelles la recherche utilisateur (découvrir et caractériser les problèmes à résoudre), la conception fonctionnelle (définir ce qui doit être mis en œuvre, mais aussi découper et prioriser), le design d'interface et le test utilisateur. Ces préoccupations sont celles du Product Management, qui fait nécessairement appel au champ de savoir de l'UX (User eXperience).

Mon grand étonnement, c'est que l'on parle de Product Management sans parler d'Agilité et réciproquement, alors que les deux marchent ensemble : ce sont l'avers et le revers d'une même pièce, le premier relevant de la stratégie quand le second relève de la tactique.

• Le Product Management sans l'Agilité, ça ne sert à rien : à quoi bon concevoir de très bons logiciels s'il n'y a pas la capacité à délivrer derrière ? Et même, que vaut une conception si elle n'est pas validée rapidement par l'usage ?

• Réciproquement, l'Agilité sans le Product Management, ça ne marche pas : c'est un canard sans tête, le fameux "on ne sait pas où l'on va, mais on y va". D'ailleurs, nombre d'entreprises qui se plaignent d'avoir des problèmes d'agilité ont en fait surtout des problèmes de définition du besoin.

Au fond, cela révèle que l'agilité a été conceptualisée par des personnes qui venaient du développement et qui ont réfléchi avec leur prisme, leur background, leurs préoccupations. Et c'est bien légitime. Et cela apporte déjà beaucoup de valeur. Mais ces développeurs, aussi pertinents soient-ils, ont cherché à optimiser leur travail dans un cadre établi, sans peut-être oser le remettre en question. L'expression "répondre au changement" est, à ce titre, très révélatrice.

À ma connaissance, aucun cadre de travail agile n'aborde le sujet de la conception fonctionnelle, et certainement pas Scrum. Un Scrum Master faisant son métier vous répondra au mieux que le temps passé par les développeurs à la conception – à supposer qu'ils y prennent part – se traduit par une vélocité moindre, donc que c'est pris en compte… Réponse peu satisfaisante, car la question n'est pas combien de temps il faut pour développer une fonctionnalité, mais plutôt combien de temps il faut à l'entreprise pour passer d'une idée non validée à une fonctionnalité déployée en production. Le Time To Market, en somme.

Peut-être faudrait-il, comme le suggère le Lean, considérer la production de logiciel comme un flux de l'entreprise, ce flux comprenant et le Product Management et l'Agilité, et rechercher des optimisations à l'échelle du flux dans son ensemble plutôt qu'aux bornes de chacun des silos.