Scrum 2.0

[English version below]

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.

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.

English Version

First of all I would like to apologize… I’m really sorry… for such a « buzz title » in this post 😉 Okay but, let’s see what’s beyond this « Scrum 2.0 » expression.

In the project we worked 6 months using Scrum, the release was done and we had one month off. After the one month off, we were supposed to continue working on the same project with a second release in the next 6 months. Before starting, we took the opportunity for a lessons learned about our 6 first-months of work. One point was about the way we work in Scrum mode. Should we do exactly the same during the next 6 months ?

Something came up quickly. Some team members found the process of dividing a user story into tasks (+ estimate the task in hours) very heavy. I took the feedback and met each team member individually. We discussed the positive points and what could be improved. Then I checked if all the team wishes matched my Scrum master needs and constraints. Then I came up with a different way of working. We used the Scrum 2.0 method with success in the second release.

Scrum 2.0: How does it work ?

Before we start, some prerequisites:

• Team remains the same (or almost). In our situation, we had one new team member.
• In the last 6 sprints, team became more and more autonomous.
• Productivity of the team improved at each sprint.

Here’s what was done and how our way of working evolved.

1. No more «  breaking the requirements into tasks« 

We no more broke the requirements into tasks. However we kept the concepts: User Stories and complexity (Fibonnacci). We didn’t give up on post-it notes: If some tasks seemed important, we wrote those tasks or some « attention points » on post-it notes. And then, as usual, we sticked those notes on the corresponding user story.

2. User Story leader

For a user story to be done, here’s how we do it. First team member who takes the user story is considered as the Story Leader for this specific user story. To make it clear (and visual) for everybody, he sticks his color on the user story and draws a star on it. The star means, that this team member is the Story Leader for this specific story. See also « Scrum 2.0 illustrated » figure for more details.

Story Leader is responsible for this Story, which means two important things. One, if several persons have to work on the story, the story leader will coordinate and follow up the progress. Two, story leader is responsible for the information and the communication, he speaks during daily meeting. If Scrum Master or Product Owner have questions on a story, story leader know the actual situation and can immediately give infos and details.

For instance: Scrum Master asks to Soulira (Story Leader for Story #45) « How far are we with Story 45 ? »

Bad answer: « yup, I don’t know, Vincent is actually coding this story, you should see with him… »

Good answer: « Vincent will end coding this afternoon, then I will update the design, you can consider it done for tomorrow 5 p.m.

3. Web Analyst

In our 1st release, the 6 first-months, we had specs with a functional analysis. Therefore, we created our product backlog based on those specs. This had the advantage, that the specs were validated by all the stakeholders (client-side). However, in the second release we had to restart from zero, without detailed specifications. And we needed our user stories to be ready asap for the team to start development. An additional issue, that could cause delay, was that the product owner had to validate priorities with a work-group.

To fix these potential issues, I decided to create the Web Analyst role. What is he supposed to do ? He has a month to help the product owner writing user stories and prioritising them, in order they discuss them with the work-group. Once finalised, the user stories are ready to be presented to the team.

Example: In January, the web analyst worked with the product owner and the work-group. End of January, we did the sprint planning together. We then discussed on a set of user stories already negotiated with the clients. On February, 1st, we could start the sprint.

To summarize, role of the Web Analyst is to be one-month ahead to the rest of the team.

Why should we change our way of working ?

For us, this change in our way of working was a success. One benefit was to reduce the risk of frustration of the team regarding the « breaking the requirements into tasks » actions. The other benefits was that the team members were more « responsible » and took the lead on the project.

I remember, at the very beginning, even before questioning our way of working, I was desperate. Things were not going so fast and so well the way I wanted. Agile Principles were not correctly applied… I remember discussing with an Agile coach and he told me: « Look it’s normal, you will see, at each sprint, the team will gain in efficiency » . Indeed, starting sprint #3 I was reassured things were getting better and after the first 6 sprints we did 6 additional sprints using our « Scrum 2.0 » method.

In a project it is necessary to evolve or to adapt, that’s why Agile and Scrum have feedback and review mechanisms. By applying those mechanisms I was able to set-up a new way of working for the team. How was I able to set this up ? Simply by listening to my team members. Do not underestimate the power of feedback, sprint review and lessons learned !

See you soon !

Bruno.

Ps: I wouldn’t advise a fresh new team to work this way, but it’s a good basis for an experienced team who wants to work in a slightly different way.