Blog

Compte Rendu Soirée anniversaire du French SUG (Scrum User Group) à Microsoft France

[English version below: « Feedback 1st birthday evening of the French SUG (Scrum User Group) @ Microsoft France »]

Campus Microsoft Paris
Microsoft Campus Paris

Je vous en ai parlé dans un post précédent, le 30 mars il était prévu que je donne une formation pour la soirée anniversaire (1 an) du French Scrum User Group. Voici mon retour sur cette soirée.

Arrivé sur Paris aux alentours de 16h, histoire de ne pas passer ma vie sur le « périph » dans les embouteillages j’ai été accueilli par Xavier Warzee de Microsoft France. En effet cette soirée était sponsorisée par Microsoft et se passait à leur siège parisien. Que dire sinon que Xavier m’a accueilli comme un roi ! J’ai pu visiter les bureaux ainsi que certaines Tech-Room et notamment faire joujou avec les « Table-Surface ».

Ensuite vers 18h arrivée de Luc Legardeur le président de l’association, mise en place de l’organisation et test des différentes conference room. Là je dois dire que point de vue logistique c’était impressionnant. Quatre salles avec tout ce qu’il faut: salles « design », projecteur, micro, matériel etc… et même une vraie salle de type « Keynote ». Bref un vrai « Conference Center ».

La soirée commençait par une présentation sur le French SUG et ensuite une keynote de 45 min de Romain Pichler ayant pour thème « Product Owner Challenges or Grooming the Product Backlog ». Intéressant et participatif comme je les aime.

En train de jouer avec la Table-Surface
En train de jouer avec la Table-Surface

Ensuite démarrage des tracks, 4 salles en parallèle donnaient des présentations sur différents thèmes. En ce qui me concerne ma présentation avait pour thème « Comment la PNL (Programmation Neuro Linguistique) peut vous aider sur votre projet Scrum« . Je suis très satisfait de la présentation. Voici mon feedback sur cette soirée.

Le positif:

  • Pas de problème logistique, nous avions même un expert à disposition
  • Une salle très curieuse du sujet, en ce qui me concerne la curiosité n’est pas un vilain défaut
  • Que certaines personnes me recontactent pour en savoir plus
  • Une audience qui participe
  • Une organisation au top
  • Des personnes curieuses d’élargir leur savoir

Ce qui pourrait être amélioré

  • J’ai été très frustré de ne pas avoir d’espace « d’échange » après la présentation. Mais histoire d’être « actif » j’ai donné mes coordonnées ce qui me permet de continuer le débat via email, mobile ou skype
  • Prévoir une séance questions & réponses
  • Etre filmé
  • 30 minutes c’est vraiment court
  • Que je ne sois pas le seul à avoir vu Percy Jackson…
French SUG Main Stage
French SUG Main Stage

En résumé une très bonne expérience, il est possible que cette présentation soit donnée dans d’autres conférences. Si c’est la cas le contenu sera adapté, je ne veux pas refaire exactement la même chose.

Si vous avez participé à cette présentation, pouvez-vous m’envoyer vos retours/feedback ?

Merci d’avance,

Bruno.

Ci-dessous vous trouverez les slides ainsi que quelques retours quant à la présentation

Les slides

Quelques retours

Antoine Vernois: « Merci Bruno.
J’ai vraiment apprécié ta présentation. J’ai découvert un domaine qui me semble pouvoir fournir des outils très utiles pour améliorer la communication dans une équipe. »

Voir d’ailleurs le très bon billet d’Antoine Vernois sur la soirée en général, inclus un commentaire sur ma présentation

Whaly: Extra la présentation sur la PNL, une découverte qui m’a donné envie d’en apprendre d’avantage. Merci.

Par Twitter

@alexconrad Attended a French Scrum User Group at Microsoft Paris this week. Very good presentation of Neuro Linguistic Programming. Thanks @BrunoSbille

Feedback 1st birthday evening of the French SUG (Scrum User Group) @ Microsoft France

Campus Microsoft Paris
Campus Microsoft Paris

In a previous post I told you had a plan to give a presentation in Paris, march 30th. It was for the first birthday of the French Scrum User Group. Here’s my feedback on this event.

I arrived in Paris around 4 p.m to avoid traffic jam, I was warmly welcomed by Xavier Warzee from Microsoft France. Microsoft was the sponsor of the evening and the event took place in their main offices in Paris. Xavier let me visit the place, all the offices, Tech-Rooms and let me « play » with the « Table-Surface ».

Then around 6 p.m comes Luc Legardeur president of the French SUG, beginning of the organization and test of all rooms.  I was impressed by the Microsoft infrastructure. It’s a real conference center with all you need. Four rooms with a nice « design », beamer, mic,… and even a « Keynote » room.

