Archives janvier 2010

[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.

[English version below: « Team is « multi-tasks » (Five keys to succeed in your Agile/Scrum projects) »]

Régulièrement lorsque je démarre un projet, il arrive qu’un membre de l’équipe vienne me demander: « Dis, quel sera exactement mon rôle sur le projet ? ». Et moi invariablement je réponds: « Je ne sais pas ».

Pour que votre projet soit un succès un premier point à prendre en compte est que l’équipe (et donc vous y compris) soit « multi-tâches ». En effet, sur un projet Agile ou Scrum, ne vous attendez pas à avoir une « job description » avec les différents acteurs (développeur, analyste,…) ainsi que les différentes tâches liées à ces rôles (le développeur est responsable du code,…). Non sur un projet Scrum/Agile on pourrait résumer le pragmatisme par: « C’est le projet qui prime ». Et donc si pour le succès du projet aujourd’hui vous devez aller dans une papeterie pour acheter des post-its de couleurs et bien c’est qu’on fera.

« Ce n’est pas comme ça qu’on fait d’habitude ?! » doit être dans le top 5 des phrases que j’entends le plus sur un projet 😉 D’après la dernière analyse de Gartner que j’ai lu, plus de 70% des projets informatiques sont un échec, il est peut-être temps de changer nos habitudes ?

L’équipe doit être multi-tâches

OK mais qu’est-ce qu’on entend par là ? C’est à vous, coach, Scrum Master, Team Member expérimenté à transmettre à votre équipe ce qu’il y a derrière cette expression. On pourrait résumer cette approche par 1. examiner et 2. s’adapter, merci Derek :-).

Exemple, si en tant qu’architecte vous devez étudier l’architecture IT, il est possible que vous ayez d’abord à faire le Sherlock Holmes pour trouver de la documentation existante. Autre exemple si aucun outil de test n’est utilisé, à vous d’en proposer. Ou encore: le client est à 50km de chez-nous, comment faire pour pouvoir installer Skype sur le réseau. Il y aura beaucoup de tâches « différentes » ou « annexes » à réaliser. On ne peut pas garantir, par exemple, à un développeur qu’il ne fera que du développement et pas du test. Ou encore, à un analyste fonctionnel qu’il ne touchera pas un peu à la technique. C’est en partie pour cela que tous ces titres sont abandonnés dans Scrum et que l’on parle de « Team Member ».

Plutôt que d’expliquer « pourquoi ça ne va pas » et « de qui est-ce la faute », notre approche va-être: « Que faut-il faire pour que ça fonctionne ?« . Et pour que cela soit possible, chaque membre de l’équipe devra faire toute sortes de tâches différentes. Il n’y a pas ici un « bon » team member qui est multi-tâche. Et un mauvais « team member » qui veut toujours faire la même chose. Non on parle ici d’honnêteté et d’humilité. A vous team leader à expliquer dès le début ce que vous attendez de vos team member. Si, lors de votre recrutement, quelqu’un vous dit « non merci moi je ne fais que du code un point c’est tout » et bien pas de soucis, il ira sur un autre projet. L’organisation a aussi besoin de personnes qui fonctionnent comme ça. Et les équipes plus opérationelles ou les autres projets de type waterfall sont aussi très utiles.

Les outils

Dans le cas d’un projet IT être « multi-tâches » c’est bien évidemment amener des techniques Agile ou des mode de collaborations différents. En vrac je vous citerai faire de l’XP, du pair programming, du test driven development, utiliser les user stories… A chacun d’apporter ses idées

Dans la dynamique d’équipe on va accorder également une grande part au partage de connaissance entre team-members et prendre des décisions en commun. Raisonner en équipe est alors à ce moment primordial car mettre tous les cerveaux autour de la table va nous permettre d’avoir « de la perspective ». Par exemple on ne mettra pas en place une technique sexy (web-service, flex,…) si on n’estime qu’elle n’a pas de valeur ajoutée pour le client. Dans ce genre de processus il peut être aussi très intéressant de mélanger des personnes ayant une très bonne connaissance du projet, avec des personnes ne le connaissant peu va pas du tout.

