Product Owner vs. Manager : complémentarité ou antinomie ?

Le rôle du manager évolue fondamentalement en particulier dans un environnement où cohabitent des équipes travaillant avec des pratiques agiles interfacées avec d’autres plus « classiques ». Et cette configuration est plutôt répandue.

Jusqu’à récemment, il était reconnu aux USA comme en France, que les développements utilisant les principes Agile, concernaient des projets plutôt petits, isolés – hors des grands systèmes d’information – et le plus souvent dans des centres de recherche et développement. Or depuis une année environ, les développements agiles s’intègrent dans une gestion de programme avec de multiples contributeurs et donc des rythmes de production différents : agile et non agile. Il devient donc impératif de travailler ensemble pour que les contributions de chaque équipe arrivent au bon moment.
Cette problématique se pose par exemple de façon aigüe pour la gestion des données. La plupart des administrateurs de référentiels ne vivent pas dans un rythme « agile » et il faut pourtant faire évoluer les  schémas de données à mesure des productions agiles. Même difficulté pour intégrer des développements produits à des rythmes différents : les équipes agiles ont besoin de tester très tôt et donc vont travailler avec des « bouchons »[1].

Et voilà qu’apparaît une notion importante : la coordination des équipes sur la base du backlog agile.  La réalisation notamment de releases intermédiaires par les équipes non agiles nécessite d’anticiper les besoins.. Et comme le contenu du backlog évolue rapidement, les points de coordination doivent être également prévus.
De quelle visibilité va donc disposer le manager de ces équipes différentes, dans leurs modes de travail et comportements ?  J’ai interviewé un certain nombre de personnes et confronté leurs histoires dans des environnements très différents : qui gérant une équipe agile d’une soixantaine de personnes au sein d’un grand programme de navigation aérienne, qui dans un contexte de système d’information pour des produits d’assurance et d’autres encore.

Leur approche est toujours similaire, basée sur du bon sens : il faut se ramener à une information « acceptable » pour chacune des équipes et il semble qu’un reste à faire exprimé en « story points » d’un côté puisse se traduire, grâce au paramètre de vélocité, en « jours hommes » plus compréhensibles par les équipes réputées « classique ».
La difficulté étant toujours de passer d’un contexte local et très contextuel de l’équipe agile dont la granularité de travail est petite à un langage universel.
C’est clairement une difficulté d’acceptation de chacun des deux mondes par l’autre.

Lors de ma campagne d’observation, je souhaitais également mesurer les différences entre approche « classique » et approche agile en termes de gestion des risques projet. Cette notion est si souvent mal interprétée, les risques pas anticipés et les surprises importantes, que je m’intéresse à toute approche susceptible de rendre la gestion des risques plus efficace, éventuellement visuelle. Les agilistes parlent rarement de risques mais d’ « impediments » , c’est-à-dire pour être clair, de problèmes. Les uns gèrent des risques sur plusieurs sprints. Les autres reconnaissent que seuls les risques techniques sont mis en perspective de la valeur client, généralement en réunion sprint. Les risques liés à l’organisation du projet ou aux stakeholders ne sont eux pas vraiment traités par les méthodes Agiles.
Il faut donc enrichir les pratiques.

Enfin c’est aussi l’occasion d’échapper à la question en rappelant les 4 grands principes gouvernant le monde Agile :
1) on recherche les gains rapides,
2) le processus est itératif,
3) les décisions sont prises le plus tard possible,
4) sont focalisées sur le retour sur investissement. 
Le dernier aspect abordé dans mon tour d’horizon a été l’importance de l’intégration des productions agiles dans une architecture d’ensemble et donc  la place de cette vision architecture.

A partir de toutes ces observations, il apparaît clairement que le rôle du directeur de programme – responsable de plusieurs équipes agiles mais pas uniquement – évolue significativement du mode commande et contrôle à un mode facilitateur : après avoir délégué les prises de décisions au niveau des personnes qui ont l’information et la connaissance nécessaires, le directeur résout les problèmes qu’on lui escalade pour fluidifier le travail. La vision partagée à tous les niveaux est unique : servir en priorité  le client. Dans les cas de mixité des équipes, le travail de réconciliation par le manager entre la visibilité donnée par chacune des équipes est le point clé. Un bon manager « nouvelle vague » est un homme/une femme de dialogue et de collaboration. Il/Elle aime prendre des risques et s’attache à la pluridisciplinarité de ses équipes.

Mais un nouveau rôle distinct de celui du manager s’est également imposé dans ce paysage : celui qu’on nomme le product owner. La personne qui a la vision globale de l’architecture fonctionnelle, de l’enchaînement des sprints et surtout une compréhension satisfaisante de toutes les exigences.

Là où on avait un manager plutôt orienté « processus » dans les approches traditionnelles, on a besoin maintenant de deux rôles distincts : un manager orienté résolution des blocages de flux de travail et une fonction d’arbitrage – priorités fonctionnelles,  dépendances, géographies – qui ne sera pas un expert de chaque partie du système développé, mais un généraliste suffisamment informé et entrepreneur.
Affirmer qu’on passe d’un à deux responsables indispensables au succès des projets, c’est sans doute oublier, même dans un programme classique, qu’un architecte d’ensemble est un élément clé de succès. Force est de constater qu’il fait souvent défaut !
Directeur de programme et product owner sont deux rôles entièrement complémentaires, l’un ne pouvant remplacer l’autre.
----------------------------------------------------
[1] Un « bouchon » est un morceau de code de remplacement pour quelque chose qui n’existe pas encore.