The event started with a presentation on the status of the French SUG, then a keynote of 45 min took place with Romain Pichler. Theme was « Product Owner Challenges or Grooming the Product Backlog ». Interesting and Interactive, just the way I like it.

Playing with Microsoft's Table-Surface
Playing with Microsoft’s Table-Surface

Then the different tracks started. 4 Rooms in the same time with different topics. My presentation was « How NLP (Neuro-Linguistic Programming) can help you on your Scrum Project« . I’m very happy with this presentation, here my feedback.

Positive points

  • No logistic problem, an expert was available to help us (thanks!)
  • People were curious about the subject
  • Some people came to me after the presentation to know more
  • A participative audience
  • Top organization
  • Met people who want to develop skills

What can be improved ?

  • It was very frustrating not to have a « exchange » space after the presentation. Anyway i was able to continue discussion via email, mobile or skype
  • Plan time for question & answers
  • Being filmed
  • 30 minutes is really short
  • I was the only one to have seen Percy Jackson…

So a very nice experience, i will maybe continue to give this presentation in other conferences but with a different content.

French SUG Main Stage
French SUG Main Stage

If you were there could you send me some feedbacks ?

Thanks in advance,

Bruno.

Below you will find the slides and some feedbacks.

Slides


Scrum et Agile sont enseignés à l’école !

[English Version below: « Scrum and Agile are taught at school! »]

Scrum à l'école
Scrum à l’école

Il y a quelques mois, via un commentaire sur notre Vidéo Scrum, j’ai fait la connaissance de Jim. Il est professeur à l’université (Caroline du nord – USA) il m’a demandé si j’avais une version libre de droits de notre vidéo. En effet la musique des Red Hot Chili Peppers est bloquée sur youtube, pour une question de droits. Après quelques échanges d’email, j’ai appris que Jim enseignait Agile et Scrum à l’université en collaboration avec un des leader Agile d’IBM.

Personnellement, j’ai été ravi d’apprendre que de futurs consultants, chef de projets, développeurs,… peuvent être mis en contact si tôt avec des techniques « Agile ».

Donc nous avons réalisé une nouvelle version de la video avec d’autres chansons. Il y a quelques jours, j’ai appris que la vidéo, ce blog et le projet que l’on a réalisé faisaient maintenant partie d’un travail donné aux étudiants ! Voir attachment ci-dessous, Section 4.

Cliquez pour voir l'intitulé du travail (creative commons)

Je trouve ça excellent qu’un professeur utilise différents supports tels que la video, Internet, un Blog,…pour rendre un devoir plus interactif, dynamique, bien disons plus Agile 🙂

Si vous voulez contacter Jim, voici ses coordonnées:

Jim Yuill – jimyuill at pobox dot com

Bye bye,

Bruno.

Scrum and Agile are taught at school !

Scrum in class
Scrum in class

A few months ago, via a comment on our Scrum Video, i met Jim. He is teacher in University (North Carolina – USA) and asked me if we had a « copyright free » version of our Scrum Video. Indeed Red Hot Chili Peppers, music on our Scrum Video is blocked by youtube, for a copyright issue. After some emails, i learned that Jim was teaching Agile and Scrum courses at University in collaboration with one of IBM’s leaders for their use of Agile.

Personally i was very happy to learn that future consultants, project managers, developers,… can be so soon in touch with Agile techniques.

So we did a new version of the video with another songs. And a few days ago, i’ve learned that the video, this blog and the project we have achieved is now part of a homework given to students ! See attachment below, Section 4.

I’m glad that a teacher use different support (Video, Internet, Blog,…) to make a homework more dynamic, interactive,… hmmm let’s say « Agile » 😉

Click to download

If you want to contact Jim here are the coordinates

Jim Yuill – jimyuill at pobox dot com

Cheers

Bruno.


Scrum 2.0

[English version below]

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.

English Version

Follow the leader
Follow the leader

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.

Scrum 2.0 illustrated
Scrum 2.0 illustrated (click to enlarge)

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.


1/5: L’équipe est « multi-tâches » (Cinq facteurs de succès pour vos projets Agile/Scrum)

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

1/5 l'équipe est multi-tâches
1/5 l’équipe est multi-tâches

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)

Team is "multi-tasks"
Team is « multi-tasks »

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.


0/5 Cinq facteurs de succès pour vos projets Agile/Scrum

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

Slide3
Cinq principes à appliquer

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

caption
Five keys…

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 ! 🙂


Le « Calendrier visuel », un outil de suivi très Agile

[English version below: « The Visual Calendar, a « so Agile » Follow-Up Tool »]

