Scrum 2.0

Follow the leader
Suivez le leader !

Tout d’abord et une fois n’est pas coutume…je vous présente mes excuses…En effet, je le reconnais j’aurais difficilement trouver un titre plus racoleur…;-) Mais passé votre surprise… qu’est-ce qui se cache derrière cette expression « Scrum 2.0 » ?

Lors d’un projet nous venions de travailler 6 mois en mode Scrum, la mise en production était réalisée et nous avions un mois d’arrêt avant de recommencer 6 autres mois de projet. Nous en avons alors profité pour faire un review / lessons learned de nos 6 mois de travail. Un de points portait sur notre méthode de travail. Allions nous continuer comme ça pour les 6 prochains mois ?

Une chose est rapidement apparue lors de nos discussions, beaucoup de team member trouvaient que la découpe d’une User Story en différentes tâches (+ l’estimation de la tâche en heures) était une étape très lourde. J’ai pris le feedback et ensuite j’ai rencontré chaque team member individuellement pour creuser l’idée. Quels étaient les points positifs et quels étaient les points à améliorer. J’ai ensuite confronté ces idées avec mes contraintes et besoins de Scrum Master et nous sommes arrivés à une méthode différente et qui a fonctionné pendant les six mois qui ont suivi.

Scrum 2.0: La méthode

Tout d’abord quelques pré-requis:

  • L’équipe reste la même ou presque. Dans notre cas remplacement d’un team member par un nouveau.
  • Durant les 6 sprints précédent, l’équipe est devenu plus autonome qu’au départ.
  • La productivité de l’équipe a augmenté au fur et à mesure des sprints.

Voici donc ce que nous avons mis au point. Et comment nous avons fait évoluer notre mode de fonctionnement

1. Plus de découpe en tâche

On ne découpe plus une user story en tâches. Mais on conserve les principes de User Stories et de complexité (fibonnacci). On n’abandonne pas les post it pour autant ! Si lors du sprint planning certaines tâches ou certains points paraissent important, on précise ces points sur des post-it et on les colle sur la User Story correspondante.

2. User Story leader

Pour réaliser une user story, durant le sprint on fonctionne comme suit: La première personne qui démarre la user story est considérée comme le Story Leader de cette user story. Afin que ce soit clair pour tout le monde il colle sa couleur sur la user story et ajoute une étoile sur sa couleur. L’étoile voulant dire, ce team member est le leader pour cette story. Ce principe est expliqué plus en détail sur la figure « Scrum 2.0 en images » ci-dessous.

Scrum 2.0 en images
Scrum 2.0 en images (cliquez pour le plein écran)

Le Story Leader a alors la responsabilité de la Story, ce qui recouvre 2 choses principales. Si plusieurs personnes doivent travailler sur la story, c’est le story leader qui en parle aux teams member correspondant et qui en assure le suivi. Deuxièmement, le story leader a le devoir d’information, c’est lui qui parle lors des daily meeting et si le Scrum Master ou le Product Owner a une question sur une story, le story leader connaît la situation et peut immédiatement donner les infos.

Exemple: Le Scrum Master demande à Soulira (Story Leader) « où en est-ton sur la Story 45 ? »

Mauvaise réponse: « heu c’est pas moi qui est dessus, ya Vincent qui code pour le moment faut voir avec lui »

Bonne réponse: « Vincent termine le code ce soir, ensuite je dois repasser sur le design, on prévoit la fin pour demain soir »

3. L’analyste Web

Lors des 6 premiers mois, nous avions hérité d’un cahier des charges pour notre projet. Nous l’avions alors transformé en Product Backlog. Ce cahier des charges comportait un énorme avantage, il avait été validé par l’ensemble des intervenants côté client. Or dans la seconde partie de notre projet nous nous retrouvions face à un problème. Il allait falloir identifier rapidement les user story à réaliser pour le sprint, mais beaucoup de personnes devaient donner leur accord sur le « Scope ». Concrètement, le product owner n’était pas seul, il devait faire valider les priorités à chaque fois par un groupe de travail.

