Formation Scrum Master à La Défense

J'ai eu l'occasion la semaine dernière, précisément les mardi 25 et mercredi 26 mars, de suivre une formation « Scrum Master » donnée par Jeff Sutherland en partenariat avec Xebia France, à Paris-La Défense.

Pour ceux qui ne connaissent pas Scrum, je dirais qu'il s'agit d'une boîte à outils méthodologiques pour mener des projets à bien.

Basiquement, ces projets sont :

• avec des objectifs « démontrables » : par exemple, un site web, un rapport rédigé, un gâteau...
• suivis de près par un « directeur de produit » (Product Owner)
  
• à équipe réduite : entre 5 et 9 personnes, avec une préférence pour des équipes de 5
  
• menés de façon itérative : à la fin de chaque itération, une version du produit est garantie testée, et est démontrable entre autres au directeur de produit ; cela assure que le feedback est reçu à intervalles rapprochés et réguliers, et qu'on vérifie que la trajectoire prise par l'équipe n'est pas déconnante
  
• menés sur des itérations courtes : de 2 à 5 semaines, avec souvent une préférence pour des itérations de 2 semaines (je n'en reviens toujours pas, car cela me semble bien court, mais plusieurs participants m'ont assuré travailler ainsi)
  

Une des grandes devises de Scrum est « inspect & adapt », c'est-à-dire qu'un projet mené avec Scrum améliore lui-même sa méthode de travail tout du long.

Scrum est une méthodologie « agile », au même titre que XP pour le processus de développement logiciel.

Pour de plus amples renseignements, je vous conseille le blog de Claude Aubry, et le livre Agile Project Management with Scrum, de Ken Schwaber (Ken Schwaber est le co-inventeur, avec Jeff Sutherland, de Scrum).

J'avais eu l'occasion de m'intéresser à Scrum par l'intermédiaire de lectures sur le web, et d'expérimenter avec enthousiasme deux ou trois principes portés par ce framework. Suivre la formation à Paris m'a permis d'équilibrer mes connaissances théoriques, et évidemment de rencontrer d'autres personnes impliquées dans Scrum.

Ce furent deux jours passionnants.

D'abord, Jeff Sutherland, l'homme. Il est à la fois brillant et précis dans son discours, très intelligent dans sa façon d'appréhender les choses, humble et... marrant. Je dirais qu'il apparaît que Scrum s'inscrit pour lui dans une démarche plus globale. Il a évoqué le bouddhisme zen par exemple.

Ensuite, Scrum. En anglais, « scrum » signifie « mêlée » : celle du rugby. À entendre Jeff Sutherland, il s'agit bien et prioritairement de permettre à une équipe d'être la plus efficace possible pour atteindre un objectif commun. Pour cela, il faut (et il suffit ?) de clarifier par tous les moyens (discussions, démonstrations suivies de feedbacks, échanges avec le client) l'objectif à atteindre, et de libérer l'équipe de tout ce qui pourrait gêner sa tâche.

À ce titre, la méthode invoque un rôle particulier dans l'équipe, celui du « Scrum Master » (c'était l'objet de la formation, vous suivez). Je dirais que celui-ci est principalement là pour régler les impediments, c'est-à-dire les obstacles que rencontre l'équipe, et pour favoriser les échanges et le feedback continuels, en organisant notamment, et en cadrant, des réunions quotidiennes d'environ un quart d'heure (daily scrums).

Les impediments peuvent être de divers ordres : matériels, logiciels, environnementaux, voire budgétaires, mais aussi humains, politiques, ou managériaux. Le Scrum Master est concentré sur le travail que doit fournir l'équipe, pas sur la hiérarchie dans l'organisation.

Quand on se pose la question de cette façon simple, il n'y a pas grand-chose à penser :

• Le Scrum Master met de l'huile dans les rouages (daily scrums et tenue à jour des backlogs),
• et balaie les grains de sable de l'engrenage.
• L'équipe prend à sa charge la réalisation du produit,
• produit dont le Product Owner maintient une vision claire et compréhensible (accessible).

