De nos jours, il est impératif que tout projet soit lancé selon la méthode Agile, au risque de paraître hors du jeu. Il est même devenu chose courante de voir dans les critères de choix d’un profil, ses compétences ou certifications en méthode Agile, parfois même sans autres attentes, ce qui pourrait laisser penser que la capacité de conceptualisation, la rigueur, l’expérience seraient secondaires comparés à la maîtrise des rituels, cérémonies, poker planning, …
A titre indicatif et parmi d’autres études, The Standish group(1) notait déjà en 2016 que sur l’ensemble de projets qu’il analysait (i.e. plus de 50.000) le nombre de projets en méthode Agile (suivis depuis 2004) dépassait ceux en méthode « waterfall » (cycle en V). Et l’étude notait que « les projets agiles ont un taux de réussite trois à quatre fois supérieur à celui des projets en cycle en V et font 20 % de mieux que les autres types de projets. »
Il reste que l’agilité n’est pas née de nulle part, et qu’elle vise à résoudre des problèmes bien réels de l' »industrie » du numérique, qui tient justement à ce qu’il reste bien difficile d’industrialiser des projets numériques. Et comme toute méthode, l‘appliquer à son organisation sans plus de réflexion ne garantit pas le succès de ses projets.
Le soft est difficile à faire rentrer dans un modèle prédictif, il dépend trop des personnes impliquées
Quand l’agilité est apparue (années 90 puis Manifeste Agile en 2001), son succès venait du constat que les méthodes dites « prédictives » présentaient pas mal d’inconvénients et ne garantissaient pas le succès des projets de développement numérique (software).
Les méthodes prédictives (impliquant d’abord une phase conséquente de design – spécification), issues du monde de l’ingénierie, ne s’appliquaient pas si facilement au monde du « soft » : difficulté voire impossibilité à stabiliser les spécifications, difficulté à chiffrer a priori le coût d’un développement du fait d’une forte dépendance envers les personnes impliquées et leur productivité, …
Dit autrement, il apparaissait que l’effort de design et spécification représentait une part trop importante du coût global des projets, sans avoir prouvé son efficacité : ce design est-il toujours conforme au besoin ? les développements sont-ils conformes au design ?
L’agilité a alors apporté son lot d’avantages qui de facto ont fait le succès de la méthode en valorisant :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
ces principes (le manifeste) se posaient aussi en réaction voire en contestation des méthodes prédictives qui privilégiaient le respect du processus et les livrables sur les individus, le respect du délai-cout-périmètre, …
Quel domaine d’application pour l’Agilité ?
Après des dizaines d’années de mise en oeuvre de l’agilité – qui, plus qu’une méthode, est une transformation de l’état d’esprit, de l’organisation, une acculturation, … – on peut constater que sa mise en oeuvre s’effectue parfois sans se poser la question de son applicabilité au contexte du projet ou du programme, ou du degré d’adaptation qu’on va y introduire pour en tirer les meilleurs bénéfices.
En tant qu’état d’esprit (« mindset ») l’agilité ne s’impose pas, il est souvent préférable d’adopter la méthode des petits pas. Quelle est la maturité de l’organisation vis-à-vis de cet état d’esprit ? ou se situe le curseur de son mindset agile ?
Les spécialistes ou défenseurs d’une méthodologie ne sont pas toujours doués pour identifier les conditions d’application de la méthode : les endroits où la méthodologie passe d’appropriée à inappropriée.
Il est effectivement risqué de partir dans un projet en considérant que tout est prédictif ou prévisible alors que ce n’est pas le cas. Mais il peut être tout aussi risqué de partir sur le postulat inverse, à savoir que rien n’est prévisible.
Il est effectivement risqué d’imposer des spécifications précises à des équipes importantes de développeurs brillants, créatifs, ingénieux, en leur demandant d’être un simple composant d’un ensemble « pré-designé », en perdant toute capacité à bénéficier de leurs talents, en risquant de les démotiver et donc de les perdre …. Mais il peut être tout aussi risqué de partir de quelques objectifs relativement flous et laisser les développeurs travailler sans contraintes, voire parfois avec leurs technologies préférées.
A ce propos le talent des développeurs doit-il se consacrer à développer des composants « techniques » (listes, écrans maître – détail, notifications, …) ou plutôt à trouver des solutions ingénieuses et économiques à des problèmes métiers ?
De quelle échelle parle-t-on ?
Quand on raisonne « à l’échelle », ou au niveau programme, pour que des équipes ou « squad » possèdent une autonomie de méthode pour développer leur « produit », a-t-on préalablement bien défini le périmètre du produit au sens applicatif ou fonctionnel ? – spécialement quand l’existant est par nature monolitique – ses objectifs stratégiques et les règles du jeu pour qu’il s’intègre dans le tout (le système d’information de l’organisation).
Même si les approches micro-services permettent l’hétérogénéité et la modularité cela nécessite d’analyser l’écosystème numérique ou système d’information et l’urbaniser a minima pour trouver la bonne maille au bon niveau entre objectifs métiers et domaines applicatifs.
En parlant d’échelle, dans quelle échelle produit se situer ?
- Prévoit-on de concevoir un produit à fort enjeu business ou réglementaire pour des milliers ou millions d’utilisateurs, avec des services et technologies innovantes qui nécessitera de tester le succès des services proposés et continuellement améliorer et enrichir le produit pour rester dans la compétition ?
- Prévoit-on plutôt de concevoir un produit pour quelques centaines d’utilisateurs, internes à l’organisation, en vue de délivrer un service minimal, puis plus optimal pour ensuite rentrer dans une phase de MCO « économique » ?
Sur quels critères vais je évaluer le succès de mon projet ?
On considère classiquement qu’un projet prédictif est souvent mesuré à l’aune du respect de son plan. Autrement dit l’échelle de valeur est qu’un projet qui respecte les délais et les coûts est considéré comme une réussite, et a fortiori s’il a respecté son périmètre fonctionnel cible.
On considère aussi que cette mesure n’a aucun sens dans un environnement agile : seule compte la valeur commerciale ou métier – ai-je pu délivrer un software qui a plus de valeur que son coût.
Quelle est mon échelle de valeur ? De quel cas mon projet se rapproche le plus ?
On peut en passant noter que même si le discours théorique indique que la variable d’un projet agile est le périmètre fonctionnel, mais qu’on en fixe le coût et les délais, nombre de projets agile ne fixent pas clairement les délais ni même que le coût.
Deux axes de réflexions : requirements / technology
Pour terminer voici une matrice de réflexion, ou autre échelle, qui peut donner matière à se poser des questions utiles (2).
Méthodologie simple ou légère : les exigences ou attentes métiers sont relativement claires et les solutions sont connues – simplicité et efficacité
Waterfall (Cycle en V) ou Kanban (Agilité) : les exigences ou attentes métiers nécessitent d’être clarifiées / analysées et la solution n’est pas entièrement connue
Scrum (Agilité) et/ou Design Thinking : les exigences ou attentes métiers sont floues et les solutions encore inconnues
En synthèse, selon cette matrice l’Agilité commence à porter ses fruits dès que les attentes métiers ou business et les solutions technologiques ne sont ni l’une ni l’autre bien stabilisées. Scrum et Design Thinking sont particulièrement adaptés quand on cherche son périmètre fonctionnel, qu’il est complexe et qu’il faudra prototyper et démontrer des solutions pour y répondre
Sources :
(1) https://www.standishgroup.com/ : The Standish Group, Rapport CHAOS, 2016
(2) bluProfessionals – matrice de Stacey : https://www.bluprofessionals.com/stacey/
