Installer Scrum sur une organisation existante

De plus en plus d’entreprises s’intéressent à la mise en œuvre d’un processus de développement agile, en particulier SCRUM. Elles pensent y trouver une méthode qui leur permettra, soit de combler les lacunes de leur processus de développement, soit de faire encore mieux que ce qu’elles savent faire. Cependant, il arrive fréquemment que des personnes se sentent exclues par le nouveau mode de fonctionnement. Deux profils particuliers sont concernés : les chefs de projet MOE et les MOA.

Nous proposons ici des réponses à des questions récurrentes comme « que devient l’activité MOA » et « à quoi sert ce chef de projet ? ».

Que devient le chef de projet MOE ?

Alors que l’équipe travaille en direct avec le Product Owner sur le chiffrage du produit, sur la qualification des demandes et sur l’affectation des tâches de développement, le chef de projet voit son périmètre d’autorité fondre au fil du temps. Quel rôle peut-il alors envisager au sein de ce type d’équipe ?

Il faut envisager une évolution des activités du chef de projet tel que défini dans nos organisations. Son activité de pilotage va changer pour utiliser des indicateurs de suivi dits agiles (valeur métier dégagée, complexité restante, stabilité de la vélocité, …). Celle de planification le rapprochera de la MOA, qu’il accompagnera dans la définition d’une roadmap agile. Toutes ses activités doivent lui permettre de conserver son implication dans le projet.

Une autre solution pour le chef de projet consiste à devenir un facilitateur pour son équipe. Le facilitateur est un manager agile : son rôle est de mettre en place un environnement de travail permettant à l’équipe de tenir ses engagements. Il doit être capable d’écouter, d’orienter et de conseiller chacune des personnes avec qui il travaille : faire tout ce qui est nécessaire pour maximiser la productivité des membres de son équipe. De premiers éléments peuvent être trouvés dans le livre Behind Closed Doors, d’Esther Derby et Johanna Rothman.

Que devient l’activité MOA ?

L’autre population qui est mise en porte-à-faux lors du déploiement de SCRUM : la MOA. Là aussi, le rôle de MOA tel que nous le connaissons est en grande partie absorbé par l’équipe : clarification du besoin, qualification des demandes, tests, … Quelle position la MOA peut-elle alors adopter pour continuer à apporter de la valeur à un projet ?

La solution en laquelle nous croyons aujourd’hui est que la MOA soit partie intégrante de l’équipe. Les activités de la MOA dans une équipe agile sont :

  • la définition de la roadmap du produit (définition des jalons fonctionnels)
  • l’animation d’ateliers avec les utilisateurs pour bien comprendre le besoin
  • la transformation des fonctionnalités en User Stories avec le Product Owner (qui peut être un profil MOA)
  • la mise en place d’un échantillon de données représentatives pour les tests
  • la définition des critères d’acceptance pour chaque User Story
  • la conservation de la maîtrise fonctionnelle globale du produit (documentation du métier implémenté)
  • la conduite du changement très tôt dans le projet

L’activité de définition des critères d’acceptance peut être encore plus valorisée par la définition de tests fonctionnels automatisés à l’aide d’outils comme FitNesse ou GreenPepper. A tout moment, ces tests peuvent être exécutés pour fournir un état d’avancement du projet. Ils permettent aussi aux développeurs de disposer d’un indicateur clair pour savoir si ils ont terminé ou non leurs développements.

De cette manière, la MOA conserve son rôle d’intermédiaire entre le fonctionnel et le technique, tout en réduisant les temps de recette (via l’automatisation des tests), et donc participe à la réduction du temps de cycle.
L’accompagnement par un coach peut être nécessaire, à la fois pour accompagner le changement et pour former les MOA à ce nouveau mode de fonctionnement (outils, méthode de travail, mode de pensée, …).

Dans des DSI de 500 personnes, il est aujourd’hui difficile de penser que l’équipe SCRUM/XP « by the book » soit généralisable à court terme. Il est donc possible d’envisager des positionnements différents des acteurs actuels, en leur permettant de continuer d’apporter de la valeur, tout en orientant progressivement le processus de développement vers un processus agile.

Quelques ressources en relation avec cet article

  • Session USI 2008, « le Facilitateur, un rôle encore méconnu » par David Gageot
  • Session USI 2009, « Maîtrise d’ouvrage et agilité » par Eric Pantera
  • Session USI 2009, « La boite à outils du manager IT » par Alain Buzzacaro

A noter aussi le 24 Mars 2009, le petit-déjeuner organisé par OCTO « SI et Innovation métier » où Generali nous apportera un témoignage sur la mise en place de SCRUM.

2 commentaires sur “Installer Scrum sur une organisation existante”

  • Pour ma part, la MOA telle qu'on l'entend à la française doit être en soutien du Product Owner. A cet égard, même s'il est essentiel que le Product Owner ne parle que d'une seule voix, j'ai tendance à recommander la mise en place d'une véritable équipe "Product Owner", dont la MOA, l'ergonome, le Business Analyst font partie intégrante... Quelques réflexions sur cette question: http://www.qualitystreet.fr/2008/10/27/maitrises-d-ouvrage-decollez-avec-les-methodes-agiles/
  • Que devient le chef de projet dans Scrum? - charte du projet: rédigée par le PO et le SM - contenu du projet: rédigé par le PO et revu avec l'équipe - délais du projet: gérée par l'équipe et supervisée par le SM - coût du projet: géré par le PO - qualité du projet: géré par l'équipe et le PO - ressources humaines du projet: PO et SM - communication du projet: PO - risques du projet: PO - approvisionnements du projet: SM donc, le chef de projet dans Scrum, c'est la Scrum Team MOA/MOE: concepts français? Dans les projets internationaux, la MOA est traduit par la PMO et la MOE n'a pas vraiment de raison d'être. La seule vraie différence entre Scrum et les autres méthodes c'est que les tâches sont redistribuées au sein de l'équipe et que l'organisation est construite entre lignes de produit (cf. MetaScrum). La Governance en mode agile ne suit que 2 métriques: le temps et le coût (cf. Earned Value Management et AgileEVM). Les seuls points critiques dans une SI agile est la gestion de portefeuilles: en effet, le voyant orange disparaît (half done is not done). Il serait temps de laisser parler les chefs de projets agiles et pas uniquement les développeurs. Non? ;)))
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha