Evoluez en faisant du Scrum 2.0

Qu’est-ce que le Scrum 2.0 ?

Le Scrum a bien évolué depuis de nombreuses années et mérite lui aussi d’avoir sa deuxième version (Scrum 2.0). Un grand nombre de pratiques complémentaires sont devenues presque obligatoires dans l’application du Scrum.

Cette article considère que vous connaissez bien les bases du Scrum et ne parlera que des évolutions du Scrum pour en arriver au Scrum 2.0 et pas des bases de cette méthode Agile.

Article : Qu’est-ce que le scrum ?

Un Sprint du Scrum 2.0

Un Sprint d’un Scrum 2.0 est légèrement plus complet que les Sprint de bases. Voici un schéma qui permet de voir les changements dans les grandes lignes :

Si vous connaissez bien le Scrum de base et son déroulement complet, vous pouvez dès maintenant en un coup d’œil voire les subtilités de cette version de Scrum actualisée.

2 nouvelles cérémonies

Cette nouvelle génération du Scrum rajoute deux cérémonies essentielles au bon déroulement des Sprint que nous allons voir dès maintenant.

La Product Backlog Refinement (Grooming)

Cette réunion comme son nom l’indique a pour but d’affiner le Product Backlog afin de permettre au Product Owner de mieux gérer son backlog et ses Sprint.

[update 2019] Pour information, cette réunion est devenue officielle dans le Scrum Guide sous le nom de Product Backlog Refinement. Le terme Grooming utilisé auparavant est exclu des documentations récentes car ce mot a une connotation pédophile dans certaines régions du monde.

Le Product Owner aura une heure par semaine maximum pour proposer des user-stories à l’équipe de développement. La réunion pourra durer beaucoup moins de temps si le PO n’a pas beaucoup de user-story à soumettre.

Ceux-ci devront dire au PO si ils ont bien compris la demande ou si il est nécessaire d’avoir des précisions sur celle-ci ; le PO pourra alors mieux expliquer la demande si il a les réponses ou revoir la user-story avec les clients.

Si la demande est bien comprise par l’ensemble de l’équipe, ils estimeront les points d’effort de la user-story avec la technique du poker planning.

Article : Planning Poker : estimer vos user-stories

En Scrum 2.0, on ne parle jamais de temps mais toujours en point d’effort. Pour ceux qui ne connaissent pas ce concept de point d’effort, les développeurs vont indiquer si la user-story est difficile ou facile à traiter en prenant en compte l’incertitude sur la demande.

Quand tout cela est terminé, on considère que la user-story est prête à intégrer un futur Sprint Backlog.

Si le temps d’affinage d’une heure par semaine s’avère insuffisant, je vous conseille alors de rajouter une séance supplémentaire d’une heure un autre jour. Nous évitons de faire une séance de deux heures car il n’est pas rare que l’équipe ne soit attentive pendant autant de temps.

La Priority Meeting

Cette nouvelle cérémonie ne concerne que les clients, le Product Owner et le Scrum Master (en tant que facilitateur et animateur). Ils vont prendre 30 minutes maximum pour prioriser les demandes ensemble.

Cette réunion peut d’ailleurs être utilisée pour faire des ateliers de priorisation (MVP, diagramme de Kano, définition d’une business value…).

Dans certaines entreprises, le PO a assez de pouvoir et la capacité de prioriser les user-stories. Il profitera de cette réunion pour présenter la priorité qu’il a choisi, les raisons de celle-ci et éventuellement le travail de ses priorisations (MVP, diagramme de Kano…) afin de maximiser la transparence. Les clients pourront d’ailleurs donner leurs points de vus sur le sujet ce qui peut soulever d’éventuels problèmes non repérés en amont.

Selon le contexte de votre entreprise, vous pouvez faire cette réunion d’une fois par semaine à une fois par Sprint.

Sprint Planning Meeting plus courte

Si cette cérémonie existait déjà dans la version de base du Scrum, elle comprenait le travail d’estimation et de compréhension des user-stories. Cependant, cette réunion était beaucoup plus longue car le Product Owner devait également préparer le Sprint en live selon le résultat des estimations de l’équipe de développement.

Avec la Product Backlog Refinement, le PO arrive à la Sprint Planning Meeting avec un Sprint Backlog déjà préparé. Il ne lui restera qu’à présenter les user-story à traiter (déjà vue précédemment dans la Product Backlog Refinement) et de demander aux développeurs de les découper en tâches techniques.

Sous ce format, cette réunion est environ quatre fois plus rapide que sous l’ancien format et les développeurs apprécient grandement ce gain de temps ; ils apprécient guère les réunions qui s’éternisent.

2 nouveaux rôles essentiels

Dans le Scrum 2.0, nous avons deux rôles qui se rajoutent pour aider au bon fonctionnement du Scrum.

Le testeur

Il est fort utile d’avoir un spécialiste des tests humains. Si ce rôle est souvent attribué au Product Owner, on considère qu’un spécialiste dans le domaine fera beaucoup mieux le job. Le PO a des contraintes qui parfois le mettent en risque de ne pas avoir le temps nécessaire pour bien tester l’ensemble des user-story.

Avoir un testeur attitré à ce rôle à 100% assure une meilleur qualité du produit car il saura faire tous les tests nécessaires pour faire des rapports complets pour aider les développeurs.

Les clients

Dans le Scrum 2.0, les clients ne font pas parti de l’équipe Scrum directement mais participent activement à celui-ci. Les clients sont présents lors de la Sprint Review et la Priority Meeting en plus du contact régulier qu’ils ont avec le Product Owner.

Cette démarche va totalement dans le sens participatif que nous retrouvons dans le Devops par exemple. Les clients sont essentiels à la réussite des projets, ils doivent en faire réellement parti.

Un Scrum 3.0 ?

Pour être honnête les pratiques Agile se multiplient ses derniers temps et évoluent très vite. Je ne serais pas étonné que de nouvelles pratiques deviennent presque obligatoires à l’avenir grâce à de nombreux retours d’expériences unanimes sur l’efficacité de certaines nouvelles pratiques.

Les pratiques Agile n’hésitent pas à emprunter des pratiques venant du marketing, venant de méthode d’organisation différentes… C’est probablement ce qui fait la richesse de l’agilité et ce qui permettra d’affiner ces méthodologies de travail qui n’attendent qu’à s’améliorer.

Avez-vous des pratiques complémentaires que vous utilisez dans votre Scrum pour l’adapter à votre contexte et l’améliorer ?