Retour d’expérience : La gestion de projets, conflit des méthodes ?

DevOps & Agilité Jeudi 20 avril 2017 Pas de commentaire

scrum logo

La vague de l’agilité est en train de submerger le domaine informatique, Scrum prend clairement le lead du mouvement.

Ce mouvement est renforcé et/ou lié à l’apparition de l’entreprise libérée : faire confiance au lieu de contrôler, et donc responsabiliser, motiver autrement, s’autogérer, manager au service de son équipe, etc.

Le système de gestion traditionnel basé sur des phases figées et sur une organisation hiérarchique est-il en train de s’écrouler ?

Loin du changement de la structure de l’entreprise, qui est plutôt lié à une évolution du taylorisme, essayons de se concentrer sur les méthodes de gestion des projets, bien que philosophiquement parlant, les choses soient liées.

En termes de gestion de projets, quelles sont les raisons qui ont poussé à ce changement ?

L’approche classique, dite aussi prédictive, a connu des limites dues essentiellement à la complexité grandissante liée à l’environnement projet :

  • Difficulté de faire collaborer des gens qui ne partagent pas les mêmes valeurs, et parfois ne partagent pas la même culture (mode offshoring par exemple)
  • Evolution technologique permanente
  • Impossibilité d’anticiper le comportement de l’utilisateur

Ceci a mis en avant certains principes :

  • L’impossibilité de faire des spécifications complètes en amont
  • L’incertitude est inévitable
  • Le besoin n’est jamais définitivement connu, qu’une fois que les utilisateurs ont utilisé le système

Il est évident que plus le projet est grand, plus le besoin est instable, plus l’utilisateur est imprévisible, et plus l’incertitude est grande.

Devant cette situation, la majorité des organisations et des managers disent que la solution miracle est l’agilité : « il faut enterrer l’ancienne méthode de pilotage et passer à Scrum ! »

D’accord, il faut suivre la vague.

Discutons-en autour de mon retour d’expérience que voici :
j’arrive dans une organisation où la méthode traditionnelle est ancrée depuis des années, je prends en charge le sauvetage d’un projet infecté par l’effet tunnel, qui a consommé le budget prévu et n’arrive pas à décoller.

En résumé :

  • Spécifications terminées depuis longtemps, mais depuis, les règles de gestion ont évolué
  • La majorité des modules sont développés, mais ne répondent pas aux besoins actuels
  • Equipe totalement démobilisée

La solution, c’est d’être agile. Je réorganise le projet en releases et en sprints, je fais ma proposition au « grand » chef, qui est content d’avoir enfin Scrum chez lui, il valide, mais demande :

  • Q : et pour le budget, on fait quoi ?
  • R : Il nous faut au moins deux sprints pour avoir la vélocité de l’équipe et pouvoir estimer le nombre de sprints nécessaires par release.
  • Q : Malheureusement, le sponsor exige d’avoir le budget, avant toute action !

Retour à la case départ ! Scrum permet bien d’avoir un « sprint initial », qui n’est pas vraiment un sprint, mais plutôt la phase d’initialisation du projet. Lors de ce « sprint 0 » on définit la vision produit, on détecte les « features », les parties prenantes, les impacts produit sur les parties prenantes, le mapping « stories / features » (au moins pour la première release), les technologies, les outils, les équipes et peut être un prototype (MVP : Minimum Viable Product). En résumé, tout ce qu’on fait lors du démarrage d’un projet traditionnel, à part qu’on évite de détailler les spécifications. Cette étape, permet d’estimer les nombres de sprints et le nombre de releases, et en conséquence le budget. Etant donné que les spécifications ne sont pas détaillées, la marge d’erreur est grande, ce qui demande de revoir le budget un peu plus tard.

Mais, dans notre cas, les spécifications sont là, pas totalement correctes, mais suffisantes pour faire une estimation plus proche de la réalité : bienvenue à la méthode prédictive !

Partant des spécifications et de la version déjà implémentée, nous avons pu estimer un budget réaliste.

Finalement, l’agile ne coupe pas totalement avec l’ancienne méthode. C’est l’approche qui change, et c’est peut-être le plus important ! 

 

Budget validé, aux sprints, alors !

Nous avons extrait les « features » de l’ancienne spécification, nous les avons priorisées selon les parties prenantes. En amont de chaque « sprint », les spécifications des « features » priorisées sont revues et corrigées. À la fin de chaque « feature », on présente un résumé des fonctionnalités sous forme de « stories ». C’est en se basant sur ces résumés que le backlog est défini et les stories sont priorisées. Les détails ont servi pour l’équipe et ont facilité la tâche du business, pas toujours disponible.

Nous avons, alors, démarré les cycles de nos mini-projets, de nos sprints. Il s’agit bien ici d’un mini-projet avec son « SACTC » (Spécification, Architecture, Codage, Test, Clôture). Par clôture on entend : revue de sprint, réunion rétrospective, et mise ou non en ligne.

Finalement, l’agile ne coupe pas totalement avec l’ancienne méthode. C’est l’approche qui change, et c’est peut-être le plus important !

 

Et les risques ? Rien dans Scrum n’empêche d’identifier les risques dès le sprint 0. Le cycle court, ne fait que minimiser l’impact de ces risques ou mieux les éviter. La notion d’obstacle est bien traitée dans Scrum et cela rejoint l’identification et le traitement des risques au cours de l’implémentation.

Les KPIs ? Ils ne sont plus les mêmes ! Scrum a ces propres KPIs plutôt dirigés vers l’équipe (Burndown, vélocité, etc.). Mais, Scrum n’interdit pas de définir des KPIs orientés vers l’extérieur. Pourquoi en définir des nouveaux ? Il suffit d’utiliser ce que propose l’ancienne méthode (la méthode prédictive) : rien n’empêche de calculer les fameux PV (Planned Value), AC (Actual Cost), EV (Earned Value), etc. Ces indicateurs seront efficaces surtout à l’échelle d’une release.

Finalement, l’agile ne coupe pas totalement avec l’ancienne méthode. C’est l’approche qui change, et c’est peut-être le plus important !

 

Un schéma vaut mieux que milles pages. Je vous laisse comparer les deux flux de processus simplifiés. Focus sur les carrées bleus

image 1

 

image 2Alors ? Apparemment, rien n’a changé ?

Il n’y a pas de re-planification pour le sprint, c’est normal car on va le planifier au début du prochain, ce que nous fait une re-planification et intégration des changements au sens release.

Donc, rien ne change, sauf l’approche. Mais quelle est cette approche ?

Pour le savoir, un petit état des lieux :

  • L’équipe est contente d’avoir toutes les fonctionnalités dans un seul endroit, contente d’être focalisée sur son sujet tout au long du sprint, d’avoir suffisamment de détails sans que la porte des suggestions ne soit fermée
  • Les utilisateurs sont contents de tester rapidement et d’avoir des fonctionnalités qui marchent. Ils ont plus de confiance dans l’équipe de Dev (Développement). En plus, maintenant, ils peuvent les contacter directement. Bien sûr, il y a toujours la tentation de demander un petit changement, une nouvelle petite fonctionnalité (très facile à développer), mais l’équipe Dev a appris à se focaliser sur l’objectif : « Merci d’ajouter cette nouvelle demande dans le bac à sable, par contre pourrions-nous discuter de ce que je suis en train d’implémenter ? »

En effet, cette approche a changé de telle sorte que :

  • L’utilisateur communique directement avec le développeur
  • Il n’y a plus des taches urgentes : tout est renvoyé vers l’étape de priorisation et planification du prochain sprint (prochain mini-projet)
  • Les changements sont les bienvenus, mais pas à tout moment
  • L’équipe est plus responsabilisée et motivée pour atteindre l’objectif du sprint

Scrum semble couper avec l’ancienne méthode, mais pas totalement :

  • On a gardé les composants, mais en plus petits : décomposer pour mieux régner
  • On a gardé les processus, les phases, les équipes, mais en plus décomposés et en plus simple (au moins, en apparence)

Bien sûr, il y a un nouveau vocabulaire, le processus de mangement de la communication semble changer et le contrôle qualité aussi. De plus, il n’y a plus de hiérarchie : on revient à la notion de l’entreprise libérée, ou à une échelle plus petite, la notion du projet libéré.

Je vais peut-être vous décevoir, mais Scrum n’a rien changé, il a juste modifié la façon de mettre en musique toutes les activités de l’ancienne méthode, ET C’EST DEJA ENORME !!

Scrum n’est pas une méthodologie de pilotage. C’est juste un cadre où on doit adapter/marier nos méthodologies (prédictives, Xterm programming, Kanban), tout en respectant les principes et les valeurs Scrum. Donc, continuez à utiliser vos KPIs, vos estimations, détailler un peu plus les spécifications en amont s’il le faut. Scrum n’est pas incompatible avec la méthode classique sur les pratiques, mais plutôt au niveau des valeurs !

Pour ne pas oublier notre sujet : finalement notre première version (release) est prête. Le business et les Dev sont contents d’aller en PROD (production). Sauf, que « Il faut attendre un mois, car notre release est lié à un autre système, qui ne sera pas en prod avant un mois ! »

Il faut changer encore, et c’est toujours l’approche qu’il faut changer, car les outils sont là : peut-être, parlera-t-on Devops dans un prochain billet ?!

 

 Par Mabrouk HARABI, chef de projet senior chez AXONES

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn