t0 : Choix et mise en place de la méthode Scrum dans notre organisation

De Fabien Gaujous dans Méthodes et Organisation

10 juin 2013

iMDEO devait choisir une méthode intégrant à la fois une possibilité de réponse plus adaptée vis-à-vis du client (très adaptative et réactive), et s’adaptant aussi à notre contexte d’équipe.

Pour bien comprendre la façon dont iMDEO a initié l’agilité, il est important de connaitre son contexte : L’équipe est constituée de développeurs (JAVA, PHP), de webdesigners, et de chefs de projet, dans un contexte de multi projets à technologies multiples.

Nous avons choisi la méthode Scrum. L’idée d’utiliser Scrum dans notre organisation nous paraissait être la solution idéale pour produire des applications. Cependant, il a fallu absorber les nombreuses informations sur le sujet (formations/conférences/Barcamp…) afin de s’imprégner de ce processus et ainsi, le modifier pour correspondre au mieux à notre organisation. En effet, de nombreuses formations expliquent la méthode Scrum dans les règles de l’art, et sont souvent présentées avec une seule équipe de 5 personnes en moyenne sur un projet unique d’une durée assez longue, ce qui ne correspond pas à notre contexte.

Voici comment cette méthode a été mise en place dans notre contexte :

Les acteurs

Tout a commencé par la formation de l’ensemble de l’équipe projet  à la méthode Scrum. Suite à cela, les différents rôles de la méthode Scrum ont été assignés à chaque membre de notre équipe :

  • Développeurs
  • ScrumMaster
  • Product Owner (PO) Proxy

Les développeurs

Dans la méthodologie traditionnelle, le développeur v1.0 répond aux besoins exprimés par le chef de projet qui « détient le savoir » et la prise de décision. Il se considère comme un exécutant, réalisant dans les règles de l’art le développement demandé sur la base d’un cahier des charges dument complété et décrit.

En méthode agile, le développeur 2.0 fait partie intégrante du processus d’écriture de la user story, dans le sens où il peut interagir de façon beaucoup plus importante avec le PO, en posant des questions et des hypothèses, des prérequis et des contraintes, afin d’évaluer au mieux la charge inhérente à la demande.

Ainsi, le mode interactif est beaucoup plus présent, et de fait la prise de responsabilité et d’engagement plus forte.

Le ScrumMaster

Nous avons défini que le ScrumMaster, dans notre contexte fait partie  de l’équipe de développement.

Son rôle:

  • Favorise la collaboration entre tous les membres de l’équipe
  • S’assure que l’équipe travaille dans de bonnes conditions
  • Protège l’équipe contre les interférences / multi tâches
  • Garantit la bonne application du processus SCRUM
  • Collabore étroitement avec le(s) Product Owner(s)

Au départ, l’équipe a décidé de changer de ScrumMaster à chaque sprint afin que chacun puisse bénéficier de cette expérience mais également que ce ne soit pas toujours la même personne qui soit dérangée durant le sprint.

Il n’est pas rare que le  scrumMaster soit un chef de projet déguisé ou officiel qui  applique un contrôle trop strict sur les membres de son équipe.

Les Product Owners (ou POs) Proxy

Les chefs de projets sont devenus des Product Owners Proxy. Ils sont les garants de la valeur du produit.

Pourquoi POs Proxy, et pas POs tout court,  me diriez-vous ? Nous avons considéré dans cette phase que les vrais POs sont les clients. Ce sont eux qui définissent la valeur du projet. Or, dans la réalité, nos clients ont rarement le temps de se prêter au jeu de la méthode (à l’exception de ceux qui l’ont choisie et qui en connaissent les vrais bénéfices).  C’est pourquoi nous avons adopté la notion de POs proxy. Ils sont les principaux interlocuteurs de nos clients et ont la responsabilité de :

  • Ecriture et réajustement du backlog avec l’aide du client.
  • Participation aux cérémonies
  • Lien entre le PO client et l’équipe

 

Organisation

Une fois les rôles définis pour chacun des membres de l’équipe, Des sprints d’une durée de 2 semaines ont été établis (2 semaines nous semble être la bonne durée).

Planning

Nous avons défini qu’un sprint se décompose de cette façon sur 10 jours ouvrables:

planning agile imdeo

planning agile imdeo

Organisation des POs

Comme indiqué précédemment nous avons une seule équipe travaillant sur plusieurs projets.
Ainsi, en amont du Sprint Planning, les Pos Proxy se rencontrent pour exposer la liste de leurs projets ainsi que la charge estimée, leur priorité et les deadlines des clients. A la fin de cette réunion, une liste de projets triés par priorité est définie avec les User Stories associées (les users stories constituent la description de chaque demande fonctionnelle, écrite dans un format déterminé).
Cela constitue une évolution des modèles classiques où c’était le responsable de production qui arbitrait pour l’ensemble des chefs de projets, sans forcément reléguer le niveau d’importance d’un projet par rapport à un autre.

Evaluation des projets par l’équipe

Cette évaluation est réalisée dans le Sprint Planning :  Les membres de l’équipe de production (en fonction des expertises) participent  à l’estimation de toutes les User Stories (l’estimation consiste à évaluer le niveau de difficulté de la demande et de lui attribuer une quotation, ici en points). Le but est de permettre un dialogue dans l’équipe,  et de pouvoir, si possible,  éviter les ressources critiques (1 seule personne capable de travailler sur un projet).

L’équipe décide alors ce qui pourrait rentrer dans le Sprint en dialoguant avec les POs une fois les User Stories valorisées.

A la fin de la journée, toutes ces User stories sont affichées sur le scrum board dans l’ordre des priorités.

Le Sprint commence dès le lendemain ! Cette journée est longue et énergivore pour tout le monde.

Scrumboard t0 iMDEO

Scrumboard t0 iMDEO

Les démos

Les démos s’effectuent à la fin du Sprint.

Chacun des POs programme une démonstration de ce qui a été développé  avec les membres de l’équipe qui ont travaillé sur chacun de  leurs projets. Cette cérémonie permet de valider ou rejeter les US stories.

Les démonstrations étaient  animées au début par les POs proxy. Nous verrons par la suite que cette option  ne contribue pas à la prise de responsabilité des développeurs par rapport à leur propre développement.

Rétrospective & slack-day

Le dernier jour est nommé « Slack Day ». Il  permet de finaliser le Sprint  en gérant les retours donnés par les Pos au cours de la démo.

Cette journée permet aussi d’effectuer de la veille  sur des sujets qui sont en adéquation avec les orientations techniques de la société.

Les US non validées sont replanifiées dans le sprint suivant.

La maintenance

L’organisation décrite précédemment permet de gérer les développements de nouveaux projets ou des évolutions planifiées et devisées.

Cependant, nous avons un certain nombre de contrats de maintenance, qui prennent en charge des  évolutions ou des bugs. La gestion de la maintenance est un sujet qu’il faut introduire dans l’organisation globale des équipes pour impacter à minima le Sprint en cours.

La méthode Scrum prône le fait que l’équipe de développeurs ne soit pas dérangée lors du Sprint : seul le ScrumMaster fait barrage pour la protéger.

Ainsi, l’équipe a décidé de nommer, à chaque Sprint, une personne en charge de la maintenance, qui n’est pas inclus dans les ressources du Sprint.

Et après ?

Il s’agit ici de notre 1ere organisation qui a duré une année, et durant laquelle nous avons pu faire, grâce aux rétrospectives, une analyse des points d’améliorations à envisager

L’article suivant traite des problèmes rencontrés lors de cette première phase.

 

Commentaire

neuf × 3 =