Pour remedier à cette situation nous avons créé un rôle d’Analyste Web. Que doit-il faire ? Il a un mois d’avance sur l’équipe pour aider le product owner à rédiger et prioritiser les user story. Ensuite ces priorités sont présentées au groupe de travail et sont prêtes le mois suivant pour être réalisées par l’équipe.

Exemple: Pendant le mois de janvier, l’analyste travaille avec notre product owner. Fin janvier on fait le sprint planning tous ensemble. On discute alors un set de user stories déjà négociées et discutées avec les client. Le 1er février on peut démarrer le sprint.

En résumé le rôle de l’analyste Web est d’être toujours 1 mois à l’avance par rapport à l’équipe.

Pourquoi faire évoluer les choses ?

Pour nous cette méthode de travail a été un succès. Elle a aussi diminué le risque de frustration de l’équipe par rapport à la découpe en tâche. Elle a aussi plus responsabilisé les teams member et permis à chacun de plus prendre « le lead ».

Je me souviens, au tout début de ce projet, avant même de parler de nouvelle méthode, lors des tout premier sprint, j’étais désespéré. Les choses n’allaient pas aussi vite et aussi bien que je l’aurais aimé. Les principes n’étaient pas correctement appliqués. Je me souviens alors d’une discussion avec un coach Agile qui me disait, « c’est normal, l’équipe va monter en expérience au fur et à mesure des sprint » et effectivement à partir du sprint 3 j’ai commencé à souffler un peu… et une fois 6 sprints passés, nous avons pu en refaire 6 autres avec cette nouvelle méthode.

Cette méthode s’inscrit dans la nécessité de faire évoluer votre équipe et vos méthodes au fur et à mesure du projet. Et comment avons nous pu mettre cela au point ? Simplement en étant à l’écoute les uns des autres. Ne sous-estimez donc pas la puissance du feed-back, des sprint review et des lessons learned !

A bientôt !

Bruno.

Ps: Je ne conseillerais pas à une équipe « toute neuve » de travailler en « Scrum 2.0 » par contre c’est une série de bonnes pistes après un certains nombre de sprints.



This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

Laurie Young

Bruno, thanks for a good post. Its a great example of a team evolving scrum to better suit your needs. I especially liked your Story Leader idea, and plan on trying it to see if it gives us the same distributed responsibility.

We have experimented with no task breakdown, and find that it results in less continued commitment during a sprint. I use the task breakdown (with hour estimates) to continuously answer the question « Are we going to complete all the work in this iteration? » – how do you answer this?

Finally – I am unclear on the difference between your Web Analyst role, and the Product owner role. Can you elaborate on this?

brunosbille

Hello Laurie and thanks for your comment !

For your first question, i agree with you: task breakdown will surely help for commitment during a sprint. Actually i did the same as you do. I’ve tried without task breakdown and in my case it worked. Maybe because the team was already in place for a long time (+6months) We also did some team building to improve our cohesion and commitment.
Anyway what you did is a excellent practice: you’ve tried something (no tasks breakdown) and after a while you drew some conclusions and decided to rollback, fine for me.

The Web analyst is there to support the product owner, in our context it was useful because the product owner was « junior » in project management and was not staffed 100% on our project. So the web analyst mainly assist the product owner. If the product owner has a specific need, he also discuss with the team to propose different scenarios (technically possible) to the PO.

Does it help ?

Cheers,

Bruno.

brunosbille

I’ve still one thought,

How « Are we going to complete all the work in this iteration? « , we use the sum of the complexity points.

e.g. We know that the team in 4 weeks can achieve 135 points, so we don’t select more user stories than a sum of 135 points of complexity.

Normally this sum will increase at each sprint, you team will improve his productivity.

Bye,

Bruno

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