Le multi-tâches en pratique, le Sprint 0

La meilleure manière pour moi est de démarrer par un sprint 0. En résumé: vous voulez faire du Scrum ? Ok commencez dès maintenant…je veux dire MAINTENANT. Imaginez-vous. Vous êtes Scrum Master ou chef de projet, et vous devez initier le projet. Si vous savez déjà qui sera dans votre équipe, même si vous n’avez encore de 2 personnes sur 9 de disponibles et bien faites du Scrum tout de suite !

• Vous êtes trois ? Faites au moins une daily meeting chaque jour.
• Vous devez organiser le déménagement afin d’avoir des locaux pour l’équipe ? Répartissez-vous les tâches
• Vous devez créer le Scrum Board ? Créer le en équipe
• Vous devez sélectioner des technologies, mettez déjà l’équipe dans la boucle

Au plus vite vous serez dans le concret, au plus vite votre équipe va monter en compétence et se familiariser avec le système.

Un sprint zéro est la manière idéale de réaliser toutes les tâches d’initiation d’un projet. Exemples créer l’équipe, trouver des locaux pour être ensemble, choisir ses outils et l’architecture, créer le product backlog etc…

Voilà, c’est tout pour le moment.

Fin de notre premier épisode de notre série « Cinq facteurs de succès pour vos projets Scrum/Agile ».

Tout feedback est le bienvenu !

Portez-vous bien.

Bruno.

Team is « multi-tasks » (Five keys to succeed in your Agile/Scrum projects)

When i initiate a project, i regularly have this question from a team member. « Look, what specifically will be my role on this project ? ». And i always answer… « i don’t know ».

To make your project a success first point to consider is that the team (and so do you) must be « multi-tasks ». Indeed, on a Agile or Scrum project , do not expect to have a « job description » with the different actors (developer, analyst ,…) and the various tasks associated with these roles (the developer is responsible for code ,…). No, on a Scrum / Agile project we can summarize pragmatism by: « Project comes first ». If the project success requires you go and buy colourful post-it notes in a shop, then you do.

« Usually we don’t do this way ?! » Is one of the top 5 i hear while i’m working on a project 😉 According to the latest analysis from Gartner that I read, over 70% of IT projects are unsuccessful, it may be time to change our habits?

The team must be « multi-tasks »

OK but what do we mean by that? It’s up to you, as a Coach, Scrum Master, Experienced Team Member, to explain to your team the meaning of « multi-tasking ». We could summarize this approach by: during the project you should 1. inspect and 2. adapt, thank you Derek 😉

Example, as an architect you will need, to study the IT architecture, it is possible that you have first to take the Sherlock Holmes role to find the existing documentation. Another example where no testing tool is used, it’s up to you to propose one. OR: the customer is 50km away from you, how to install Skype on the network ?. There will be many different tasks to achieve. We can not guarantee, for example, to a developer that he will only do development and not testingt. Or, to a functional analyst that he/she will not have some technical tasks. This is one of the reasons why, in Scrum, we do use the term « Team Member » and no « developer », « analyst »,….

Rather than explain « Why it doesn’t work » and « Who is to blame », our approach will be: »What do we have to do to get it done?  » And to make it happens, each team member must make all sorts of different tasks. There is here no « good » team member who is multi-task or a bad « team member » who always wants to do the same thing. We speak about honesty and humility. It’s up to you as a team leader to explain at the very beginning of the project, what you expect from your team. So, when you recruit your team members if someone tells you « no thanks, I am only writing code nothing more », that’s ok. He will go on another project. The organization also needs people who work like that. A more « operational » team is also useful for your company.

Tools