L'image qui me venait est celle d'une piste de bobsleigh : si la piste est constamment dégagée, l'équipe la descendra d'abord à pied (on n'est jamais trop prudent), puis en se laissant glisser individuellement (confiance), puis... en bobsleigh (confiance + équipe).

Les études menées sur l'utilisation de Scrum montrent paraît-il qu'une équipe de développeurs moyens est toujours meilleure à terme que des bons ou des très bons développeurs qui travaillent séparément. Cette émergence qui naît au sein d'une équipe est captée dans le « ba », terme japonais.

Le fait d'avoir son esprit vacant (no impediment) et concentré sur l'activité s'appelle le « kaizen ».

L'objectif de Scrum est de permettre au « ba » de s'exprimer dans une équipe composée de personnes en état de « kaizen » ;-)

Pour en revenir à la formation, nous étions 30 stagiaires. La formation et le support étaient en anglais, avec l'aide de Guillaume Bodet, directeur technique de Xebia France, présent pendant ces deux jours, dans le cas où des termes auraient nécessité une traduction (cela n'a finalement pas été le cas).

Deux exercices m'ont particulièrement intéressé :

• la réflexion en équipe et la rédaction collaborative d'une réponse à un problème donné, en trois itérations de 8 minutes, chacune précédée de 4 minutes de daily scrum. Je jouais le Scrum Master, et me bornais donc à organiser les daily scrums et à régler les problèmes de l'équipe. J'ai trouvé que le résultat, c'est-à-dire le document rédigé, malgré le caractère parfois désordonné du travail, et la vitesse demandée, était de bien meilleure facture que ce qu'on aurait pu composer chacun de son côté, ou de ce qu'on aurait pu organiser linéairement sans itérations. Pour la démo, l'équipe m'a demandé de présenter le document ! alors que je n'avais pas participé à sa matière. C'est le rôle du Scrum Master, si j'ai bien compris : être au service de l'équipe...
  
• un exercice de planification en fonction de la « valeur métier » des composants d'un produit à réaliser. Notre équipe n'a pas terminé l'exercice (!!!) car nous passions trop de temps en planification. La qualité de réalisation était évidemment très bonne (vu la planification), mais le projet a été planté, vu que nous n'avancions pas à un rythme suffisant. Cet exercice m'a montré l'importance primordiale du Product Owner, qui doit être clair dans ses demandes et exigeant quant au résultat, et celle, finalement secondaire, du cadrage apporté par le Scrum Master.

Quelques questions font débat :

• Scrum Master, n'est-ce pas simplement un rôle chef de projet ? Voire un sous-rôle de chef de projet ? Pour ma part je pense que le Scrum Master a notamment comme fonction de balayer les obstacles et de cadrer l'énergie collective, pas de se mettre en avant par rapport à l'équipe (d'ailleurs par moments ça gêne, si on se met en avant). Par ailleurs ce n'est en aucun cas un positionnement hiérarchique : les tâches ne sont pas affectées par le Scrum Master. Donc à chacun de se faire son idée.
• Le client final a-t-il plutôt besoin de bons Scrum Masters, ou de bons Product Owners ? La réponse de Jeff Sutherland est fortement et sans hésiter : de bons Product Owners. La vision du produit doit être portée, avec en permanence la visée de la maximisation de la valeur métier. C'est le Product Owner qui fixe les priorités de chaque itération et qui, en fonction des réalisations de l'équipe (et de la vélocité, dont je n'ai pas parlé dans ce post), gère les dates de livraison.
  

Au final, je vais appliquer Scrum sur tous mes projets. Outre le contact avec le Scrum Trainer, la formation Scrum Master permet de faire le tri dans les bases théoriques sur Scrum, largement disponibles sur le web ou dans la littérature, et de les confronter à la réalité à l'aide de quelques exercices pratiques.

Je ne peux que conseiller cette formation.