Un exemple de "Visual Calendar"
Un exemple de « Visual Calendar »

Lors de la dernière release de notre projet j’ai eu à travailler avec une équipe de 7 personnes. Or parmi les membres de l’équipe, personne n’était staffé à 100 % sur le projet. Pour vous décrire la situation nous avions:

-> Deux personnes à 80% sur le projet
-> Deux personnes à mi-temps
-> Un expert qui devait prester 15 jours sur le projet, sur une durée de 3 mois
-> Une personne à 20% sur le projet
-> Une personne qui devait intervenir 5 jours sur le projet, mais quand cette personne était présente…toute l’équipe devait être présente.

Cette situation aurait pu tourner au cauchemar… comment être sûr que chacun ait le bon niveau d’information ? Comment communiquer ? Comment fixer une réunion ? Comment lorsqu’un développeur « preste » sur le projet être sûr que « la webdesigneuse » soit là etc…

Bon j’avais d’abord pensé vous dire que j’avais inventé un nouvel outil composé comme ceci:

– un algorithme de calcul très avancé
– des technologies de pointes de planning
– un module de gestion des disponibilités.  Mais j’ai bien peur qu’il n’en soit rien les amis. La vérité est bien plus simple !

Rendez-le tout V-I-S-U-E-L

En fait ces « problématiques » ont été réglées assez rapidement car nous utilisions un « Visual Calendar ». Un outil de suivi et de communication extrêmement simple à mettre en place, et très puissant.

Le Visual Calendar se compose d’une grande feuille de papier sur laquelle on réalise un calendrier d’un mois et sur lequel on colle des post-it.

Voici comment procéder:

Légende visual calendar
De quoi avez-vous besoin pour créer le « Visual Calendar » ?

1. Lors du sprint planning, nous réalisons le visual calendar sur le mois courant. Une bonne pratique est de le faire correspondre à votre sprint. Exemple: imaginons que votre sprint n°2 se déroule du 19 octobre au 13 novembre. Vous savez aussi que le sprint planning du sprint n°3 se fera le 15 novembre Vous réalisez donc votre calendrier du 19 octobre au 15 novembre.

2. Sur le calendrier vous identifiez les jours feriés, ou les jours éventuels de fermeture de votre client.

3. On place sur le calendrier les dates importantes déjà négociées avec le product owner ou le client. Date de la démo, sprint review, sprint planning, go live,…

4. Vous identifiez chaque intervenant (Team Member, Scrum Master et Product Owner) par une couleur.

5. Chaque team member spécifie ses éventuelles vacances et disponibilités sur le calendrier.On distingue les jours « ON », la personne est sur le projet, et les jours OFF, la personne n’est pas disponible sur le projet.

Ensuite à vous de jouer avec les concepts de jour ON et OFF afin de ne pas surcharger votre calendrier et d’avoir une visibilité maximum.

Dans notre exemple les personnes à temps pleins précisent leurs jours d’absences « jours OFF », pour les personnes à mi–temps, elles précisent leurs jours de présence « jours ON ».

Exemple1: Bob est à 80% sur le projet, il ne sera pas disponible pendant 4 jours sur le sprint, il colle 4 post-its de sa couleur sur le calendrier avec la mention « Bob Off », ces jours là il n’est pas présent sur le projet
Exemple2: Gérard preste 2 jours sur le projet, il place 2 post-its de sa couleur avec la mention « Gérard ON » sur le calendrier.

6. Tout évènement important est ajouté en cours de sprint: présence du product owner, réunion éventuelle, déplacement à l’extérieur (et donc indisponibilité) etc.

Afin de conscientiser l’équipe à l’importance que nous donnons à cet outil, chaque mois un team member différent le réalise (temps de réalisation entre 5 et 15 minutes) . C’est aussi l’occasion pour chacun d’y aller d’un soupçon de créativité.

légende
Cliquez ici pour agrandir

« Okay Bruno, c’est bien ce que tu nous racontes mais, tu nous dis d’être visuel et dans ton article tu écris plein de texte… », « Bruno je dois dire… là je suis un peu perdu… » Ok tu as raison mon ami voici donc les points 1 à 6 réexpliqué de manière plus visuelle 🙂

This is it !

Une fois cet outil réalisé vous pourrez instantanément répondre à des questions comme:

Team Member: « Quand Gérard est-il présent ? J’ai besoin de lui pour finaliser mon module ! »

Product Owner: « J’aimerais valider les User Stories terminées, quel est le meilleur jour pour que je vienne cette semaine ? »

Team Member: « Quand organiser notre meeting avec le client et notre expert technique ? »

Team member: « il vient quand le product owner ? »

X: « C’est quand encore la démo ? J’ai pas reçu l’invitation ? »

Scrum Master: « Quel est le meilleur jour pour offrir un verre à l’équipe ?  » 🙂

et cerise sur le gâteau… ça fonctionne même en cas de panne du réseau, virus ou autre problème informatique !

Comme toujours, faite évoluer votre outil au fur et à mesure des sprints et en fonction des différents feedback de vos teams members (voir la galerie ci-dessous) !

Comme toujours, je ne vous demande pas de me croire…je vous invite juste à essayer. Allez-y testez cet outil, personnalisez le à votre façon, inventez vos propres règles…et donnez moi du feedback sur votre expérience 🙂

Bonne visualisations à tous,

Bruno.

The Visual Calendar, a « so Agile » Follow-Up Tool

Un exemple de "Visual Calendar"
An example of « Visual Calendar »

During the latest phase of our project, I had to work with a team of 7 people . But none of them was 100% on the project. To describe the situation we had:

-> Two team members 80% on project
-> Two part-time
-> One expert who was 15 days on the project over a period of 3 months
-> A person 20% on project
-> A person who was involved 5 days on the project, but when he was there … the whole team should be present.

This situation could have turned into a nightmare … how to be sure everyone has the right level of information? How to communicate? How to fix a meeting? If a developer need the webdesigner, how can we sure she will be present ?

Well at first i wanted to tell you i had invented a new tool that combines:

– a very advanced calculation algorithm
– advanced planning techniques
– a module with  availability management.

But the truth is far more simple…

Make it V-I-S-U-A-L

In fact these potential issues were solved fairly quickly because we used very powerful and easy-to-set-up follow-up and communication tool called « Visual Calendar ».

Visual Calendar consists of a large sheet of paper on which you draw a one month calendar on which you stick post-it notes.

Here’s how to set up this tool:

What do you need to create the "Visual Calendar"?
What do you need to create the « Visual Calendar »?

1. During the sprint planning, you build the visual calendar for the current month. A good practice is to match your sprint schedule. Example: imagine that your sprint #2 runs from October 19 to November 13. You also know that the sprint planning sprint #3 will take place on November 15 so you can build your Visual Calendar from October 19 to November 15.

2. On the calendar you identify the days-off, or any non-working day for your customer .

3. Place on the calendar all the dates already negotiated with the product owner or customer, e.g. demo, sprint review, sprint planning, go live …

4. You identify each member (Team Member, Scrum Master and Product Owner) with a color.

5. Each team member specify holidays and availabilities on the calendar. Day « ON », the person is on the project, and days « OFF », the person is not available on the project.

Then you play with the concepts of days ON and OFF to not overload your schedule and to have maximum visibility.

In our example the full-time staff indicate their days of absence « days off » for the people part – time, they specify their days of prence « days ON.

Example 1: Bob is 80% on the project, he will not be available for 4 days in the sprint, he sticks 4 post-its of his color on the calendar with the words « Bob Off » for the days he is not present on the project.

Example2: Gerard will be 2 days on the project, place 2 post-its of color with the words « Gerard ON » on the calendar.

6. Every « key » event is added during sprint presence of the product owner, meetings, travel outside, unavailabilities etc..

To raise awareness of the team to the importance we give to this tool, each month a different team member builds it (completion time between 5 and 15 minutes). It is also an opportunity for everyone to show some creativity.

Click here to enlarge
Click here to enlarge

Reader: « Okay, okay Bruno you seems to be a nice guy but… you tell us to make it visual and you only use text to explain your concept…strange isn’it ? »

Bruno: « What can i say…you’re totally right ! Here’s the Visual Calendar with a Visual explanation (Click to enlarge) « 

This is it!

With this tool you can immediately answer questions like:

Team Member: « Is Gerard present today ? I need him to complete my module! »

Product Owner: « I will validate some user stories, what is the best day for me to come this week? »

Team Member: « When can we organize our meeting with the client and our technical expert? »

Team member: « When is the product owner coming? »

X: « When is the demo ? I have not received the invitation? »

Scrum Master: « Which day is best to offer the team a Belgian beer ? » 🙂

and cherry on the cake … it works even in cases of network failure, viruses or other computer problems!

As always, i suggest you to update your tool according to your team’s feedback (see gallery below)!

As always, I am not asking you to believe me … Just give it a try!  Go test this tool, customize it your way, invent your own rules … and give me feedback on your experience 🙂

Cheers,

Bruno.


Definition of Done (DOD)… ou quand la mise en production devient une formalité…

[English Version Below: « Definition of Done (DOD)… or when the « Go Live » sounds like fingers in the nose »]

Un exemple de « Définition of Done » ou DOD.

Bob: « Voilà j’ai terminé de développer ce module, c’est déployé ! »

Gérard: « Ben je vois rien…? »

Bob: « Ha en tout cas chez moi ça marche… »

Allez, avouez…vous avez déjà tous vécu ce drame non ? 🙂

Une des choses que j’aime dans Scrum, et c’est selon moi une de ses plus grandes forces ! C’est que quand une tâche, ou disons une User Story, est terminée…et bien elle est vraiment terminée.  Dans le cas d’un projet IT, j’entends par là que c’est développé, testé, documenté, déployé sur le serveur de test etc… C’est ce que l’on appelle en Agile le Definition of Done (DOD). Le principe est simple pour mettre une User Story dans la colonne « Done » du tableau, il « suffit » que tous les critères du DOD soient remplis.

On utilise parfois le terme de « Production Ready », c’est à dire qu’une fois votre User Story terminée et validée par le client, elle peut être potentiellement mise en production. Plus aucune action n’est nécessaire.

Documentation

Concernant la gestion de la documentation nous essayons d’appliquer certains principes « Lean » à savoir ne produire que des documents à haute valeur ajoutée. Bien souvent nous arrivons à transformer la question « avez-vous de la documentation ? » en « mais que recherchez-vous comme information ? ». Ensuite nous fournissons l’information. L’idée est de ne pas passer des dizaines de jours à produire des documents rapidement dépassés. Attention ! Je ne fais pas le procès de la documentation elle est utile mais selon moi avec parcimonie. En écrivant ce paragraphe je me rends compte que cette seule problématique pourrait faire l’objet de plusieurs articles.

Tout ça pour vous dire que mon nouveau cheval de bataille pour la Doc c’est… l’utilisation de la vidéo. Personnellement j’utilise iShowU sur Mac qui permet de faire très simplement des vidéo de captures d’écran. J’y crois fermement: c’est rapide, plus amusant pour la personne qui doit prendre connaissance de la doc, plus facile à mettre à jour.

La mise en production

La plus grosse claque que je me suis pris en utilisant Scrum c’est à quel point la mise en production a été …. cool ! Oui vous lisez bien. En fait, vu que nous respections le DOD, vu que chaque mois nous faisions une Démo au client, la mise en production n’a été…qu’un sprint de plus. Vu que les procédures de déploiement étaient utilisées à chaque sprint, la mise en production a été un simple déploiement sur un autre serveur.

Bon maintenant je ne vais pas vous mentir… le jour de la mise en production mon pouls bat toujours plus vite et je m’attends à ce qu’il y ait des problèmes. Notre mise en production a quand même pris quelques heures et nécessité un ou deux légers ajustements manuels. Mais en toute sincérité, en plus de 10 ans de carrière, je n’avais jamais eu de mise en production aussi calme…et je dois dire que ce n’était pas pour me déplaire.

Capitaliser sur les tests

Plusieurs points du DOD portent sur le testing, l’avantage d’écrire les tests au fur et à mesure est qu’au moment de la mise en production vous avez un énorme « set » de tests qui peuvent vous donner un bon indicateur de la qualité de la release. De plus pour les releases suivantes, nous disposons d’autant de tests de régression. A ce sujet je voudrais remercier l’équipe avec qui j’ai travaillé car pour la première fois je n’ai pas dû « négocier » le fait qu’il fallait faire des tests. Un membre de l’équipe avait même mis au point un système obligeant que tous les tests soient « vert » à chaque commit…oui nous sommes de vrais psychopathes 🙂

Le "DOD" en contexte
N’hésitez pas, lors des « sprint review », à faire évoluer ce document

En conclusion, Le DOD est un document à faire vivre tout au long du projet, dans l’exemple de DOD que vous trouverez au bas de cet article vous verrez que l’on a rajouté certaines choses en cours de projet (attribution des droits utilisateurs et gestion des erreurs d’indisponibilité). Nous le considérons à ce point important que nous l’avons placé en plein milieu de Paul (C’est ainsi que nous appelons notre Tableau « Scrum »). Voir ci-contre.

Merci principalement à Bob et Gérard 😉

Bruno.

Voici un exemple de Definition of Done (ppt), n’hésitez pas à l’utiliser merci simplement de citer les crédits.

Definition of Done (DOD)… or when the « Go Live » sounds like fingers in the nose

légende
An example of « Definition of Done » or DOD.

Bob: « Okay, this is it, i have finished developing this module. Deployment is done ! »

Gerard: « Well, I can’t see nothing …? »

Bob: « On my workstation it works ! »

Come on, admit it … you’ve already lived such a drama isn’t it ? 🙂

One of the things I like in Scrum, and it my opinion it is one of its greatest strengths! I like that, when you said that a task or a User Story is done … well it is really done. In the case of an IT project, done means that stuff is developed, tested, documented, deployed on the test server etc. This is What Agile call the Definition of Done (DoD). The principle is simple: to switch a User Story in the column « Done » of the board, all the DOD criteria are met.

We sometimes use the term « Production Ready », meaning that once your User Story completed and validated by the client, it can potentially be put into production. No further action is required.

Documentation

Regarding the management of the documentation we try to apply some principles of « Lean ». I mean produce only documents with high added value. Often we can transform the question « do you have documentation? » in « what is you question ? What information are you looking for ? ». Then we provide the information. The idea is not to spend tens of days to produce documents quickly outdated. Warning! I’m not on trial with « doing documentation ». Documentation is useful but I think it is a means and not a goal to achieve. While i’m writing this paragraph I realize that this problem could be the subject of several articles.

Anyway the point is that i have a new crush about how we can do documentation… the use of video. Personally I use iShowU on the Mac that allows you to do video screenshots in a very simple way. I strongly believe in this: it is faster, more fun for the person who must « read » the document, easier to update.

The Go Live

The biggest slap that I receive using Scrum is how the production launch (i mean the go live) was …. cool! Yes you read it well. In fact, as we respect the DOD, as each month we did a demo to the client, the go live has been … just another sprint and no more. Since the deployment procedures were used for each sprint, the start of production was a simple roll on to another server.

Well now I will not lie to you … when the date of the go live comes close,  my pulse start to beats faster and faster and I expect problems and bad surprises. Our production launch has nevertheless taken a few hours and needed one or two minor manual adjustments. But honestly, in more than ten years of my career, I had never a go live o easy … and I must say that this was not to displease me.

Capitalizing on tests

Several points of the DOD concern testing, the advantage of writing tests is simple… When you are ready to deploy, you have a huge « set » of tests that can give you a good indicator of the quality of the release. In addition, for the next versions of your software, you can still use the « old » tests for the regression testing. By the way, i would like to thank the team with whom I worked. For the first time I did not have to « negotiate » the fact that we must write tests. They were all a lot « quality minded ». A member of the team had even developed a system requiring that all tests must be « green » to each commit … yes we are true psychopaths 🙂

Le "DOD" en contexte
DOD in context, don’t hesitate to update it on each « sprint review ».

Finally, DOD is a living document and his lifetime is the time line of the project, in the example of DOD that you find at the bottom of this post, you will see that we added some things during the project (allocation of user rights and negative error handling). We consider that DOD is so much important that we placed it in the middle of Paul (So we call our « Scrum » Board). See picture.
I would like to thanks Bob and Gerard 😉

Bruno.

More info: Example of Definition Of Done (ppt): Feel free to use it, just give me some credits.


Scrum et les méthodes Agile en tant qu’opportunité Business

[English version below: « Scrum and Agile methods as a Business opportunity! »]

Comment Scrum peut vous faire décrocher des contrats…

Alors ça y est, vous avez découvert Scrum ! Vous en avez parlé avec d’autres collègues ou amis, vous avez lu moult blog et articles. Votre matériel est prêt, vous avez lu des livres jusqu’à plus soif. Vous avez sélectionné un projet que vous pourriez…que dis-je…que vous voulez réaliser en utilisant Scrum ! Vous êtes fin-prêt.

Reste juste un léger détail à régler… le budget, et là souvent c’est le drame. En effet, autant Scrum et les méthodes Agiles peuvent être séduisantes pour des personnes travaillant dans l’ICT, autant elles peuvent paraître saugrenues ou étranges à des décideurs (Sponsors, CTO, Clients,…). Or, cher Scrum Master dans l’âme, c’est précisément ces personnes qu’il faudra convaincre de l’intérêt de cette méthode car ce sont ces personnes qui vont décider d’allouer ou non du budget pour ce projet.

Une réelle opportunité business

Lors de mon dernier projet dans le secteur public Belge, j’étais là, à l’origine, pour une mission de consultance afin de coordonner la rédaction un cahier des charges pour la réalisation de deux portails Web. Nous avons écrit le cahier des charges en collaboration avec le client mais au moment de l’estimation du budget (de plus de 2.000.000 €) le client nous signale qu’il n’a pas cette somme. Les problèmes n’arrivant jamais seuls,  nous étions de plus confrontés à un autre problème: la longueur de la procédure de l’appel d’offre. Et pour couronner le tout, pour des raisons qui lui sont propres, le client avait besoin d’avoir « quelquechose » 7 mois plus tard.

