Chez Public-Idées, à Bordeaux, c'est désormais une ruche. Les questions fusent devant des tableaux tapissés de Post it, les débats sont vifs dans les stand-up meetings, les discussions fleurissent entre développeurs dans l'open space. Le pôle technique (16 salariés), du spécialiste du marketing à la performance qui conçoit et fournit des logiciels maison au siège de Levallois (56 salariés), se heurtait depuis des années à des bogues à répétition, à des retards incontrôlés et à une sévère chute de motivation dans les rangs.

Mais en 2011, cette unité a su redresser la barre grâce à Scrum. Une méthode agile de gestion de projets qui a le vent en poupe en France depuis huit ans, en particulier dans les start-up, mais aussi à présent de plus en plus dans les bureaux d'études et de R&D des entreprises. Son atout principal : être plus axé sur les interactions des personnes entre elles que sur les processus, pour gagner en vélocité et en qualité.

« C'est une approche simple, pragmatique, flexible, qui a été bien formalisée et qui parle à beaucoup de gens », souligne Jean-Noël Chaintreuil, consultant en innovation RH.

Utilisée dans la Silicon Valley, elle est, selon des observateurs, la méthode d'innovation la plus aboutie après les procédés Extreme Programming, RAD, DSDM dédiés à l'ingénierie des logiciels depuis les années 1990 et, de fait, très techniques.

Un travail par cycles itératifs orientés client

L'objectif du nouveau directeur technique de Public-Idées à Bordeaux, Fabien Barbaud, était double : relancer ses équipes dans l'action et satisfaire son client en le remettant au centre du jeu. Scrum, un terme emprunté à l'univers du rugby et qui signifie « mêlée », se prête bien à ces exigences.

« L'équipe va en effet travailler de façon collective, elle doit être soudée, tournée vers un même but et se passer la balle à bon escient, explique l'expert Jean-Noël Chaintreuil. En outre, la méthode orientée résultats est au service du client (interne ou externe), dont les demandes sont intégrées dans le processus au fil de leur évolution. »

Il ne s'agit donc plus de répondre à un cahier des charges définitif en établissant des plannings à trois ou à six mois, sans cesse repoussés et conduisant au final à des prototypes qui ne conviennent jamais. Non, il s'agit de tenir compte des fluctuations et aléas divers et de s'adapter en continu.

« En travaillant par itérations, des cycles courts de deux semaines, nous avons effectué une vraie révolution, raconte Fabien Barbaud. Désormais, nous avons une visibilité à court terme sur des réalisations concrètes et nous pouvons rectifier le tir au fur et à mesure du développement. »

Car chaque cycle, dénommé « sprint », selon le jargon Scrum, s'attache à une fonctionnalité précise du produit, créant une première version qui sera enrichie d'une autre fonctionnalité durant le « sprint » suivant, générant une V2, et ainsi de suite. Deux autres termes sont essentiels : « product owner » (PO), l'oeil du client dans le projet, qui gère un carnet de production évolutif (dit « backlog) » en déterminant l'ordre des priorités selon ses attentes et qui valide le produit à chaque étape, et « scrum master » (SM), garant de la méthode et facilitateur.

Les deux autres points forts de la méthode sont « la transparence » et « l'inspection » pour vérifier que les travaux sont sur le droit chemin. Ce qui passe par des rituels spécifiques (lire encadré ci-dessous) dont l'un des piliers est le « scrum quotidien », une réunion très courte - portes ouvertes - de quinze minutes chaque matin et qui permet d'entamer une journée plus productive après avoir dressé le bilan de la veille.

« Nous nous rassemblons tous les matins à 9 h 35 tapantes, moi, les PO [product owners] et toute l'équipe technique, précise Fabien Barbaud. Chaque membre de l'équipe parle à tour de rôle en répondant à ces trois questions clés :
"Qu'ai-je fait de bien hier ?", "Que vais-je faire aujourd'hui ?", "Où ai-je rencontré des problèmes ?". Du coup, on lève les obstacles illico, et le jour même on cherche les solutions. »

