Articles

Leçon N°13 : appliquer les 4 règles d’or de la méthode SCRUM

 SCRUM est un nom barbare pour une méthode originale de management agile.

Les méthodes de gestion de projet sont nombreuses mais on constate qu’il n’est plus possible de gérer les innovations à l’ancienne avec de grands projets s’étalant sur douze à dix huit mois et mobilisant d’immenses équipes. En 2005, Apple a développé l’OS de l’IPHONE avec une équipe de 60 personnes alors que Motorola faisait du « sur place » avec 1500 ingénieurs et que Nokia était victime des lourdeurs de sa gouvernance pour se décider.

Depuis 10 ans, les DSI ont testé et mis en place la méthode SCRUM qui vise à découper un grand projet en chantiers à taille humaine puis en sprint (micro-chantiers). La méthode des lots de travaux n’est pas nouvelle mais SCRUM apporte des enseignements sur le management de projet. CESAR est la solution applicative de pilotage du portefeuille du projet qui permet un management agile des projets

Règle d’or N°1 : ceux qui évaluent sont ceux qui réalisent

Ce n’est pas le chef de projet qui évalue le reste à faire mais ce sont les équipiers qui évaluent la complexité et qui s’engagent sur un résultat en tenant compte de leur capacité à faire (CAF). Cela peut paraître subtil ou peu important mais dans les faits cela change tout.

Un trop grand nombre de chefs de projet réalisent des estimations en aveugle sans tenir compte de la capacité à faire, des compétences réelles des équipiers et de la motivation du moment. On constate des erreurs de chiffrage sur le plan de charge, des restes à faire qui ne diminuent pas et des pertes de motivation voir d’engagement.

CESAR permet de comparer la capacité à faire (disponible planifié par les équipiers) au reste à faire (effort nécessaire pour terminer un livrable validé par le chef de projet sur la base des estimations des équipiers).

Règle d’or N°2 : les équipes sont mixtes et soudées afin d’éviter les débats d’experts interminables

L’ingénierie du logiciel est un métier difficile où il faut sans cesse se mettre à la place de l’utilisateur et imaginer comment on va pouvoir lui simplifier la vie. Dans le cadre des estimations (méthode du Poker Planning), on mélange les experts et les novices afin d’éviter les débats trop techniques, et on cale les discussions dans des espaces temps limités (Time-Boxer). Les équipes métiers sont imbriquées avec les équipes techniques pour former un tout cohérent et agile.

La solution CESAR permet de gérer des chantiers mais également des micro-chantiers (Sprint en SCRUM mais également groupe de travail). L’équipe partage un objectif et un plan d’action. Elle est engagée sur un livrable clair et précis. On recommande de conduire des rétrospectives en équipe afin de partager points réalisés et points bloquants. CESAR permet de formaliser ces informations dans un FLASH REPORT.

Règle d’or N°3 : le système est découpé en sous-systèmes qui seront réalisés dans le cadre d’un SPRINT (durée de 4 à 7 semaines).

La méthode Agile suppose d’avoir en amont une bonne vision de l’architecture du système. Dans l’industrie, on l’appelle organigramme technique (OT) ou « product breakdown structure » (PBS). Cette approche d’architecture a été appliquée sur le système d’information et l’entreprise où on rencontre des « architectes » d’entreprise qui vont découper et piloter les briques métier. La maintenance de ces briques est alors réalisée dans des SPRINT, c’est à dire des morceaux de projet à taille humaine (équipe de 7 à 10 personnes), à durée limitée (5 à 7 semaines) et avec des spécifications détaillées précises (Backlog) pour atteindre un résultat précis et tangible. Cela peut être une V0 d’un logiciel qui constituera le squelette. On lancera alors un deuxième SPRINT pour réaliser une V1 qui apportera de nouvelles fonctions ; on est dans le versionning classique mais avec des règles de management (équipe réduite, durée courte, organisation simple) qui garantissent le résultat dans les délais.

CESAR permet de piloter la ROADMAP de l’entreprise en fixant les grands jalons  de l’année et les résultats de l’année. Il est possible ensuite dans une logique de poupées-russes d’analyser le détail à différents niveaux : processus, projet, chantier, micro-chantier, livrables. 

Règle d’or N°4 : un engagement de résultat de l’équipe qui va développer sa vélocité et sa véracité sur une durée courte de 5 à 7 semaines.

La méthode agile positionne une équipe dans un périmètre et un objectif clair (TIME BOXING). Les dérives de coûts sont faibles mais surtout l’échec est peu envisageable. L’équipe s’est mobilisée personnellement et collectivement dans une approche d’engagement librement consenti. Le sprint est dans une logique de montée en charge rapide sur le résultat à atteindre et on constate souvent des situations de dépassement de soi pour terminer. Cet engagement est lié à la durée courte du sprint et à l’envie de créer / réaliser un résultat concret en équipe.