webleads-tracker

5 « clés » pour rater son Projet Agile …. et quelques pistes pour y remédier - Clé n°3

5 « clés » pour rater son Projet Agile …. et quelques pistes pour y remédier - Clé n°3

« Agile », « Agilité », « Projet Agile » … tous ces mots obéissent à une volonté prégnante des entreprises de rester compétitives face à un marché concurrentiel et de demeurer innovantes face aux usages et besoins de consommateurs qui ont radicalement changés avec le numérique.
Réussir son Projet Agile, c’est donc en théorie proposer des produits user centric : désirables pour ses utilisateurs, qui leur apportent de la valeur ajoutée et qui soient rapidement utilisables (le fameux time to market).
Loin de cette image d’Épinal, mettre en œuvre un Projet Agile peut se solder par un échec cuisant avec des répercussions douloureuses tant d’un point de vue humain que financier(1). 
Vous êtes sur le point de réaliser un Projet Agile ? 
Vous réalisez un Projet Agile et vous rencontrez quelques difficultés ?  
Alors, cet article – sans prétention d’exhaustivité ou d’omniscience – peut vous aider à comprendre pourquoi certains projets Agiles échouent ou sont voués à l’échec avant même d’avoir commencé.
Retrouvez chaque semaine une nouvelle clé pour rater votre Projet Agile.
 

# Clé n°3 - Mettre en place une organisation projet floue

Comme évoqué précédemment, l’un des fondements de l’agilité est l’auto-organisation de l’équipe.
 