Suite à cela pour gagner du temps sur la procédure d’appel d’offre, mon Manager me propose d’utiliser une procédure d’appel d’offre simplifiée, plus rapide mais beaucoup plus risquée. C’est à ce moment là que je lui ai parlé de Scrum. Je lui ai parlé de la méthode non pas en termes de daily scrum, product backlog ou sprint review. Je lui ai simplement expliqué que je connaissais une méthode qui pouvait en 6 mois délivrer « quelquechose » qui tourne en production. Je lui ai donc fait une proposition d’équipe type en fonction des besoins de notre projet:

  • 2 personnes ayant un profil d’Analyste Programmeur expérimenté
  • 1 personne ayant un profil de Webdesigner
  • 1 personne ayant un profil d’Architecte
  • 1 Scrum Master (votre humble serviteur)
  • 1 personne ayant un profil d’Expert en Géolocalisation

Le budget disponible pour le projet étant fixe, nous avons décidé de mettre sur pieds une équipe mixte composée d’internes et d’externes. Il nous restait alors à « traduire » le cahier des charges en une suite de User Stories consignées dans notre product backlog.

Résultats à ce jour:

  • Pour notre client une success story à un budget bien moindre
  • Pour notre société de consultance, plusieurs consultants sur projet pendant 1an et demi
  • Pour votre serviteur, avoir pu utiliser Scrum avec succès et le mettre au service du client

Des compromis

Vous l’avez donc compris, dans une majorité des cas, pouvoir réaliser un projet en utilisant Scrum/Agile passera par l’assentiment d’une personne généralement peu au courant de ces méthodes. La principale difficulté sera de faire accepter à votre sponsor, client que vous vous engagez sur un ensemble d’axes à réaliser, un ordre de grandeur et pas sur une liste de fonctionnalités précises (le product owner pouvant changer d’avis).

N’hésitez pas à raisonner avec votre client en terme de contraintes: Budget, Planning, Fonctionnalités. Dans notre exemple nous avons convenu avec notre client d’une deadline fixe, d’un budget fixe mais en lui demandant de pouvoir « jouer » sur les fonctionnalités. Et vous savez quoi ? Ca tombe bien vu que c’est principalement un des atouts de Scrum 😉

N’hésitez pas également à faire des compromis… Votre client a peut-être déjà une méthodologie en place vous « obligeant » à produire certains document: Project Charter, P.I.D, Progress Report. C’est une bonne pratique de négocier comme ceci: ok je vais faire tes documents de méthodologie et de ton côté tu t’engages à respecter la méthode.

Si vous n’avez pas la fibre commerciale n’hésitez pas à demander conseil à un chef de projet, à un coach ou pourquoi pas un de vos « commerciaux » dans votre société ils pourront vous donner d’excellents conseils sur la meilleure manière d’amener cette méthode à un client.

Enfin vous pouvez aussi rassurer votre client en démarrant un projet pilote. Choisissez alors un petit projet court à risque très limité. Une réussite sur un tel projet vous amènera certainement d’autres opportunités.

Parce qu’en fin de compte l’idée derrière tout ça c’est de pouvoir utiliser une méthode qui amène du sens dans l’entreprise et mettre cette méthode au service des besoins du client…non ?!

Bonne chance à tous dans vos réalisations !

Bruno.

Ps: Les deux Portails Web que nous avons réalisé en utilisant Scrum et les méthodes Agile: Portail Bruxelles Mobilité et Portail Espaces Publics

Scrum and Agile methods as a Business opportunity!

how to get to use Scrum at the client's place
how to get to use Scrum at the client’s place

So there it is, you’ve discovered Scrum! You’ve talked with other colleagues or friends, you read a lot of blog and articles. Your stuff is ready, you read books until you felt asleep. You have selected a project that you could … no … that you want to achieve using Scrum! You are so ready !

Mmmm just a little detail to be … budget, and often there is the fall. Indeed, on one hand, Scrum and Agile methods can be attractive for people working in IT, on the other hand, they may seem incongruous or strange to decision makers (CEO, Sponsors, CTO, Customer ,…). Now, dear Scrum Master to be, it is precisely these people that need to be convinced of the usefulness of this method. Because it is these people who will decide whether to allocate the budget for this project.

A real business opportunity

My last project was for the Belgian public sector…yes you know…Belgium…right here I was there originally for a consultancy mission to produce a call of tender for the creation of two Web portals. We made the specifications in collaboration with the client but when comes the estimated budget (over € 2,000,000) the customer indicates that we did not have that amount. The problems never come alone, we were increasingly confronted with another problem: the length of the procedure of the call of tender. And to top it off, for reasons of its own, the client needed to have “something” 7 months later.