En plus, tout le monde sait qui fait quoi, ce qui facilite l'entraide.

Quand les coéquipiers "refont le match"...

Autre réunion capitale, la rétrospective après la fin d'un sprint - porte fermée - pour « refaire le match » exclusivement entre les coéquipiers concernés et le PO, afin d'interroger l'efficience des choix opérés (techniques, compétences, organisation, procédés). De là doivent sortir des objectifs de progression pour le prochain sprint : opérer en binôme, combler une lacune...

Le dirigeant a ajouté des réunions de son cru un vendredi par mois pour faire lever la tête du guidon aux équipes sur tout type de sujet. Il en profite pour délivrer des informations sur la vie de l'entreprise et la stratégie décidée par le comité de direction.

Public-Idées n'est pas parti bille en tête pour généraliser la démarche Scrum. Elle l'a testée deux mois et demi au printemps 2011 avec six volontaires répartis en deux équipes. Une étape d'autant plus nécessaire que ces pratiques - alors inédites pour les collaborateurs - reposent sur un postulat de taille : l'auto-organisation.

« Il n'y a plus de chef de projet qui amène la conception, programme et délègue les activités dans le détail », souligne Kévin Maccioni, ex-scrum master et « coach agile » pour aplanir les difficultés.

Ce qui nécessite un nouvel état d'esprit autour de la prise d'initiative et de la responsabilisation.

« Chacun de nos groupes projets de trois développeurs doit s'impliquer et assumer des choix. »

C'est le groupe qui décide de sa charge de travail dans un sprint, lui qui fait les choix techniques, qui détermine le comment, qui gère son tableau de bord, qui détecte les améliorations.

Chacun doit donc apprendre à s'écouter et dire son opinion avant que le groupe se mette d'accord, par vote ou consentement. Et le partage comme le feed-back positif doivent devenir un réflexe. Et là, il y eut des freins. L'équipe étant en première ligne de A à Z, chacun s'exposant, certains ont craint d'être jugés incompétents.

« Il a fallu détricoter les postes, raconte Fabien, notamment celui des chefs de projet, redevenus développeurs. »

Et puis tous ont dû s'approprier le sabir spécial Scrum, utile pour faciliter le détachement par rapport aux anciennes habitudes. Au final, le rythme des livraisons à l'utilisateur s'est accéléré, il y en a une toutes les deux semaines et non plus une tous les deux mois. Fort de son succès, le pôle technique de Bordeaux essaime aujourd'hui ses pratiques dans toute l'entreprise. Et depuis fin 2013, il va encore plus loin dans l'agilité, en variant la durée des itérations selon les besoins et la complexité des tâches qui se présentent : certaines itérations ne durent que deux jours.

_____

>>> FOCUS Les six rituels de la méthode

• Sprint - Cycle de développement d'une ou plusieurs fonctionnalités, d'une durée fixe de deux à quatre semaines, qui aboutit à un produit partiel mais potentiellement utilisable.
• Story - Histoire du client qui exprime le contenu à développer dans une fonctionnalité (par exemple, saisir un login pour se connecter) présentée par le PO à l'équipe.
• Scrum quotidien - Réunion du matin de dix à quinze minutes pour évaluer l'avancement du travail, identifier les obstacles et décider des ajustements.
• Rétrospective - Réunion de réflexion collective en fin de sprint, de une heure ou plus, pour capitaliser sur les savoirs, éviter les erreurs. Après la revue de sprint qui montre le produit devant l'utilisateur pour récolter son feed-back.
• Planning poker - Estimation par l'équipe du travail à accomplir sur une fonctionnalité grâce à un jeu de cartes à plusieurs valeurs. Chacun abat sa carte et s'explique sur son choix. Ce qui ouvre le débat, pour parvenir à un consensus.
• Validation des tâches - Effectuée par un collègue - jamais le même - qui confronte sa vision à celle du faiseur, ce qui permet de décloisonner le pouvoir dans la prise de décision.