Ceci constitue en soi un vrai changement voire une révolution pour tous ceux qui raisonnent encore avec les vieux réflexes du cloisonnement MOA/MOE avec tous les travers qui en découlent : trouver des argumentaires pour faire porter la faute à l’autre partie en cas d’échec du projet et ce parfois même avant que le projet ne démarre, communiquer par mail pour garder des traces écrites car on ne sait jamais, le fait de penser « contrat », « forfait »,… et ne pas vouloir déroger du cadre initial plutôt que de s’adapter dans la limite du raisonnable (cf. les situations de contorsionnistes évoquées dans l'article précédent), …
 
A ce changement des habitudes s’ajoute le manque de repère par rapport aux nouveaux rôles de chacun — souvent par manque de formation.
    
Un Product Owner, est-ce un Chef de Produit ? Un Scrum Master, est-ce un Chef de Projet ? Un développeur, est-ce un développeur ?
  
Sur ce dernier point on vous rassure, un développeur est un développeur… mais lui aussi verra son rôle et ses attributions évoluer.
 
Dans la tête d’un développeur peu au fait des principes Agiles, parler de mise en place d’un tel projet peut susciter deux réactions : « je n’aurai plus de contraintes, je peux faire tout ce que je veux. On est agile, non ? » ou « je vais être constamment surveillé par mon Scrum Master avec ces Daily Stand-Up. En plus, toutes ces réunions me font perdre du temps car pendant ce temps, je ne code pas ! ».
 
Vous l’aurez compris, imaginer ne pas avoir de contraintes est quelque peu utopiste pour un développeur à qui l’on demande une exigence plus forte de qualité avec notamment des tests plus nombreux
 
Penser également que le travail de « non-programmation » avec les Daily Stand-Up ou encore les Planning Poker est une perte de temps indique que la notion de travail d’équipe n’est pas encore intégrée. 
 
Les Planning Poker ont de l’importance car ils permettent aux développeurs d’avoir une vision et des objectifs du produit de façon régulière. Certes, ne pas y assister permet de coder plus, mais y a-t-il un vrai intérêt à « coder juste pour faire des lignes de codes » sans rapport réel avec les besoins du client avec le risque qu’une partie de ce code s’avère au final inutile ?   
 
Quant aux Daily Stand-up, ils ont pour principaux objectifs de partager auprès de l’équipe ce sur quoi on a travaillé la veille, ce sur quoi on compte travailler aujourd’hui et quels sont les obstacles rencontrés. Le fait d’indiquer en toute transparence les obstacles rencontrés peuvent permettre aux développeurs quel que soit leur niveau de séniorité d’échanger entre eux – en dehors du Daily Stand-up – sur les moyens de les résoudre. 
 
Ces échanges peuvent se dérouler sereinement si et seulement si le Scrum Master qui est le véritable leader de l’équipe joue son rôle de facilitateur et de coach pour l’équipe. Il est donc la personne clé, dotée d’un fort leadership, d’une aisance relationnelle et d’un état d’esprit constructif pour amener l’équipe à trouver comment le travail peut être fait. En d’autres termes, il apprend à l’équipe comment s’auto-organiser et il la protège aussi des éléments extérieurs pouvant nuire au bon déroulement du projet.
 
Il va sans dire que le Scrum Master n’est pas un Chef de projet… ou un (Proxy) Product Owner !
 
Il n’est pas Chef de projet car son rôle n’est pas d’assigner des tâches, de prendre des décisions à la place de l’équipe ou encore de faire « passe-plat » entre le (Proxy) Product Owner et l’équipe, voire de prendre des décisions à la place du (Proxy) Product Owner.       
 
Il joue plus le rôle de : 
  • coach expérimenté en faisant des recommandations et en apportant des conseils avisés auprès des développeurs et du (Proxy) Product Owner quand il identifie des obstacles ;
  • garant du respect de la méthodologie, sous réserve qu’il la maîtrise lui-même.
 
Il n’est pas un (Proxy) Product Owner car il n’est pas responsable de la valeur du produit ni de la priorisation des fonctionnalités et des besoins métiers… à chacun son périmètre métier et il ne s’agit pas de l’outrepasser ! 
 
Comme facilitateur et garant de la méthode, il doit être au contraire l’appui du (Proxy) Product Owner pour notamment l’aider à construire un backlog pertinent au regard des contraintes de développement dont il a par ailleurs la visibilité.
 
Bref, le Scrum Master est le facteur clé de succès du Projet Agile car il doit tirer le meilleur du profil de chacun et développer auprès de l’équipe l’ouverture d’esprit, la capacité de se remettre en cause, la volonté d’apprendre et de progresser, la confiance dans la prise de parole pour certains développeurs introvertis car chaque voix compte !
 
Tout le contraire du command & control classique du chef de projet.
 
Quant au Product Owner, ce n’est bien évidemment pas un Chef de Produit qui décide seul des directions à apporter au produit !  
 
Le Product Owner fait donc partie intégrante de l’équipe et travaille en étroite collaboration avec elle pour la définition du produit. Il sort donc de son rôle de spectateur, voire d’opposant comme dans les relations classiques MOA/MOE pour agir et penser uniquement à la sortie d’un produit à valeur ajoutée pour ses clients.
 
A noter que dans l’hypothèse où le Product Owner ne peut être intégré à l’équipe pour des raisons de disponibilités ou de réalisation par un sous-traitant, la solution peut se trouver en la nomination d’un Proxy Product Owner pour être l’interlocuteur quotidien de l’équipe de développement à la place du Product Owner. Dans cette configuration, la réussite du projet d’un point de vue métier dépendra de la capacité du Proxy Product Owner à endosser le rôle du Product Owner. 
 
Il doit en effet avoir une bonne maîtrise du contexte et des enjeux du projet, tout en ayant la légitimité suffisante pour porter la vision du produit. Il doit également avoir assez de recul pour procéder aux inévitables arbitrages
 
Pour garantir la réussite du projet, il est indispensable que le Proxy Product Owner et le Product Owner partagent la même vision du produit ou que le Product Owner ait suffisamment de maturité pour avoir cette vision et l’insuffler auprès du Proxy Product Owner. Sans ces éléments, le projet court à l’échec car les décisions prises risquent d’être constamment remises en cause.
 
Vous aurez compris la nécessité de définir les tâches et responsabilités de chacun au risque de ralentir le projet et d’instaurer une ambiance délétère au sein de l’équipe.  
 
------- 
 

Vous n’avez pas encore débuté votre projet en mode Agile ? 

  1. Prenez le temps pour définir les rôles et les responsabilités de chaque membre de l’équipe et l’expliquer dans le cadre du Sprint 0.
  2. Mettez en place ou assurez-vous d’avoir une équipe dédiée uniquement à votre projet pour éviter que les ressources passent en permanence d’un contexte de projet à un autre et pour faciliter le travail de l’équipe qui pour aller vite à besoin de réponses rapides par les personnes adéquates. 
  3. Réalisez votre projet en « Cycle en V » si la redéfinition des rôles est perturbante pour l’équipe.   
 

Vous avez déjà débuté votre projet en mode Agile ?

  1. Faites-vous aider d’un expert
  2. Mettez en place ou assurez-vous d’avoir une équipe dédiée uniquement à votre projet pour les mêmes raisons qu’évoquées ci-dessus.
  3. Aucun des éléments mentionnés ci-dessus ne peut être réalisé ? Continuez à vos risques et périls.

 

 
Légende : 
(1) Voir à ce titre l’article de Maxime BLANC, « S’affranchir du cycle en V », « Agile canada dry » ou « comment perdre 4 ans et 1.45 M€ ».
 
Lexique : 

 

Je m'inscris à la Newsletter mensuelle de Sollan

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ajouter un commentaire

CAPTCHA
Merci de nous aider à éviter les spams, en répondant à cette question. Par exemple, pour 1+3, saisissez 4 :
7 + 3 =
Trouvez la solution de ce problème mathématique simple et saisissez le résultat. Par exemple, pour 1 + 3, saisissez 4.