Following this to save time on the invitation to bid, my manager offered me to use another procedure, faster but more risky. At that time I told him about Scrum. I told him about the method not in terms of daily scrum, product backlog and sprint review. I simply explained that I knew a method that could deliver in 6 months “something” that can go live. So I sent him a proposal of a “composition of team” on the needs of our project:

* 2 people with a profile of experienced Analyst Developer
* 1 person with a profile Webdesigner
* 1 person with a profile of Architect
* 1 Scrum Master (me)
* 1 person with an expert profile in Geolocation

The budget available for the project was fixed, so we decided to set up a joint team of internal and external people. We still had to “translate” the specifications to a series of User Stories reflected in our product backlog.

Results so far:

* For our client a success story at a much lower budget
* For our consulting firm, several consultants on the project for one year and a half
* For me, have been successfully used Scrum and to fill the customer expectations

Compromises

If you are a married guy/woman or have a girlfriend/boyfriend…you’ll understand this topic Okay i apologize for the macho style.

You get it right, if you want to be able to achieve a project using Scrum / Agile you will need a GO from a person generally unfamiliar with these methods. The main challenge will be to make your sponsor, customer and you agree on a set of mains prorities to achieve and not on a list of very specific features (because the product owner may change his mind).

Feel free to discuss with your customer in terms of constraints: Budget, Planning, Features. In our example we have agreed with our client a fixed deadline, a fixed budget but asking him to “negotiate” on features. And you know what? What a coincidence.. It is mainly one of the asset of Scrum

Feel free also to compromise … Your client may have already methodology in place, and maybe he has spent a lot of money to specify some standards of project management. If you are “forced” to produce certain document: Project Charter, PID, Progress Report. It is good practice to negotiate like this: ok I’ll make your documents and methodology on your side you agree to follow some Agile/Scrum principles ?

If you do not have the commercial or business talent do not hesitate to seek advice from a project manager, a coach or why not one of your business manager in your company they will give you excellent advices on the best way of “make it happend” to a client.

Finally you can also reassure your client by running a pilot project. Then choose a small project with very little risk. Success on such a project will certainly lead you to other opportunities.

Because, ultimately the idea behind it is to use a method that bring more sense in the company and use this method to serve customer needs … no? “

Good luck to you fo all your achievements!

Bruno.

Ps: The two Web Portals we have achieved using Scrum and Agile methods: in french and dutch: Portal Brussels Mobility and Public Spaces


Vidéo sur Scrum: Application de Scrum sur la création de deux portails Web (2008)

[English version below: Scrum Video: Scrum works in the real world!]

[EDIT: Cette vidéo a été réalisée en 2008 lors de mon premier projet Scrum, elle comporte sans doute quelques erreurs quand à la bonne pratique des puristes mais elle a le mérite de montrer l’esprit Scrum]

Voici une vidéo de 5 minutes qui se veut un retour d’expérience sur Scrum. L’idée était de faire une activité sympa en équipe (la réalisation de la vidéo) tout en faisant la promotion d’une méthode (Scrum) que nous trouvons efficace. Nous voulions aussi faire le lien avec un projet existant et pas juste une vidéo expliquant le concept.

Cette vidéo a été réalisée au cours d’un projet en utilisant le framework Scrum. Ce fut une grande expérience pendant 6 mois: un partage d’expériences, d’échanges, un peu de stress mais beaucoup de bonne humeur et avec finalement deux Portails Web.

Aucune pub ou lobbying ici! Nous voulons tout simplement partager une bonne méthode qui facilite la réalisation d’un projet.

Scrum fait partie du « Monde Agile » et est totalement gratuit.
Voir: https://en.wikipedia.org/wiki/Scrum_(software_development)

Introduction: La scène d’ouverture de « Le Seigneur des anneaux: La communauté de l’anneau », réalisé par Peter Jackson

Musique: Red Hot Chili Peppers « Snow »

Scrum Video: Scrum works in the real world!

Here it is !

A 5 minute video which is a feedback on Scrum. The idea was to make a fun team activity (the creation of the video) while promoting a methodology (Scrum) that we find effective. We also wanted to link to an existing project and not just a video explaining the concept.

This movie was realized during a project using the scrum methodology. This was a great experience during 6 months: an experience sharing, exchange, a little bit stress but lots of good humor and with finally 2 Web Portals.

No commercial or lobbying here ! We just want to share a great method that facilitates the realization of a project.

You won’t see any commercials for our company, just thanks to other people, or mention tools (all free and open sources).

Scrum is part of the « Agile World » method and is totally free.
See: https://en.wikipedia.org/wiki/Scrum_(software_development)

Introduction: Opening scene of « The Lord of the Rings: The Fellowship of the Ring » directed by Peter Jackson

Music : Red Hot Chili Peppers « Snow »