L’agilité occupe aujourd’hui le devant de la scène. De plus en plus d’entreprises s’y intéressent et souhaitent la déployer plus largement, au-delà même de leur département IT.

Si la méthode peut sembler facile, la démarche n’en reste pas moins complexe. Devenir agile ne s’improvise pas. Quels sont les pièges à éviter pour une transition réussie ? Comment les anticiper ?

Lors d’un webinaire, trois de nos auteurs, spécialistes du sujet, nous ont présenté les notions fondamentales à maîtriser et les écueils à éviter pour une transition agile réussie.

Vos questions/ Leurs réponses

Réponses de Gilbert Le Guillouzic

1. Agilité = nouvelle méthode ?
Je croyais que l’Agilité n’était pas une méthode mais un cadre…

Oui, si l’on veut être puriste, il faut parler de cadre, mais je dirai plutôt que le cadre intègre les méthodes agiles. Par exemple, le plus grand principe des méthodes agiles est de diviser le projet en itérations courtes (nos sprints) pour pouvoir livrer rapidement. Pour que tout ce mécanisme fonctionne parfaitement, s’ajoutent les artefacts qui constituent les fondations des méthodes agiles (les sprints, les cérémonies). C’est cet ensemble qui nous donne un cadre. Quand on arrive à adapter le cadre à notre contexte, tout en respectant le manifeste agile, on baigne vraiment dans la philosophie agile.

2. Il doit y avoir de l’accompagnement au changement. Mettre en place l’agilité en faisant de l’agilité ?

Si  l’on souhaite préparer son basculement agile façon cycle V, on risque de reporter sans cesse le basculement sous prétexte que telle ou telle partie n’est pas encore claire. Au lieu de tenter de tout préparer d’un coup pour ensuite faire son basculement façon Big Bang, il vaut mieux procéder étape par étape et cette façon d’avancer étape par étape, petit bout par petit bout, c’est déjà procéder de façon empirique et c’est bien un procédé agile.

3. Peut-on tout construire en agile ?

De plus en plus d’entreprises qui ne viennent pas du monde informatique se mettent à faire de l’agilité. Déjà dans les années 50, au Japon, chez Toyota, Taiichi Ohno et Shigeo Shingo ont introduit le concept agile de Lean Startup ! À l’époque, cela avait révolutionné la production automobile de Toyota. Imaginez maintenant que, dans le projet « Mission sur Mars », on dise aux astronautes que sur le sprint 1 on se focalise sur le décollage, ensuite, au sprint 4, on commencera seulement à s’intéresser aux retours sur terre. À mon avis, nos astronautes ne signeront même pas pour le sprint 1…
L’agilité peut s’incruster dans tout secteur d’activité où l’on peut livrer rapidement, fréquemment et de façon incrémentale.

Réponses de Stéphane Badreau

4. En agile, peut-on avoir des obligations de résultat avec des objectifs calendaires forts ?

En agile, le délai est fixe, ce qui a priori n’est pas antinomique, voire plutôt une bonne nouvelle dans un environnement avec une contrainte calendaire forte, comme par exemple des exigences liées à la réglementation. Les exigences avec une contrainte de temps devront très certainement être traitées en priorité haute dans les différents itérations afin d’assurer leur livraison dans les temps. Ensuite, c’est aussi une question de gestion des risques : quel risque prend-t-on à ne pas être dans les temps ? est-ce préjudiciable pour l’organisation ? l’organisation sera-t-elle soumise à des pénalités ou des amendes ?

5. Peut-on utiliser la méthode classique et agile dans un même projet selon les phases du projet ?

Oui, tout à fait, il est possible par exemple de réaliser l’étude d’opportunité et le cadrage avec des phases séquentielles (comme dans un projet traditionnel) et de poursuivre la réalisation et les tests de manière itérative et incrémentale (en mode agile). Dans ce cas, on parle d’approche hybride.

6. Quelle littérature conseillez-vous sur l’ingénierie des exigences ?

Mon livre paru aux éditions Dunod en 2014, intitulé « Ingénierie des exigences – Méthodes et bonnes pratiques pour construire et maintenir un référentiel ».

7. Comment documenter une exigence qui change quelque peu régulièrement en contexte projet où le métier ne parvient pas à clarifier son besoin à l’entame du projet ?

On parle d’instabilité des exigences dans ce cas. Cela peut provenir de plusieurs causes :

1/ l’analyste ne mène pas efficacement l’activité d’élucidation par méconnaissance de méthodes et de techniques. Par exemple, la stratégie d’élucidation et d’affinage des exigences n’est peut-être pas la bonne.

2/ à l’entame du projet, il peut être normal que le besoin ne soit pas très bien défini, il faut dans ce cas procéder par étapes successives et faire valider au fur et à mesure l’avancée des travaux (activité de validation des exigences). L’adoption d’une bonne stratégie d’affinage peut également permettre un éclaircissement sur les exigences.

8. Quels éléments de la présentation rependriez-vous, ajusteriez-vous, ou quels sont ceux que vous ajouteriez pour la mise en place d’une organisation DevOps ?

DevOps (ou plus largement DevSecOps) est une pratique qui consiste à rapprocher le monde du développement de celui des opérations (intégration, delivery, mise en production, release). C’est une pratique complètement intégrée à SAFe (dans sa version v5) et je n’apporterai pas de modification à ma présentation. Tout au plus, concernant les besoins et l’ingénierie des exigences, cela se traduit par une attention particulière aux aspects non fonctionnels (qualité du code, auditabilité, testabilité, supervision…).

Réponses d’Edgard Maillot

9. Existe-t-il des domaines /services dans lesquels cette méthodologie n’est pas pertinente ?

L’agilité est issue de l’industrie (TPS: Toyota Production System) et est applicable à tous les domaines d’activité. En revanche, faire du Scrum n’est pas pertinent partout. Parfois, il est préférable de faire du Kanban ou même utiliser d’autres cadres de processus. Dans tous les cas, s’appuyer sur une démarche Lean engendrera un accroissement de performance et/ou une réduction des délais (Time to Deliver).

10. Qu’en est-il du rôle de Chef de Projet (Prince2) avec l’approche agile ? Est-ce antinomique ? Est-ce un concept qui “disparaît” de fait ? Il y a clairement un conflit entre le rôle de manager (PO, Scrum Master) et Chef de Projet.

C’est antinomique avec Scrum ou SAFe, mais pas avec l’agilité. Vous pouvez avoir une entreprise agile et des projets agiles avec des chefs de projets. Mais pas dans un cadre Scrum.

11. Peut-on développer un produit (logiciel ou système informatique) avec des sous-traitants et engagement de leur part en coûts et délais (ce qu’on appelait en méthode classique les projets au forfait ou clés en main)?

Oui, mais comme l’a expliqué Stéphane, en cas de nouvelles demandes ou d’évolution de la demande, le sous-traitant ajustera le périmètre, plutôt que de produire des avenants impactant le coût/délai. Attention donc à la manière de contractualiser.

Formation CPF

Scrum : Maîtriser la méthode Agile