Et si le meilleur atout d’une méthode agile, c’était une méthode classique?

Avez-vous déjà essayé de vendre à un DAF un projet de développement dont on ne connait ni les contours, ni les coûts ni la date de fin?

Évidemment, présenté comme ça c’est un peu brutal. Mais qu’est-ce que voit un décideur d’un projet agile si ce n’est exactement ça? Et je ne parle pas des financiers, à qui la démarche est le plus souvent totalement étrangère.

Bien sûr ce n’est pas ce que dit SCRUM (80% des projets de développement agiles s’appuient sur SCRUM). Mais dans les faits, c’est pourtant bien ce qui se passe car les entreprises ne sont pas toutes en mode agile. Elles ont besoin de visibilité, les différents acteurs ont du mal « payer pour voir »: il faut convaincre et pour convaincre il faut montrer.

Deux cas assez fréquents où il faut donner de la visibilité: lorsque l’entreprise souhaite expérimenter/adopter une méthode agile, et lorsqu’on a vécu un échec après l’avoir expérimenté. Dans les deux cas il y a une attente forte de contrôle.

Il n’y a pas dans SCRUM d’étape sur le contrôle. Les Sprint Reviews et Sprint Rétrospectives sont bien des jalons où des feedbacks sont générés respectivement sur les fonctionnalités et sur la méthodologie. Mais c’est très insuffisant pour (re)donner confiance et avoir de vraies perspectives.

Ce contrôle est d’ailleurs utile aux équipes qui ont souvent, elles-aussi, besoin de se rassurer. Pensons par exemple au Product Owner, qui porte seul la responsabilité de l’atteinte des objectifs du développement agile: que peut-il faire pour garantir l’alignement du développement avec les objectifs de l’entreprise? Comme va-t-il chercher le financement? Comment fait-il la preuve que ces objectifs ont été atteints? Comment formule-t-il ces objectifs? Comment fait l’équipe de développement, qui doit embarquer assez souvent des évolutions extérieures au projet agile? Comment l’équipe gère-t-elle la non-disponibilité des parties prenantes et leur motivation (rappel: le Scrum Master n’est pas un manager et la Development Team est auto-suffisante)?

Dans la vraie vie, la Dévelopment Team n’est pas dédiée; elle ne dispose pas de toutes les ressources nécessaires: parce qu’elles n’ont pas besoin d’être présentes tout au long du développement et/ou parce que ces ressources sont toujours mutualisées avec d’autres projets.

Autant de questions fondamentales qui n’ont pas de réponse dans SCRUM. Autant de sources de dysfonctionnement et les équipes ne sont pas armées pour y faire face.

Finalement de quoi parle-t-on? On parle de recentrer les équipes agiles sur leur cœur de métier: le développement. Mais développer une application ce n’est pas seulement écrire du code. C’est aussi gérer des risques, respecter une feuille de route, rendre compte d’un budget. Bref, c’est gérer un projet.

N’en déplaise aux puristes, la meilleure façon de gérer un projet de développement agile, c’est de l’encadrer avec une gestion de projets classique.

Je sais ça fait tâche. Mais c’est du bon sens: A moins que l’entreprise ne choisisse de consommer un certain budget « pour voir » et que le périmètre du développement soit vraiment restreint, faire du pure agile est très risqué.

Comment faire?

Tout le monde a depuis longtemps fait la correspondance entre classique et agile via les Sprints: les Sprints sont en agile ce que les Séquences sont en classique (pour PRINCE2 par exemple). Et finalement, l’équipe spécialiste de PRINCE2 c’est la Development Team de SCRUM. Mais comment réconcilier la vue court-terme de SCRUM avec la vue long terme de PRINCE2?

En fait, il y a un point de contact naturel: le Sprint Goal. A chaque début d’itération (Sprint Planning), la Development Team définit les objectifs du Sprint à venir dans un Sprint Goal. Ce Sprint Goal permet à l’équipe de développement de « garder le cap », et ne pas oublier les objectifs du Sprint pendant son exécution.

Ce Sprint Goal est un excellent moyen de confronter le périmètre à réaliser dans le projet et le périmètre réalisé dans le Sprint. Visuellement, c’est lui qui fait le lien dans un Plan Projet classique avec les objectifs de la Development Team. On a ainsi tous les outils pour donner de la visibilité à l’entreprise, voire au sponsor du projet de développement (rôle décrit nulle part dans SCRUM bien évidemment).

Alors? Est-ce que le meilleur atout d’une méthode agile, ce n’est pas une méthode classique?

En savoir plus: Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/formation-certification/gestion-de-projet/23-SCRUM-methode-agile/certification-professional-scrum-master-PSM1/

Répondre

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s