S'il y a un product owner, il peut y avoir un design owner

DictatorScrum, la méthode agile la plus populaire, définit un rôle de product owner. C'est un membre à part entière de l'équipe de développement qui a certaines responsabilités. Citons principalement :

  • décrire les éléments du backlog produit
  • les prioriser
  • approuver leur implémentation dans le produit

De manière anti-symétrique, la plupart des autres équipiers (oublions le scrummaster qui ne prend pas part directement à la création du produit), n'ont pas de rôle exclusif : ils sont pluridisciplinaires.

Il y a une possibilité pour régler ce problème de symétrie, c'est de dissoudre la responsabilité PO au sein de l'équipe en rendant chaque membre responsable des objectifs business et non plus seulement de la construction du produit. Les multiples approches du genre "PO proxy" ne sont, je pense, que des manières plus ou moins heureuses de tendre vers une telle organisation.

Il y a toutefois une autre façon pour redonner un peu de symétrie : tout comme il y a un product owner qui agit en tant que leader sur l'objectif business, il pourrait y avoir un design owner qui assurerait le leadership sur la conception du produit.
J'ai le sentiment (peut-être à tord ?) qu'une telle approche n'aurait pas bonne presse dans un contexte qui se définit comme agile.
En supprimant le command & control matérialisé la plupart du temps par un chef de projet omnipotent qui est avant tout un chef du planning et des ressources, la mouvance agile en est arrivée à promouvoir des organisations sans aucun chef.
J'ai l'impression (toujours peut-être à tord ?) qu'aujourd'hui il est difficile de faire valoir que certaines responsabilités de conception puissent être assignées à quelqu'un en particulier dont le choix serait prépondérant, tout comme le choix de priorisation d'un product owner est prépondérant sur celui des autres personnes qui peuvent concourir à l'objectif business.

Sans aller jusqu'à faire la promotion d'organisation de développement logiciel assez autocratiques comme pouvait le suggérer Brooks avec son chirurgien en chef dans le contexte des années 70, il me semble qu'une organisation peut introduire des rôles de leadership de conception tout en restant en accord avec les valeurs et les principes du manifeste agile.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
Si cela est vrai en attribuant un rôle spécial à un unique product owner, alors cela reste vrai en attribuant un rôle spécial à un unique design owner.
Il ne s'agit pas de déposséder l'équipe de sa capacité d'autoorganisation. Tout équipier peut avoir son mot à dire sur tout ce qui concerne le produit. Un design owner dont les choix seraient contestés par la majorité des équipiers aurait un futur assez compromis. Cela n'est d'ailleurs pas moins vrai pour un product owner qui ferait des choix de priorités plus que douteux.

Le terme owner est d'ailleurs probablement mal choisi autant pour l'un que pour l'autre. Il s'agit plus de leaders qui donnent le cap et, par leur capacité à porter des décisions, assurent une certaine cohérence à l'ensemble.
Le fait est que dans la réalité des développements logiciels, ce rôle de design leader existe quasi-systématiquement de manière explicite ou implicite. Il existait même explicitement dans certaines méthodes agiles aujourd'hui oubliées[1] à cause de la déferlante scrum.
Le monde de l'open source fourmille de dictateurs bienveillants qui sont un point positif pour la bonne marche de nombreux projets.
Plus généralement dans le monde de l'entreprise, qu'on le nomme Lead Programmer ou Tech Lead, ce responsable de la conception fait plutôt du bien à un projet de développement logiciel, du moins pour ce que j'ai pu en voir.

Son absence inconstestable dans la terminologie agile actuelle est pour moi un mystère.
Dans Software Craftsmanship: The New Imperative, Pete Mc Breen abordait l'organisation d'un projet de développement logiciel en parlant de Lead Software Craftsman. Le mouvement actuel du même nom (software craftsmanship), émanation de la mouvance agile, a repris bien des idées déjà présentes chez Mc Breen il y a 12 ans mais l'organisation avec hiérarchisation de rôles n'en fait étrangement pas partie.

Les agilistes sont-ils victimes d'un syndrome d'égalitarisme ?

Notes

[1] par exemple le team leader dans DSDM

Fleid

Bonjour Oaz,

Dans ma vision de la chose, une équipe auto-organisée ne veut pas dire une équipe sans organisation.

Pour moi « auto-organisée » veut dire que l’organisation va s’établir d’elle-même, naturellement, plutôt qu’être imposée par des éléments extérieurs. En effet elle apparaîtra de manière naturelle, à partir des compétences de chacun et du leadership naturel plutôt que des titres sur les cartes de visite.

Cela veut également dire qu’elle n’est pas figée dans le temps, qu’elle peut évoluer en fonction de la monté en compétence de chacun, de leur forme physique et mentale (c’est bon d’avoir un backup naturel quand on fatigue) et des arrivées et départs dans l’équipe projet.

Par contre dans cette équipe auto-organisée, il y a bien un lead technique, un architecte, qui assume ce rôle et impose des contraintes. Il le fait non pas parce que le management l'a nommé, mais parce qu’il a la connaissance, la compétence, le charisme pour le faire. Parce qu’il le fait bien en fait.

Fleid 28 septembre 2012 - 14:43
Oaz

Bonjour Fleid,

Je suis globalement d'accord. A un détail près : tout ne peut pas toujours s'établir "naturellement"...

Oaz 29 septembre 2012 - 11:28

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.