Vous souhaitez implémenter une méthode agile dans votre organisation, ou avez déjà entamé la démarche.
Pourtant, c’est plus compliqué que prévu et vous cherchez à comprendre comment bien axer votre démarche ou améliorer celle en cours.
Plutôt qu’un énième conseil peu concret, nous vous proposons de prendre le problème dans l’autre sens, sur la base de notre expérience en conseil & coaching agile dans des dizaines d’entreprises !
Quand ne pas faire d’agilité ?
Ou plutôt, quand est-ce que l’agilité a des (fausses, spoiler) faiblesses ?
Raison n°1 : Quand personne dans l’équipe ou la structure ne connaît l’agilité.
Il est possible d’adapter les méthodes agiles pour en concevoir une sur mesure pour sa situation. Mais improviser l’agilité pour s’en approcher, sans qu’une personne puisse juger de la qualité ou du choix de la méthode et de son adaptation dans votre structure ? On ne vous dira pas que c’est impossible, mais cela reste très difficile.
- La force de l’agilité réside avant tout dans 3 choses :
- sa culture, centrée sur l’amélioration continue et la valeur délivrée
- ses rituels, indispensables à la bonne communication au sein de l’équipe et vers les parties prenantes
ses artefacts, que ce soit un kanban, un backlog ou autre, accessibles à toute l’équipe et permettant une transparence totale.
Une méthode agile qui est intégrée à une structure ou une équipe, avec des failles, qui est mal appliquée, et pour laquelle personne n’a la connaissance et la compétence pour ajuster si besoin, aura de grandes difficultés à discerner l’origine de ses problèmes.
Est-ce l’intégration de la méthode ? Sa mise en œuvre ? Un problème humain ?
Un des objectifs premiers de l’agilité étant de trouver des solutions aux problèmes pour s’améliorer, on comprend pourquoi mal connaître l’agilité et donc la source des problèmes, se retournera rapidement contre vous.
Pourquoi ne pas appliquer l’agilité quand on ne connaît pas donc ?
Et bien, ce qui découle de ce manque de discernement, c’est le risque de déception. Si votre expérience est un échec, les futures frictions ne seront que plus grandes pour réussir, ou même recommencer.
De notre expérience, c’est le problème premier des organisations qui ont fait l’expérience de l’agilité.
Commencez avec des bases saines, de la compétence et de l’expérience. Cela vous aidera à aller plus vite et à créer plus rapidement de la valeur.
Raison n°2 : Quand l’organisation n’est pas prête à intégrer la méthode
Votre méthode est bonne, les équipes sont formées, vos projets sont adaptés à l’agilité, le management soutient les équipes, la culture agile est de mise au sein de l’organisation ?
Si toutes les cases ne sont pas cochées, il est probable que votre organisation ne soit pas prête à une agilité optimale.
La méthode :
Nous vous renvoyons au point n°1.
Si vous vous êtes tout de même entourés de personnes d’expérience pour définir votre méthode, mais que ce qui a été défini est une adaptation un peu hasardeuse, il est probable que cela ne fonctionne pas.
En allant vers une agilité “à la carte”, qui arrange votre organisation et vos anciens processus, vous aurez également des performances… “à la carte”…
La formation :
Une formation seule ne suffit jamais, quel que soit le sujet. Cela est dû au principe de déclin de rétention de la mémoire : sans rappel nous oublions.
Il est donc essentiel de pratiquer dès la sortie de formation.
Vos projets :
Nous vous renvoyons aux points 4 à 7. Peut-être qu’il faudrait revoir la façon dont vous créez des projets et de la valeur !
Le management :
Lien essentiel à la mise en place de toute nouvelle méthode de travail, cela ne fait pas exception pour l’Agilité. Rôle pivot, il permet, lors de la mise en place, de faire le lien entre la culture Agile et les autres cultures. Garant des indicateurs de performance, il facilitera la transparence et l’autonomisation de l’équipe et saura mettre en avant l’amélioration de celle-ci.
La culture :
Complexe par nature, la culture d’entreprise est difficile à changer/modifier. Il n’y a pas de méthode pour aller vers une culture Agile, mais des managers prêts à relever le défi, faire confiance aux équipes, les accompagner dans leur montée en compétence.
Mais la culture Agile est-elle déjà dans votre entreprise ?
Vos équipes vous remontent les problèmes naturellement ? Mettent-elles en place des solutions efficaces sans forcément remonter de problèmes ? Parlez-vous d’amélioration plutôt que d’erreurs ?
La culture part de l’humain, de la relation que vous avez avec les autres. Sans confiance, sans transparence et sans autonomie, l’Agilité ne peut exister.
Encore une fois, cette raison n’est pas un “no go” catégorique, mais il est important de connaître ces critères pour identifier les enjeux et être agile en vous améliorant.
Raison n°3 : Dans une organisation silotée
Traditionnellement les réalisations coûteuses sont assorties de cahier des charges bien précis et de méthodes prédictives.
Une organisation silotée, qui découle de cette tradition, se confronte mécaniquement à presque tous les problèmes évoqués dans la raison n°2.
Elles adoptent par exemple un management directif, partant du sommet de la pyramide vers le bas. À cela est lié le fait de déresponsabiliser les personnes en bas de la pyramide et de contrôler la totalité des tâches effectuées. Une opposition directe avec l’autonomie et la transversalité de la responsabilité portés par la culture agile.Ce point est d’ailleurs le plus bloquant parmi ceux cités en n°2. Si la structure managériale de l’organisation silo ne porte (ou du moins supporte) pas l’agilité, le manque de lien entre la culture Agile et les autres cultures causera des incompréhensions systémiques et donc des erreurs voir des frictions dans la prise de décision de la structure (les décisions étant généralement prises par un manager voire un directeur).
Le bon moyen de mettre en place de l’Agilité est de l’initier avec des projets transverses !
En effet, il sont d’une nature beaucoup plus incertaine et complexe, c’est là que l’agilité brille.
Les silos étant centrés sur leur métier pur, ils ne sont pas capables d’avoir une vision d’ensemble permettant d’avancer dans une seule direction.
Contrairement au cycle en V où on tente de dérisquer un maximum dès le début du projet, en agilité, on se concentre surtout sur la création de valeur étape par étape. Le risque n’est donc pas évalué en début de projet et mesuré en fin de projet, mais à chaque itération du projet (en général tous les mois).
Raison n°4 : Quand le projet a une dépendance forte à un délais matériel/fournisseur
Il faut le reconnaître, SCRUM n’est pas le plus adapté lorsque vous avez des dépendances matériel/fournisseurs fortes. Si votre produit intègre un matériel fabriqué et paramétré par un fournisseur à l’autre bout du monde, il vous sera difficile de renvoyer le dit matériel toutes les deux semaines pour effectuer des modifications de paramétrage.
Par contre, le Lean pourrait être adapté sur l’évolution de matériel. Fort d’outils tels que PDCA, Kaizen. Issu de l’industrie, ses outils sont utilisés dans l’ensemble des secteurs d’activités aujourd’hui et sont complémentaires de l’Agilité.
Raison n°5 : Quand l’organisation délègue la production à d’autres entreprises
Pour des questions de coût, de taille d’entreprise ou autre, beaucoup font appel à des sociétés tierces développant des produits sur étagère nécessitant un paramétrage ou développant un outil sur mesure.
Dans ce genre de cas, il existe le plus souvent la configuration suivante :
- côté fournisseur : un chef de projet et une équipe technique
- côté client : un chef de projet et une Assistance à Maîtrise d’Ouvrage (métier).
Le dialogue entre client et fournisseur se passe uniquement entre chefs de projet. Il est donc impossible pour l’équipe d’avoir un lien direct avec l’AMO (métier) afin de bien comprendre les besoins.
De plus, si le fournisseur propose une nouvelle version du logiciel tous les mois, souhaitant faire de l’Agilité, le client se retrouve à écrire des specs et effectuer des recettes, tout en réalisant du bout de méthode agile. Deux méthodes projets sont alors mélangées : SCRUM et Cycle en V, causant :
- des mésententes entre client et fournisseur (problèmes de communications)
- un nombre important d’allers-retours entre livraison/recette/re-livraison/re-recette…
- etc.
Les conséquences étant inévitables : retard, besoin de budgets supplémentaires, qualité moindre.
Il est possible néanmoins de mélanger ces méthodes, et cela porte un nom : la méthode R.A.C.H.E. – vous avez d’ailleurs la possibilité de passer une certification ici 🙂 : https://www.la-rache.com/. – méthode à manier avec précaution (second degrés).
Dans ce genre de situation les meilleures solutions possibles restent :
changer la configuration afin qu’il n’y ai plus de chef de projet, mais un Product Owner en lien direct avec l’équipe et donc d’appliquer la méthode SCRUM
utiliser une autre méthode projet, tel que le cycle en V.
Raison n°6 : Quand les équipes changent souvent
Cette raison s’applique particulièrement à la méthode SCRUM.
Un de ses principes est de capitaliser sur l’humain pour améliorer la valeur produite au fil des cycles. L’équipe travaille mieux ensemble parce qu’elle apprend à mieux travailler ensemble.
La méthode est ensuite dépendante de cette capacité de travail pour jauger la quantité de valeur produite à chaque itération et donc dérisquer au fur et à mesure de l’avancée du projet (délais et coûts).
A chaque fois que l’on change l’équipe, on repart en quelque sorte de zéro, car la connaissance du potentiel de l’équipe change. Il devient presque impossible d’estimer la nouvelle capacité et donc de dérisquer de la même façon.
Cependant, l’agilité fonctionnant en itération courtes, le risque est tout de même moins élevé qu’en cycle en V. Il est donc tout à fait possible de concevoir une autre méthode que SCRUM, adaptée aux fluctuations dans l’équipe. “Les individus et leurs interactions plus que les processus et les outils” 😉 (Pilier n°1 du manifeste Agile)
C’est notamment ce qui a été fait à la province Sud de Nouvelle-Calédonie. Nos consultants sont intervenus afin de former et mettre en place une méthode Agile sur mesure, découlant de SCRUM, mais adaptée au fait que les équipes ne peuvent pas être fixes.
Raison n°7 : Quand on veut absolument tenir un cahier des charges (et de surcroît dans un délais et un budget précis)
Pourquoi utilise-t-on un cahier des charges ? Ce document recense l’ensemble des fonctionnalités, des pré-requis d’un projet, qu’il soit informatique ou non.
Tout est défini dans le détail, ce qui est très utile lorsque l’on construit un bâtiment, l’erreur n’est pas permise, il est donc important de tout évaluer et tout prévoir. Il y aura forcément des surprises en cours de route et des réajustements. Mais un projet dans le bâtiment est-il incertain ? À priori non, on sait où l’on construit, les matériaux utilisés, on connaît le sol, etc. Mais qu’en est-il des projets informatiques ?
La plupart du temps la personne en charge d’un projet informatique souhaite définir un cahier des charges afin de définir dans le moindre détail l’ensemble des fonctionnalités. Mais cette personne est-elle spécialisée en expérience utilisateur ? Connaît-elle les plus grands usages des utilisateurs ? Connaît-elle les possibilités techniques pour répondre à ses besoins ?
Mais surtout, lorsque le cahier des charges est respecté, le résultat est-il satisfaisant ? Correspond-il au besoin utilisateur ? La personne chargée du projet est-elle satisfaite ?
Malheureusement non.
C’est pour cela que SCRUM par exemple, demande à communiquer étroitement avec l’équipe afin de détailler au fur et à mesure du projet les specs. Cela permet d’embrasser le fait que le besoin évolue au fil de l’eau et également d’accepter le changement, contrairement à un cahier des charges rigide, et donc d’être au plus prêt des besoins réels (et non estimés) du projet
Ensuite, quand le projet s’arrête-t-il ? Deux possibilités :
- le produit est satisfaisant et répond au besoin
- le budget ne permet pas d’aller plus loin.
Dans le second cas, SCRUM assure le fait d’avoir un produit fonctionnel apportant le maximum de valeur aux utilisateurs.
Si l’agilité ne permet pas de garantir un nombre défini de fonctionnalités dans un délai et un budget donné ce n’est peut être pas la méthode que vous cherchez.
Malheureusement, aucune méthode ne vous le permettra.
Ce n’est pas pour autant que cette dernière raison devrait être un frein à l’adoption de l’agilité. C’est en fait une excellente opportunité de comprendre que tous les projets dépassent budget et délais, quelle que soit la méthode, et d’apprendre à tirer le meilleur des situations dans le cadre qui leur est imparti (un des objectifs principaux de l’agilité).
De plus, il y a toujours de l’inconnu dans un projet, qu’il soit en V ou agile. En se concentrant sur la production de valeur sur de courtes périodes, l’agilité excelle également dans la gestion des risques associés. “L’adaptation au changement plus que le suivi d’un plan” (Pilier n°4 du manifeste Agile).
———————————–
Vous l’aurez compris, l’agilité peut s’adapter quand même presque à toutes les situations. L’enjeux est donc de savoir comment le faire, et si cela est techniquement et humainement possible dans votre organisation.
Donc ne jurez pas que par SCRUM, ouvrez l’esprit de vos managers et collaborateurs, testez, améliorez, recommencez. Vous avez de la valeur à portée de main !
