« How do Agile UX teams collaborate? Notes 1 » de Dean Meyers est sous licence CC BY 2.0
Article rédigé en mars 2017.
« 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é 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 Agile échouent ou sont voués à l’échec avant même d’avoir commencé.
# Clé n°1 – Penser qu’agilité rime avec facilité
« Agile ? C’est facile ! Il suffit d’avoir un outil qui permet de gérer les sprints, de faire des Daily Stand-up, on n’a plus besoin de tout documenter pour faire plaisir à la MOE, … »
Ces propos ne vous semblent-ils pas familiers ?
Ce n’est pas étonnant. Beaucoup de personnes s’arrêtent aux aspects « ludiques » et simples à mettre en œuvre en pensant qu’un outil logiciel fera le travail à leur place ou encore que la mise en place d’une méthode Scrum permettra de résoudre tous les problèmes rencontrés jusqu’alors.
Aborder l’agilité uniquement sur des aspects outils et processus sans en percevoir la finalité est la garantie à terme d’un sentiment de déception voire d’une « arnaque sur la marchandise ».
Or, au-delà des outils et des processus, la démarche agile nécessite bien plus de discipline et de rigueur que l’approche en « Cycle en V » car l’un des fondements de l’agilité est l’auto-organisation de l’équipe.
S’auto-organiser nécessite notamment de pouvoir planifier son travail en ayant suffisamment de visibilité ou encore de pouvoir synchroniser les efforts de chacun.
… et cela induit des exigences fortes sur les individus et les organisations.
De la discipline technique par exemple pour les développeurs pour tester, faire du refactoring, de l’intégration continue, participer aux démonstrations, … et ce afin de produire un logiciel de qualité, évolutif et maintenable.
De la discipline personnelle pour tous afin de travailler de façon constructive dans un mode collaboratif et favorisant la communication directe et transparente car il peut être difficile de mettre en place le Pair Programming ou encore d’éviter que les Daily Scrum ne dérivent en « foire d’empoigne » avec recherche de coupable.
Vous l’aurez compris, la démarche Agile ne s’improvise pas et nécessite un effort de « changement de paradigme » de la part de tous les protagonistes.
Ces changements doivent être profonds, avec un engagement fort du Management et des équipes afin que votre projet ne soit pas une application inefficace des principes Agiles.
Vous n’avez pas encore débuté votre projet en mode Agile ?
1/ Recruter des personnes ouvertes, motivées, coopérantes, prêtes à tenter l’aventure et un Scrum Master ayant une réelle expérience en plus de sa certification.
2/ Ne brulez pas les étapes et prenez le temps de former toute l’équipe aux valeurs, aux principes et aux techniques agiles.
3/ Assurez-vous que le Product Owner est compétent dans son métier, mais aussi intéressé par les processus agiles et qu’il a le temps de porter toutes les responsabilités lui incombant. Sinon, misez en plus sur un Proxy Product Owner déjà intégré au métier ou ayant réellement les moyens d’acquérir les compétences métier.
4/ Renoncer à mettre en place votre Projet Agile si ces conditions ne sont pas réunies.
Vous avez déjà débuté votre projet en mode Agile ?
1/ Si l’équipe est en capacité de s’adapter à ces nouveaux principes, n’hésitez pas à vous faire aider le cas échéant par un expert durant quelques sprints pour amener l’équipe à utiliser les bonnes pratiques de manière naturelle.
2/ Si l’équipe n’est pas en capacité de s’y adapter, arrêtez votre Projet Agile – temporairement ou définitivement – tant qu’il est encore temps… ou continuez à vos risques et périls.
# Clé n°2 – Négliger le sprint 0
Autre propos maintes fois entendu : « Il faut être agile, non ? » … pour justifier le changement de périmètre pendant un sprint.
Qu’elles en sont bien souvent les raisons ?
De prime abord, une vision faussée des notions d’itérations et d’incréments qui signifie pour certains Product Owners : changement de plan constant sous prétexte d’être réactif au changement et de s’adapter au contexte.
… Et on arrive vite aux situations où l’équipe de développement joue les contorsionnistes pour suivre ces demandes fluctuantes bien souvent sans réel fondement, créant bien évidemment des situations de tensions qui auraient pu être évitées. Cerise sur le gâteau, l’on constate souvent que la rapidité de réalisation du produit tant vantée laisse place au meilleur des cas à des retards voire au pire à l’incapacité de sortir quoi que ce soit.
De même, certains Product Owners n’ont pas une réelle vision de leur produit, de ses fonctionnalités clés qui créent de la valeur pour le client et qui doivent être développées en priorité.
Ce constat vient du fait que bien souvent seuls quelques objectifs du sprint 0 ont été couverts au détriment d’autres. Par exemple, cantonner la réalisation du sprint 0 à la préparation de l’environnement de développement.
Ce sprint est bien souvent négligé car ne produisant pas de valeur immédiate. Penser de la sorte est malheureusement une erreur car ce sprint est un investissement essentiel pour que le projet se déroule par la suite dans des conditions optimales.
Prendre du temps à la mise en place de ce sprint permet :
- de partager une vision claire du projet (le périmètre du produit, le budget, le planning global, les enjeux, les risques, les rôles et responsabilités de chaque membre de l’équipe, …) ;
- de produire une première version du Product Backlog avec des parties plus ou moins détaillées selon le séquencement des itérations afin d’offrir de la visibilité à l’équipe de développement sur le contenu final du produit ;
- de définir dans les grandes lignes l’architecture globale du projet ainsi que les guidelines graphiques et ergonomiques ;
- de définir des KPIs Agiles partagés par l’ensemble de l’équipe (ex. valeur délivrée, efficacité via le diagramme de vélocité, qualité produite, etc.) ;
- d’apprendre à l’équipe à travailler ensemble en faisant une première estimation du backlog, à diviser les tâches, etc.
Vous n’avez pas encore débuté votre projet en mode Agile ?
1/ Prenez le temps de réaliser ce sprint en vous faisant aider le cas échéant par un expert.
2/ Renoncer à mettre en place votre projet agile afin d’éviter une déconvenue.
Vous avez déjà débuté votre projet en mode Agile ?
1/ Arrêtez temporairement le projet s’il s’avère que certains des points structurants ont peu ou prou été abordés et ce afin d’insuffler de nouvelles bases plus solides au développement de votre produit.
2/ Continuez à vos risques et périls.
# 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 ci-dessus), …
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 ? [2]
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.
2/ 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.
# Clé n°4 – Minimiser l’importance de l’amélioration continue et des rétrospectives
Choisir de réaliser un projet en mode agile sous-entend d’être conscient que tout ne peut être parfait dès le début du projet, que des erreurs seront réalisées et que grâce à elle l’équipe projet en sortira paradoxalement grandie et performante.
Les rétrospectives sont le cadre pour réaliser cette démarche collective d’amélioration continue.
Mais en pratique, que constate-t-on bien souvent ?
Des rétrospectives bâclées au meilleur des cas voire inexistantes sous prétexte qu’elles sont considérées comme un « luxe » et réalisées seulement « s’il y a le temps ».
Il est en effet difficile de pouvoir résister à la pression extérieure du projet à terminer à tout prix quel qu’en soit les raisons. Les rétrospectives étant un « luxe », il est aisé de constater qu’en leur absence on assiste à une accumulation de non-dits, une fuite en avant du sur-engagement via une estimation de charge trop optimiste ou approximative au risque d’essoufler toute l’équipe et d’arriver inéluctablement à un « accident de livraison d’itération » avec une vélocité quasi-nulle.
Pour quelles raisons ?
Pour être efficace, une rétrospective doit être ouverte et sincère.
Il faut que chacun puisse exprimer librement les difficultés rencontrées sans peur d’un quelconque jugement.
Il faut pouvoir prendre le temps d’analyser et d’approfondir les dysfonctionnements qui ont déjà pu être soulevés lors des Daily Stand-Up.
Il faut avoir le courage de ne pas « se voiler la face » en laissant les obstacles s’accumuler sans action efficace pour les surmonter.
Il faut savoir faire fi de son ego en voulant « bien se faire voir » quitte à écraser les autres membres de l’équipe et réfléchir à la réussite de l’équipe car un projet se gagne et se perd ensemble.
Il faut tout simplement ne pas craindre les échecs et les accepter comme une opportunité de s’améliorer collectivement.
Vous n’avez pas encore débuté votre projet en mode Agile ?
1/ Recrutez un Scrum Master expérimenté apte à analyser puis à débloquer les problèmes qui seront rencontrés dans le cadre du projet.
2/ Si l’ensemble de l’équipe est au fait des pratiques agiles mais sans expérience réelle de ce type de projet, faites-vous accompagner par un expert qui interviendra notamment pour fluidifier la communication au sein de l’équipe.
3/ Anticiper le coût de l’agilité car les différentes cérémonies – comme les rétrospectives –coûtent chères en jour/homme et ce d’autant plus que pour être efficaces, il est nécessaire que tous les acteurs du projet y participent.
Vous avez déjà débuté votre projet en mode Agile et vous ne constatez pas d’amélioration de la vélocité ou vos rétrospectives demeurent superficielles ?
1/ Faites appel à une personne externe au projet qui aura une vision plus objective de la situation et pourra mieux analyser les problématiques sous-jacentes.
2/ Assurez-vous du rythme régulier et soutenable des itérations et non la surperformance.
3/ N’oubliez pas de célébrer les réussites pour éviter que l’ancienne culture ne revienne.
4/ Envisagez en dernier recours la réaffectation de certaines ressources.
# Clé n°5 – Faire un Projet Agile car « c’est à la mode »
« Tu as déjà travaillé sur un Projet Agile ? C’est comment ? Parce que je dois commencer un Projet Agile bientôt et je n’ai aucune idée de ce que c’est ? »
Ces propos démontrent que les Projet Agiles sont souvent réalisés dans les entreprises pour de fausses raisons et sans qu’elles aient réellement perçues qu’adopter l’Agilité nécessite une impérieuse transformation de toute l’organisation.
Généralement, ces entreprises « passent à l’Agilité » car elles souhaitent s’extirper des travers du « Cycle en V » dont notamment l’« effet tunnel » ou encore qu’elles souhaitent obtenir un contrat où la réalisation du projet en mode Agile est un prérequis.
Elles vont pour la plupart envoyer leurs collaborateurs à des formations Agiles en vue de les certifier, acheter un outil de gestion de projet Agile, faire appel parfois à un Coach Agile et appliquer Scrum superficiellement.
Qu’elle en sera l’issue ?
Echec et déception face à l’Agilité.
Mettre en place un projet Agile passe avant tout par une transformation de la culture d’entreprise et des hommes.
À une entreprise fondée sur le blâme et la sanction en cas d’échec doit s’instaurer un cadre bienveillant et sécurisant où l’expression de la créativité n’est pas remise en cause, où chaque individu est responsabilisé et où le droit à l’erreur est reconnu [3].
En d’autres termes, penser que l’adoption de l’Agilité ne peut se faire que via un Scrum Master ou un Coach Agile est quelque peu illusoire.
Cette transformation ne pourra réussir que si la direction soutient et encourage l’initiative pour que l’équipe puisse mettre en place de nouvelles méthodes de travail.
Cette transformation ne pourra réussir que si les collaborateurs sont motivés et soucieux d’améliorer leurs pratiques actuelles.
Une approche combinée « top-down » et « bottom-up » est indispensable pour définir un projet ambitieux, réaliste et à l’image de votre entreprise.
Il n’y a pas de mystère, la personnalité de votre entreprise sera le reflet de la personnalité de votre agilité.
Pour finir, l’Agilité n’est pas une fin en soi car ce n’est pas une mode mais des principes et des valeurs – de management notamment qui a besoin de temps pour son installation.
Alors, n’hésitez pas à renoncer à l’Agile si vous ne partagez pas ses valeurs.
Et d’un point de vue plus opérationnel, n’hésitez pas à renoncer à l’Agile, si c’est un très petit projet (1-2 sprint), si vous avez de très petites équipes (1-2 personnes) ou à l’inverse de très grosses équipes (+ de 7 personnes). Dans ce dernier cas, vous pouvez le lotir en « SCRUM de SCRUM » mais cela nécessite une réelle expérience.
De même, si votre projet comporte peu de complexité fonctionnelle ou est essentiellement technique avec de nombreux sous-traitant, préférez un projet de type « Cycle en V ».
Vous n’avez pas encore débuté votre projet en mode Agile ?
1/ Demandez-vous si la réalisation de ce projet en mode Agile est nécessaire.
2/ Si oui, ne brûlez pas les étapes et réalisez un projet de transformation vers l’Agilité, projet hautement stratégique. N’hésitez pas à faire appel à des experts le cas échéant.
3/ Renoncer tout de suite à l’Agile si vous n’en partagez pas ses valeurs.
Vous avez déjà débuté votre projet en mode Agile ?
1/ Demandez-vous si la réalisation de ce projet en mode Agile est nécessaire.
2/ Si oui, mettez en place un dispositif d’accompagnement a posteriori sur le projet (coaching, évangélisation sur les pratiques d’ingénierie Agile, …).
3/ Réalisez en parallèle ou post-projet Agile un projet de transformation vers l’Agilité.
***********
Sans une communication irréprochable et transparente, un respect total des règles mises en place, un réel effort sur soi pour penser différemment, un réel investissement et un enthousiasme au quotidien de tous pour la réussite du produit, les méthodes agiles n’apporteront aucun bénéfice à l’équipe. Et, l’on pourra arriver à la conclusion facile que la réalisation d’un projet agile n’arrive pas à la hauteur des espoirs qu’il suscite.
[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€ » publié sur « Linkedin« .
[2] Sans oublier les testeurs ou encore les UX/UI Designers qui ne seront pas évoqués dans cet article mais qui ont un rôle crucial dans la réussite du projet.
[3] Voir à ce titre l’article de Thomas Gibot, « Le droit à l’erreur » publié sur le blog « Savoiragile.com« .