On a IT project being « multi-tasks » is obviously bring Agile techniques or different collaborations methods. Like Xtreme Programming, Lean thinking, pair programming, test driven development, using user stories… Everybody can bring ideas !

In the way the team members interact, we will also provide sharing of knowledge and take decisions as a team. Thinking together is important at this time. Bring all the brains around the table will allow us to have « perspective ». For example, we will not use a sexy technology (web service, flex ,…) if we consider that it has no added value for the customer. In this kind of process, it can also be very interesting to mix people with very good knowledge of the project, with people not knowing the project at all.

Multi-tasking in practice, the Sprint #0

In my opinion, , it is best to start with a Sprint #0. In short: you want to do Scrum? Ok start now … I mean NOW. Imagine. You are Scrum Master or project manager, and you must initiate the project. If you already know who will be in your team, even if only 2 people on 9 are available. I suggest you to start in Scrum mode immediately.

• You’re three? Make at least one daily meeting every day.
• You want to organize the move to have offices for your team ? Divide tasks between team members
• You want to create the Scrum Board? Create it with the Team
• You want to select technology, already put the team in the loop

The faster it will be concrete, the faster your team will become familiar with the method.

A sprint #0 is the ideal method to do all the « initiation » tasks on a project. Like: set-up the team, seat the team together, choose tools, architecture, create product Backlog,…

That’s all for the moment.

End of our first episode of our series « Five success factors for your projects Scrum / Agile ».

Feel free to give feedback.

Take care.

Bruno.

[English version below: « 0/5 Five keys to succeed in your Agile/Scrum projects »]

Je suis en train de préparer une série d’articles. le thème sera « cinq facteurs de succès pour vos projets Agile/Scrum ».

L’idée: en se basant sur diverses sources (formation, coaching, retour d’expérience, lessons learned) vous proposer cinq principes qui, s’ils sont appliqués, vont grandement augmenter vos chances de succès sur un projet utilisant Scrum ou des méthodes Agile. Vous pouvez également appliquer ces principes sur un projet de type « waterfall » utilisant PMI ou Prince2.

Les articles traiteront de principes Scrum, de principes Agile mais aussi d’autres choses comme des principe de coaching ou des concepts issus de la PNL.

J’ai pas mal d’idée et donc à mon avis, ce thème des cinq facteurs sera divisé en une série de billets.

Je terminerai par deux choses, tout d’abord vous remercier pour vos emails, vos commentaires via le Blog ou via Tweeter. c’est un réel plaisir d’échanger avec vous. Un merci particulier à Kelly Waters et Claude Aubry pour m’avoir publié. Merci également à Dany Butaye et Lahcen Afif pour m’avoir aidé à mettre au point mon Blog.

Ensuite je vous souhaite à tous de bonne fêtes de fin d’année. Plein de bonheur pour vous vos amis et vos familles. Et je vous souhaite de réussir à tenir toutes vos bonnes résolutions pour 2010 🙂

Bruno.

0/5 Five keys to succeed in your Agile/Scrum projects

I’m for the moment working on a serie of posts. Theme will be: « Five keys to succeed in your Agile/Scrum projects ».

The idea is to suggest five principles which, if implemented, will greatly increase your chances of success on a project using Scrum or methods Agile. Those posts will be based on various sources (training, coaching, feedback, lessons learned) . You can also apply these principles on a waterfall project using Prince2 or PMI.

Articles will cover Scrum principles, Agile principles but also other things like coaching principles or NLP concepts.

I have a lot of ideas and therefore I think this theme of the five keys will be divided into a series of posts.

I will conclude with two things, first of all thank you for your emails, your comments via the blog or via tweeter. It’s a real pleasure to share with you. A special thank you to Kelly Waters et Claude Aubry having me published. Thank you also to Dany Butaye and Lahcen Afif for helping me to set-up my blog.

Then I wish you a happy new year, full of happiness for you, your friends and families. Happy 2010 ! 🙂