Adopter une approche agile
CHAPITRE 7
225
Une plus grande implication du client peut être perçue comme un coût ; il faut donc le
convaincre qu’il a tout intérêt à effectuer cet « investissement », en démontrant que la
valeur ajoutée du produit final compense le coût de sa participation au projet. S’il ne
considère pas opportun de s’impliquer davantage, on peut s’interroger sur la justification
du projet lui-même. En outre, les avantages doivent lui être présentés très concrètement :
plus grande transparence, meilleur arbitrage décisif sur les priorités, satisfaction accrue,
meilleure communication, adéquation du produit à ses attentes…
Intermédiaire entre client et équipe de réalisation, la fonction « maîtrise d’ouvrage » tend
de plus en plus à se développer dans les organisations ; déjà impliqués dans les projets de
développement, les maîtres d’ouvrage sont un vivier pour être de « bons » product
owners et, a priori, plus sensibles aux bénéfices qu’apportent les approches agiles. La
question est de savoir s’ils bénéficient de l’autonomie dont ils ont besoin pour exercer ce
rôle au sein d’une équipe agile. D’autant que, paradoxalement, ces intermédiaires existent souvent dans des environnements non agiles.
Les utilisateurs finals
Ils sont les interlocuteurs les mieux placés pour exprimer leurs besoins et pour restituer
un feedback lorsqu’on leur présente des fonctionnalités opérationnelles. Mais les
utilisateurs ne se sentent concernés par un projet informatique que si celui-ci leur
apporte une solution à un problème métier ou rend leurs activités quotidiennes plus
confortables. Il est donc essentiel de parler leur langage et de s’assurer que l’on
adresse les vrais besoins.
Ils n’ont malheureusement pas tous la disponibilité souhaitée, mais un utilisateur
convaincu par la méthode et surtout par le résultat visible sera plus actif, d’une part pour
« porter la bonne parole » auprès de ses pairs, d’autre part pour s’investir encore davantage.
Cette plus grande disponibilité peut avoir des impacts organisationnels : elle relève de
décisions prises au niveau de l’entreprise, qui leur accordera ou pas une part d’autonomie
et une disponibilité qui doit être durable pour assurer une continuité et une cohérence sur
l’ensemble du projet de développement.
L’équipe
Tous les développeurs ne sont pas des passionnés des méthodes agiles ! Et quel que soit
le degré d’adhésion, l’équipe, qui adopte de nouvelles méthodes de travail, perd ses repères traditionnels : elle a donc besoin d’être guidée, accompagnée dans sa démarche.
Les méthodes agiles ne sont pas sécurisantes : en effet, elles exposent davantage les
collaborateurs et les invitent à plus de responsabilisation. On peut être sensible à ce gain
en autonomie et à la possibilité de pouvoir exprimer plus facilement ses talents, ou l’on
peut s’affoler à l’idée de ne plus se voir assigner les tâches à exécuter.
L’équipe doit, par conséquent, être rassurée sur l’esprit de la démarche, les conditions de
sa nouvelle autonomie ; elle est associée à l’évaluation de la démarche sans crainte du
GestProjInform Livre Page 225 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 7
225
Une plus grande implication du client peut être perçue comme un coût ; il faut donc le
convaincre qu’il a tout intérêt à effectuer cet « investissement », en démontrant que la
valeur ajoutée du produit final compense le coût de sa participation au projet. S’il ne
considère pas opportun de s’impliquer davantage, on peut s’interroger sur la justification
du projet lui-même. En outre, les avantages doivent lui être présentés très concrètement :
plus grande transparence, meilleur arbitrage décisif sur les priorités, satisfaction accrue,
meilleure communication, adéquation du produit à ses attentes…
Intermédiaire entre client et équipe de réalisation, la fonction « maîtrise d’ouvrage » tend
de plus en plus à se développer dans les organisations ; déjà impliqués dans les projets de
développement, les maîtres d’ouvrage sont un vivier pour être de « bons » product
owners et, a priori, plus sensibles aux bénéfices qu’apportent les approches agiles. La
question est de savoir s’ils bénéficient de l’autonomie dont ils ont besoin pour exercer ce
rôle au sein d’une équipe agile. D’autant que, paradoxalement, ces intermédiaires existent souvent dans des environnements non agiles.
Les utilisateurs finals
Ils sont les interlocuteurs les mieux placés pour exprimer leurs besoins et pour restituer
un feedback lorsqu’on leur présente des fonctionnalités opérationnelles. Mais les
utilisateurs ne se sentent concernés par un projet informatique que si celui-ci leur
apporte une solution à un problème métier ou rend leurs activités quotidiennes plus
confortables. Il est donc essentiel de parler leur langage et de s’assurer que l’on
adresse les vrais besoins.
Ils n’ont malheureusement pas tous la disponibilité souhaitée, mais un utilisateur
convaincu par la méthode et surtout par le résultat visible sera plus actif, d’une part pour
« porter la bonne parole » auprès de ses pairs, d’autre part pour s’investir encore davantage.
Cette plus grande disponibilité peut avoir des impacts organisationnels : elle relève de
décisions prises au niveau de l’entreprise, qui leur accordera ou pas une part d’autonomie
et une disponibilité qui doit être durable pour assurer une continuité et une cohérence sur
l’ensemble du projet de développement.
L’équipe
Tous les développeurs ne sont pas des passionnés des méthodes agiles ! Et quel que soit
le degré d’adhésion, l’équipe, qui adopte de nouvelles méthodes de travail, perd ses repères traditionnels : elle a donc besoin d’être guidée, accompagnée dans sa démarche.
Les méthodes agiles ne sont pas sécurisantes : en effet, elles exposent davantage les
collaborateurs et les invitent à plus de responsabilisation. On peut être sensible à ce gain
en autonomie et à la possibilité de pouvoir exprimer plus facilement ses talents, ou l’on
peut s’affoler à l’idée de ne plus se voir assigner les tâches à exécuter.
L’équipe doit, par conséquent, être rassurée sur l’esprit de la démarche, les conditions de
sa nouvelle autonomie ; elle est associée à l’évaluation de la démarche sans crainte du
GestProjInform Livre Page 225 Vendredi, 3. avril 2009 12:07 12