Blog

Démarrer une intervention Agile en mode Scrum

[English version below « A Scrum Kickoff… »]

Votons !

En général quand je démarre une mission « Agile », mon premier souci est de comprendre comment fonctionne la société. Comment les différents départements collaborent entre-eux.

Il y a quelques mois de cela, j’étais précisément à cette étape. J’avais rencontré 30 personnes des différents départements de la société. Et me voilà à me demander ce que je vais faire de toute ces informations et différents feedbacks.

Pour information, lors de cette étape je leur demandais d’expliquer leur job et comment ils contribuaient à la réalisation des projets. Je leur ai également demandé selon eux ce qui fonctionnait bien et les problèmes qu’ils rencontraient.

La Présentation

Pour transmettre mes résultats je n’avais que 2 heures de réunion prévue. Je voulais qu’ils aient une vue d’ensemble, je voulais que le groupe soit actif et enfin je voulais avoir l’opportunité de d’introduire Scrum. J’avais des slides sur Scrum que j’aurais pu réutiliser mais je voulais éviter une réunion du type « je parle, ils écoutent ». Et ce bien que ma maman m’ait maintes fois répété que j’avais une voix merveilleuse 😉

La première partie de la présentation consistait à discuter ce qui fonctionne bien dans la société et ce que l’on peut améliorer. Dans un tel exercice il est selon moi important de faire l’effort de découvrir aussi ce qui va bien. Car l’on veut capitaliser sur les bonnes pratiques…et non les abandonner. De plus une longue liste de choses « négatives » peut être immédiatement très démotivante. J’avais donc 4 slides: 2 avec les choses positives et 2 avec une liste d’améliorations possibles.

En résumé donc, je voulais que cette meeting soit:

  • Un feedback sur ma période d’observation
  • Une introduction à Scrum

Et je voulais que les participants:

  • Soient actifs
  • Vivent la méthode

Le Processus utilisé

J’ai démarré la réunion en donnant à un participant un paquet de post-it vert et un autre rouge. Ensuite je lui ai demandé d’en prendre un de chaque et de passer le paquet à son voisin. Dans cette phase j’ai été intentionnellement directif et je vérifiais secrètement le temps pour que chacun aie ses deux post-it. Le temps écoulé: 124 secondes.

Ensuite je leur ai demandé d’écrire « Oui » sur le post-it vert et « Non » sur le post-it rouge. Ensuite, j’ai commencé ma présentation. A chaque fois que j’annonçais un point positif, ou une piste d’amélioration, je leur demandais de voter pour voir s’ils étaient d’accord ou pas. Le vote se faisait en levant simultanément un seul post-it (Oui ou Non) par participant. Rendons à César ce qui appartient à César, j’avais vu cette manière de voter utilisée dans des conférences, notamment par Henrik Kniberg et Claude Aubry.

Les slides suivants de la présentation concernaient Agile et Scrum. Certains slides comportaient des provocations comme: “Agile est une méthode magique qui va régler tous mes problèmes ». Lors de ces slides je demandais également aux participants de voter. Ce genre de slides accompagné du système de vote a également amené d’intéressantes conversations.

A la fin de la présentation, je leur ai demandé si Scrum était clair pour eux. Ils m’ont répondu « Oui » et ensuite je leur ai annoncé qu’ils venaient d’effectuer un sprint…et que nous allions en démarrer un second immédiatement. Ils étaient quelque peu surpris.

de 124 secondes à 42 secondes en utilisant Scrum

Donc je leur ai expliqué que le premier sprint (la distribution des post-it) avait pris 124 secondes…Ce qui était bien entendu malhonnête de ma part vu qu’ils n’étaient pas au courant 🙂

Donc, je leur ai proposé un second sprint.

L’objectif, du sprint 2 était: “Réaliser la user story aussi vite que possible ». Et la user story était En tant que présentateur, Je veux que chaque participant ait un post-it vert et un post-it rouge afin de leur permettre de voter ». Je leur ai laissé 5 minutes de préparation, en ensuite à leur « GO » je démarrais le chrono. A la fin du sprint, le résultat était: 42 secondes. Waouw ! Seulement un tiers du temps initial.

Il y a eu un évènement cocasse. Un participant était fier de me montrer qu’il avait 2 rouges et 2 verts m’annonçant qu’il avait été « le plus productif ». Malheureusement en tant que client le fait qu’il ait 2 rouges et deux verts ne me donnait aucune valeur ajoutée…

Cela a été une bonne occasion d’introduire le concept suivant: faites ce que le client vous a demandé puis arrêtez.

Donc ce simple processus utilisé m’a permis d’introduire aux participants ces différents concepts:

  • auto-organization
  • Le principe Scrum « inspect and adapt »
  • Les user stories
  • Les réstrospectives
  • Travailler en équipe
  • « faites ce que le client vous a demandé puis arrêtez »

Puissant non ? Qu’en pensez-vous ? Quelqu’un a-t-il déjà utilisé un processus similaire ?

Bye

Bruno.

A Scrum Kickoff…

Let’s vote !

Usually when I start an Agile « Mission » my first concern is to understand how the company works. How the different business departments collaborate together.

A few months ago I was just in this step. I met 30 people from all departments of the company. And so I was there with plenty of feedbacks wondering “How will I use these information”.

Basically I just asked them to explain me their job and how they contribute to a project within the company. I also asked them what works well and what are the main problems.

The Presentation

I wanted them to understand the big picture, and wished to do it in an active way with the opportunity to introduce Scrum. I already had plenty of usable Scrum slides, but wanted to avoid a “Me speaking, them listening” effect; even though my mom used to say I have a beautiful voice 😉

The first part of the presentation was to list what works well within the company, and what can be improved. For such exercise, it’s important to insist on what works well, because we still want to continue working that way right ?! Moreover, a long list of “negative” things can create immediate demotivation. So I had 4 slides: 2 with “Positive things” and 2 named “list of possible improvements”.

So to summarise I wanted this meeting to be:

  • A feedback on the study period
  • An introduction to Scrum

And I wanted the participants:

  • To be active
  • To live the method

The Process

I started the meeting by giving to one participant a bunch of green and red post-it notes. Then, I asked him to take one of each and pass them to his neighbor. I was intentionally very directive and I was (secretly) tracking the time they took to complete the procedure. It took them 124 seconds to have all the post-it notes distributed to the participants.

Secondly, I asked each of them to write ‘Yes’ on the green post-it and ‘No’ on the red post-it. Then, I began my presentation. Every time I would announce a positive thing, they were asked to vote if they agree. The same exercise was done with the ‘list of possible improvements’. The participants had to raise a ‘Yes’ or  ‘No’ post-it to vote. I saw this technique used in conference by Henrik Kniberg and by Claude Aubry.

The next slides of my presentation aimed at Scrum topic. A few slides were thought provoking like: “Agile is a magic method and will solve all my problems”.

The vote + those kind of slides led to interesting discussions.

At the end of the presentation I asked them if Scrum was clear for them, and once they answered “Yes” I told them that they just did one sprint and that we will start the second sprint right away. They were a bit surprised 😉

from 124 seconds to 42 seconds using Scrum

So I explain them that the sprint 1 took 124 seconds which was unfair from me of course because they were not aware 😉

Therefore, I proposed them do a second sprint.

Objective of sprint 2 was: « “Perform as quickly as possible ». The user story to do as a team was: As a presenter, I want each participant to have one green post it notes and one red so I can use it to have them vote”. They had 5 minutes of preparation, then they had to give me the “Go” to start implementation. At the end of this sprint, the result was : 42 seconds. Waouw ! Only one third of the original time.

One funny thing did happen, one participant proudly told me “Hey look I have 2 green and 2 red !”. He thought he had reached another objective. However, as a client, I had no added-value to have a participant with 2 greens and 2 reds.

It was a nice opportunity to introduce the “do just what your client asked then stop” concept.

So this simple process was for me the opportunity to introduce them to:

  • self organization
  • the « inspect and adapt » concept
  • the user stories
  • the restrospectives
  • Working with 5-9 people teams
  • the « do just what your client asked then stop » concept

Quite powerful isn’it ?

If you have any thought or any comment about this, feel free to write me or to leave a comment

Cheers

Bruno.

Ps: Billet écrit en écoutant cette chanson: Mixtapes – Hope is for People


Liste de liens sur Agile et Lean

[English version below « Toolbox: A list of Agile & Lean links »]

Ps: Post written listening Darling Thieves – Ignore the Whisper

The missing link ?

Bonjour,

Dans ce billet, vous trouverez une liste de liens sur Lean et l’Agilité. Ces liens sont parmi ceux que j’utilise le plus dans mon travail. J’espère qu’ils pourront vous être utile.

Scrum

Liste de templates Agile ? Templates de Product Backlog, Sprint Backlog,… http://bit.ly/btxh6S

La Checklist Scrum : Simple et si puissante… http://www.crisp.se/scrum/checklist

User Story Mapping le Workshop de Jeff Patton http://bit.ly/knsOdj

La clé pour être efficace dans la résolution de problème est d’avant tout être certain que l’on comprend le problème que l’on essaie de régler, pourquoi il y a besoin de le régler et comment on saura qu’il est réglé. Le « A3 thinking » est là pour vous y aider: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf

De l’aide pour donner des priorités avec Agile: le modèle Kano de satisfaction du consommateur. http://bit.ly/g3LITC

Jeux Agile (Agile Games)

Une liste de jeux Agile que vous pouvez jouer avec vos équipes ! http://blog.tastycupcakes.com/category/games/

Des jeux Agile pour l’apprentissage http://www.agilefairytales.com/games.html

InfoQ: Jouer pour apprendre http://t.co/00iwQzc

Apprendre en jouant à des jeux ?

Divers

La boîte à outils du coach: http://www.agilecoach.net/

Répondre aux  objections avec humour http://bit.ly/kOyRs9

Utiliser un process Agile dans le cadre de l’outsourcing http://bit.ly/lcWSV8

Agile Open Belgium et le principe d’« Open Space » http://www.agileopen.net/on-open-space

Une vidéo intructivehttp://bit.ly/gIoQyD RSA Animate La surprenante vérité sur ce qui nous motive…

Et enfin, ceci n’est pas à proprement parler un lien Agile mais j’aime beaucoup le concept! Voyez comment on peut changer les comportements en utilisant le « Fun«  http://www.thefuntheory.com

Bon surf à tous,

Bruno.

Ps: Billet écrit en écoutant Darling Thieves – Ignore the Whisper

Toolbox: A list of Agile & Lean links

Dears,

The missing link ?

You will find in this post some Agile and Lean links that I use most.

Scrum

Do you need Agile templates ? Templates of Product Backlog, Sprint Backlog and Scrum Tools: http://bit.ly/btxh6S

The Scrum Checklist: This is so Simple and Powerful… http://www.crisp.se/scrum/checklist

User Story Mapping Workshop by Jeff Patton http://bit.ly/knsOdj

The key to effective problem solving is to first make sure you understand the problem that you are trying to solve – why it needs to be solved, how you will know when you’ve solved it, and what the root cause is. This what A3 thinking is all about: http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf

Help for Agile prioritization: Kano model of customer satisfaction http://bit.ly/g3LITC

Agile Games

A list of a lot of Agile Games you can play ! http://blog.tastycupcakes.com/category/games/

Great Agile and Learning Games http://www.agilefairytales.com/games.html

InfoQ: Agile Games for Learning http://t.co/00iwQzc

Learn by playing games

Various

The Agile Coach Toolkit: http://www.agilecoach.net/

A nice way to handle Agile objections http://bit.ly/kOyRs9

Using an Agile Software Process with Offshore Development http://bit.ly/lcWSV8

Agile Open Belgium and the « Open Space » principle http://www.agileopen.net/on-open-space

Nice Video seen during a Training http://bit.ly/gIoQyD RSA Animate The surprising truth about what motivates us…

And last but not least…Not an Agile Link but I like the idea ! See how fun can change behaviour for the better at http://www.thefuntheory.com

Surf safely 😉

Bruno.


En quoi Star Wars peut vous aider dans votre dynamique d’équipe (Agile)

Conference Agile France 2011

Bonjour à tous,

C’est confirmé je présenterai une session intitulée « En quoi Star Wars peut vous aider dans votre dynamique d’équipe (Agile) » à Agile France 2011.

Agile France se déroulera les 26 et 27 Mai 2011. Toutes les infos sont présentes sur le site officiel ainsi que le programme.

La session sera sous la forme d’un atelier interactif. Quelques infos sur la session proprement dite…

Vous pouvez avoir les meilleurs outils dans votre équipe, sans une bonne cohésion il vous sera difficile de mener votre projet à bien.
Lorsque nous travaillons ensemble, lorsque nous communiquons, chaque membre d’une équipe utilise inconsciemment différent style de management (ou de leadership). Et ce qu’il soit Manager ou non.
Ensemble nous verrons et expérimenterons comment les styles de management peuvent aider à construire une forte cohésion d’équipe (même dans une équipe auto-organisée) et comment ils peuvent être utilisés par tous les membres d’une équipe.
Je serai assisté par quelques coachs célèbres tels que Yoda et Darth Vador.

Les objectifs de cet atelier sont:

  • Introduire ou rappeler différents  style de management (ou de Leadership)
  • Différencier Leadership et Management
  • Expérimenter les différents styles
  • Considérer l’utilité des styles de management (quelle que soit la fonction que j’occupe)
  • En conclure des applications concrètes dans des équipes Agile

Venez participer… vous êtes les bienvenus

Bruno 😉


Agile Games 4 Scrum Teams

Atelier Agile Games au Scrumday France

Présentation de l’atelier réalisé lors du Scrum Day France, le 31 mars 2011.

Une excellente journée qui a rassemblé plus de 400 personnes autour d »un même sujet Scrum.

Jeux joués lors de l’atelier:
Ball Point Game, Name Game, Constellation Game, Fist of Five et Talking Game.

Connaissez-vous les « Agile Games » ou Jeux Agile ? Ils sont apparentés à la discipline des « Serious Games ». Mes excuses pour tous ces anglicismes dans une seule phrase 🙂

Ces jeux vont vous permettre d’expérimenter et d’améliorer votre connaissance des méthodes et principes Scrum (et Agile).

Le fait de mettre les participants en action favorise l’apprentissage. De plus il a été observé que l’être humain apprend efficacement si l’expérience se passe dans une atmosphère détendue en passant un bon moment.

Pendant 90 minutes nous jouerons un maximum de jeux ayant pour thèmes les estimations, l’auto-organisation et autres principes Scrum & Agile.

Merci à tous pour votre participation !

Bruno.


2/5 Personnalité des différents acteurs (Cinq facteurs de succès pour vos projets Agile/Scrum)

[English version below « 2/5 Personality of the different actors (Five keys to succeed in your Agile/Scrum projects) »]

Cet article s’inscrit dans la série: Cinq facteurs de succès pour vos projets Agile/Scrum il fait suite à 1/5: L’équipe est « multi-tâches ». 

Vous pouvez avoir les meilleures technologies et outils à votre disposition. Si le dynamique de votre équipe n’est pas bonne, vous aurez toute les difficultés du monde à faire aboutir votre projet. Lors de la composition d’une équipe Scrum, il est bon de mettre toute les chances de votre côté. 

Je vais donc vous décrire (brièvement) ci-après quelques outils qui vont vous permettre de sélectionner vos « team-members » et de coacher votre équipe. 

Ci-dessous, vous trouverez quelques attitudes qui, une fois adoptées, vous aideront à atteindre vos objectifs. 

Actif – Passif

Actif ou Passif ?

Comment reconnaît-on quelqu’un de passif…ou d’actif ? Quand il est face à un problème. Si les objectifs que je dois atteindre sont clairs, comment est-ce que je me comporte face à une difficulté ? 

Exemple: je dois imprimer un document et le remettre à mon responsable pour la fin de journée. 

Problème: l’imprimante n’a plus de papier 

Exemples de réaction passive: 

  • Je lui explique en fin de journée que je n’ai pas su imprimer à cause du manque de papier
  • Je prends tout l’étage à parti en disant que c’est quand même un scandale qu’il n’y ait plus de papier
  • J’envoie un mail au responsable logistique afin qu’il prenne des sanctions car normalement le papier doit être réapprovisionné chaque jour.

Exemple de réaction active 

  • J’essaie de trouver des rames de papiers à un autre étage
  • J’essaie d’imprimer sur une autre imprimante (éventuellement avec l’aide du helpdesk)
  • J’utilise des feuilles de brouillon pour imprimer

Même si cet exemple peut paraître caricatural: on reconnaît quelqu’un d’actif à ce qu’il met en oeuvre lorsqu’il est confronté à un problème. 

Je suis « actif » si, lorsque je suis confronté à un problème qui m’empêche d’atteindre mon objectif, je mets en place des actions qui me permettent d’atteindre cet objectif. 

Exemple d’attitudes passives: 

  • Tu en es où avec ça ? Heuu j’ai envoyé un mail mais ils ne m’ont toujours pas répondu… !
  • Acter par email que l’on n’a pas su atteindre son objectif en ayant un coupable « potentiel »
  • « Je leur ai envoyé 3 mails et toujours aucune réponse ! »
  • « Il n’y a plus de réseau…je ne sais plus rien faire 🙁
  • C’est X qui doit s’en occuper mais je ne sais pas quand il le fera…je suis pas son chef !
  • « Je sais pas avancé je suis bloqué! »

Exemple d’attitudes actives: 

  • Aller voir quelqu’un en face à face
  • Identifier la personne dans l’organisation qui peut résoudre mon problème
  • Lorsque quelqu’un me dit « je ne suis pas disponible maintenant », prendre un rendez-vous à une heure ultérieure précise
  • Aller chercher l’information
  • Demander de l’aide
  • Demander « Qui est responsable pour…? »

Donner et recevoir le feedback

le plus beau des cadeaux !

Certaines méthodes Agile comme Scrum ont déjà certains mécanismes de feedback inclus comme la Daily meeting et les rétrospectives. 

Il est important pour les membres d’une équipe de se donner du feedback et d’accepter le feedback en retour. Cela favorise la cohésion d’équipe et démine les situations potentiellement problématiques. Il sera difficile de construire une bonne dynamique d’équipe avec des attitudes du type… « de toute façon je suis comme je suis, je ne changerai pas ». 

Il faut considérer le feedback, s’il est donné de manière bienveillante et compétente comme un vrai cadeau que l’on vous fait. 

Il existe des techniques pour donner et recevoir du feedback, si cela vous intéresse je pourrai faire un billet là-dessus. 

S’il y a une tension entre deux personnes. Une fois que l’on a enlevé tout l’émotionnel, les jugements et les lectures de pensée. Il est souvent très impressionnant de constater le teneur réelle du problème qui est souvent très légère. 

Exemple: 

  • M: « tu n’as aucun respect pour les autres ! » (ceci est une lecture de pensée, face à un fait, par exemple une interruption, on déduit ce qu’est la personne. Le but en PNL est d’éviter les lectures de pensée, ou si on en a, d’essayer de les (in)valider en discutant avec l’autre)
  • S: « ok isolons-nous pour en discuter quand tu seras calmé »
  • (…)
  • S: Voilà je t’écoute
  • M: Bon tu m’interromps sans arrêt ! Toutes les 5 minutes tu me poses des questions

La solution dans un cas pareil sera peut-être simplement que S note ses questions au fur et à mesure, et ensuite qu’il s’arrange pour prendre 1 heure avec M pour en discuter. 

Être orienté « projet »

Une bonne orientation

Lors de mes suggestions ou de mes décisions sur un projet. Est-ce que je décide en fonction de mon intérêt personnel ? Exemple: je vais utiliser tel framework car je rêve de l’essayer ! 

Ou est-ce que je mets dans la balance l’intérêt du projet, les choix qui vont vraiment permettre à mon client d’être satisfait et au projet de se porter bien. 

Exemple d’orientation projet: choisir un framework en tenant compte de son potentiel mais également de la connaissance de ce framework par les autres membres de l’équipe. Est-ce que le projet peut se permettre que toute l’équipe prenne le temps de se former sur ce framework ? 

Être orienté projet ne signifie pas se diluer et en oublier ses objectifs personnels. Mais c’est, dans nos choix, prendre également en compte l’intérêt de l’équipe et du projet. 

Le désaccord

…ou pas

Il existe différents types de désaccord. 

Par polarité: Quelqu’un qui dit toujours le contraire de ce que vous avancez 

Par comportement: émettre des bruits avec son bic, soupirer bruyamment, reculer sa chaise de 1 mètre par rapport à la table 

Le « Oui mais »: à chaque fois que l’on avance quelque-chose, on vous répond par une phrase commençant par un « oui… mais ! » 

Le changement de taille de découpage: changer de sujet, parler d’autre chose. Exemple: à une réunion sur les spécifications: « Bon la façon de déployer en production ça va pas du tout ! » 

Par commentaires: Vous annoncez quelques chose et on vous répond quelque-chose comme « hein tu en as souvent des idées comme ça ? » ou « pfff n’importe quoi! » 

Il y a deux choses importantes par rapport à quelqu’un qui fait du désaccord: 

Un, il y a toujours un message derrière le désaccord, il est important pour le coach, le leader d’arriver à le décrypter. Lors d’une formation que je donnais, un participant faisait du désaccord par comportement. Je me suis posé la question du pourquoi et je me suis aperçu que j’avais démarré la formation en français. J’ai demandé si le français était ok pour tout le monde et il s’avérait qu’on avait prévenu les participants que la formation se donnerait en anglais. J’ai alors continué en anglais, la personne en question ne parlait que très mal le français, et tout de suite, son attitude a changé. 

Deux, quelqu’un qui fait du désaccord va coûter énormément d’énergie au groupe. Imaginez une réunion de 2 heures avec 10 personnes. Si quelqu’un fait constamment du changement de taille de découpage, vous pouvez perdre 20h de travail… Même si les sujets abordés étaient « importants » vous n’avez pas pu tenir votre agenda initial. Il faut donc gérer le désaccord, dans ce cas précis remettre la réunion sur les rails. 

Quelle utilité ?

Pour quoi faire ?

A quoi vont vous servir ces outils ? 

Ces outils peuvent être utiles pour sélectionner vos team members. En effet si vous ne sélectionner que des personnes ayant une tendance au désaccord et passives… je vous souhaite bien du plaisir 😉 

Vous pouvez également présenter ces outils et préciser ce que vous attendez. Vous aurez compris que dans une équipe, être actif, donner et accepter le feedback, être orienté projet et ne pas être trop en désaccord seront autant d’attitudes qui vont vous aider dans le succès de votre projet. 

Plutôt que d’utiliser cela comme un outil de diagnostic: « Toi tu viens pas dans l’équipe t’es trop passif ! ». Le plus intéressant selon moi avec ces outils c’est de les présenter à tous, de les expliquer et de décrire ce que l’on attend de chacun

Amusez-vous ! 

Bruno. 

Ps: Ces outils viennent de la PNL (les méta-programmes)  

2/5 Personality of the different actors (Five keys to succeed in your Agile/Scrum projects)

Personality aspects of team members

This post is part of the series Five keys to succeed in your Agile/Scrum projects. It follows 1/5: Team is “multi-tasks”.

Despite the best technologies or tools you can use on your project, the energy and team-spirit of your team is the key to succeed a project. Here are some tips to set up your Scrum team.

You’ll find below some tools used to identify your team members and coach them.

Active or Passive attitude

Active or Passive ?

What is an active or passive behaviour? And how do you identify it?

When someone faces an issue, what is his reaction ?

A simple example behaviour would be:

“I need to print a document and give it to my management by the end of day… Unfortunately, the printer is out of paper”

Examples of a Passive behaviour :

  • I will explain I haven’t been able to print because the printer was out of paper
  • I tell everyone it’s a shame the printer is out of paper and that I can’t do my job
  • I inform the head of logistics department in order to take the penalties because paper supply is empty… Although it is supposed to be filled daily

Examples of an Active behaviour :

  • I try to find paper and fill the printer
  • I try printing on another printer
  • I use draft paper to print

It may sound caricatural, but we identify someone’s active by all the means put in place we he faces an issue. I’m being active when I face an issue preventing me from reaching my objectives, and  put all the possible means in place to reach my objectives.

Examples of « passive » attitude on a project:

  • « Is this working task done? Well I’ve sent an email but they haven’t responded yet … ! »
  • « I failed in my objective but I have an email proof of the person responsible (according to me) of my failure »
  • « I’ve sent them 3 emails and still haven’t received an answer! »
  • « There is no more network … I can’t work anymore !
  • « I’m stuck, Mr X has to deal with that but I don’t know when it will be done…I’m not his Manager! »
  • « I’m stuck »

Examples of « active » attitude on a project:

  • Face to face interactions
  • Identify the person in the organization who can help me to fix my problem
  • Get the information
  • Asking for help
  • « Who is in charge for this matter ? »

Give and Take Feedback

Best gift ever !

Best gift ever !

Some Agile methods like Scrum already included feedback mechanisms in daily meetings and sprint reviews.

It is important for team members to give feedback and accept feedback in return. This promotes team cohesion and can also avoid potential problems. It will be difficult to build an efficient team if you are acting in this way: « Whatever… I am who I am, I won’t change. « 

When given in a benevolent way and in a competent way, Feedback can really be a true gift to give or receive. There are several techniques for giving and receiving feedback, if you’re interested I can write a post about it.

When 2 people argue, once we remove all the emotional judgements and hypothesis on each other’s understanding, we can be surprised on how slight the problem was.

Example:

  • M: « You don’t have any respect for other ! »

(In NLP we name that « ming reading ». Facing a fact e.g an interruption we try to deduct what the person is which obviously a wrong statement. If we do some « mind reading » the goal is to avoid them. If we have some, we should try to discuss with the other person to try to (in)validate our believes).

  • S: « OK we can discuss this we you are available and calm »

(…)

  • S: Ok I’m listening
  • M: Look, you keep interrupting me all the time ! Every 5 minute you ask me questions.

Solution in this case could be that S write down all his questions and then arrange a 1-hour meeting to discuss it with M.

To be project oriented

A efficient orientation

When I give my opinion, or take decisions in a project:

  • Am I taking decisions according to my own interest?

Example : I will use this technical framework, because I’d love to try it !

  • Am I taking decisions according to the project interest ? the choices that will truly satisfy my customer and give sense to the project.

Example of « project oriented » behaviour: choose a technical framework by taking into account its potential but also the knowledge of this framework by the team. Do we have enough time for each team member to be trained on this framework?

Being « project oriented » does not mean to be discreet, without an opinion and to forget his personal goals, it is a behaviour, in our daily choices, to consider the interest of the team and the project.

Agree – Disagree

…or not ?

There are different ways to express disagreement:

By opposite disagreement: someone who keeps saying the opposite idea of yours

By behaviour: act or sigh loudly, move back its chair 1m from the table

By ‘Yes, but’: when an idea is brought to the conversation, one would keep answering “Yes…but !”

By changing topics: one topic is brought to the meeting but someone keeps changing the conversation. Example : During a meeting about specifications => “Well, the way it is put in production is wrong’

By commenting: You want to express your opinion and someone would answer: “Do you have many silly ideas like this?”or “Pffff… what a nonsense!”

There are 2 important things regarding someone’s expressing disagreement:

First, there is always a message behind this behaviour. It is important for the coach or the leader to understand it. During a training, one participant had disagreement behaviour. I wondered why and I realized I started the training in French after asking the audience. However, the training was first announced in English and this participant barely spoke French. That’s why he had disagreement behaviour ! When I switched to English, you could see his behaviour changing.

Secondly, when one in a group disagrees, it can cost a lot of energy to everyone. Imagine a 2-hour meeting with 10 people. If one would constantly change the topic of the meeting, you can lose 20 working hours. Even though the topics covered were important, at the end, you were not able to reach your initial objectives. In this case, you need to manage the disagreement to keep the agenda and the meeting under control.

What for ?

What for ?

Why will these tools could be useful ?

They can be used during interviews to select your team members.

Indeed, if you only have team members with disagreement and passive behaviours, I wish you luck to manage your team 😉

You can also explain these tools to your team and define your expectations to them.

Having a team who knows about being active, give/receive feedback, project-oriented and being careful to their agreement behaviours is an asset to the success of your project.

However, these tools should not be used to diagnose the team : “Hey you, you cannot join the team, you are being too passive”. This wouldn’t help.

In my opinion, the most interesting use of these tools is to explain and share them as a team

Have fun !

Bruno

PS: These tools come from NLP (Neuro-linguistic programming) (meta-programs)


Agile et PNL: les yeux, les oreilles et les sensations … et le triangle dramatique

[English version below « Agile and NLP: eyes, ears, feelings and the dramatical triangle »]

Le sauveur (film: « Oui mais… »)

Voici mon retour sur la conférence Agile France 2010. Cette conférence a eu lieu en juin 2010.

C’est l’occasion aussi de publier la présentation sur mon blog (voir plus bas).

Cette Keynote a été filmée et le film devrait être publié sur le site d’Agile France.

Mon feedback:

J’ai aimé

  • L’endroit de la conférence, propice à l’échange
  • L’équipe technique très pro qui m’a bien aidé pour la première session
  • Les différentes présentations, particulièrement celles d’Alexandre Boutin, Pascal Van Cauwenberghe et de Guillaume Duquesnay
  • Les différentes personnes que j’ai pu rencontrer entre les sessions
  • Les débats

J’aurais aimé

  • Avoir les présentations de la conférence online sur le site d’Agile France
  • Voir les différentes sessions qui ont été filmées

Voici les slides du Keynote donné la première journée:

Le monde change. C’est la réflexion que je me suis fait après ma participation à Agile France. Quel bonheur de se retrouver avec autant de personnes qui partagent mes interrogations. Mettre du sens au sein des projets, des entreprises. Répondre à la question du « Pourquoi » je fais ce projet ou ce métier.

Quel plaisir lors des sessions interactives de rencontrer autant de personnes actives et curieuses de choses nouvelles. De discuter entre deux sessions avec des gens et se dire « tiens ils sont comme moi ». De rencontrer autant de personnes qui veulent partager et donner envie. De rencontrer des gens qui n’ont pas peur de sortir des sentiers battus et de proposer des approches audacieuses (et efficaces) à base de choses délirantes comme « un post-it », « un dessin » ou un « jeu de société ».

Pour tout cela, merci aux organisateurs et aux participants.

Oups…pardon…

Pour les Auditifs: veuillez lire ceci à haute voix:  » MERCI A TOUS ! »

Pour les Kinesthésiques cliquez sur ce lien: http://www.youtube.com/watch?v=vr3x_RRJdd4

Pour les Visuels:

Bruno.

Agile and NLP: eyes, ears, feelings and the dramatical triangle

The Persecutor (from french movie: « Oui mais… »)

This post is my feedback on the Agile France conference . This conference took place in June 2010 in Paris.

It is also the opportunity to publish the presentation slides.

This keynote has been filmed and the movie should be published on The Agile France website.

My feedback

I have liked

  • The place, nice for exchange and chats
  • The technical team who helped me for my keynote
  • The different presentations especially those from Alexandre Boutin, Pascal Van Cauwenberghe and Guillaume Duquesnay
  • Different people I’ve met between the sessions
  • Debate

I would have liked

  • To have the slides from the different presentations
  • See the filmed presentation

Slides of the Keynote (1st day):

After this conference I was thinking, « The world is changing ». I was so glad to meet so many people who shared the same values and the same interest. I’ve met many people with the same concerns than I have myself. Put some sense in the company, in the project. Answer to the question « Why » am I doing this ?

It was really fun during iteractive sessions to meet so many constructive, active and « curious of discovering new things » persons. It was nice chatting between 2 sessions and to have AHA moments like… he is like me ?!  It was great to meet so many people willing to share. To meet people not afraid to try new crazy (but efficient) stuff. With tools like a postit note, a game or a drawing.

For this thanks a lot to the organizers and people present this day.

Yup…i’m sorry…

For « Auditory » persons: please read this loudly:  » THANKS A LOT ! »

For Kinesthetic people clic this link: http://www.youtube.com/watch?v=vr3x_RRJdd4

For the Visuals:

Bruno.


Agile Games Conferences

Agiles Games

Agile Games are more and more used… What do we mean by Agile Games ?

An Agile Game is a game that you can play with a team. Usually the game has quite simple rules. The interactions between players during the game give you a great learning experience.

It is related to Serious Gaming. It’s quite simple. The Human Being learn very well when he plays. More and more games are used in companies, during trainings, during coaching sessions… to learn and experience.

E.g. The XP Game is a game that you can play with your team to introduce a new way of estimating, doing teamwork and make predictable plans. The fact that you are playing put all the participants in action and allow them to raise some lessons.

There is several Agile Games about various topics such as leadership, team work, how to do a software architecture, how do we « self-organized » us,…

Agile Games are an emergent concept (not so new actually) in which I’m very interested.

In 2011 there will be 2 main conferences about Agile Games

Play4Agile

http://www.play4agile.org/

When ? 18th -> 21st February 2011

Where ? In Germany

Website: http://www.play4agile.org/

Agile Games 2011

http://agilegames2011.com/

When ? April 14th -> 16th 2011

Where ? In Boston (USA)

Website: http://agilegames2011.com/

.

I plan to be there at both conferences ! I really want to go deeper into Agile Games this year !

Cheers 😉

Bruno.


La gestion des risques en mode Agile

[English version below: « Risks management with Agile »]

Ce billet est l’œuvre d’un blogueur invité, Giuliano Abraini.

Bonjour à tous, vous connaissez tous l’adage populaire « un chef de projet qui ne gère pas les risques court de gros…risques… ».  Bon OK, elle est de moi celle-là mais quand même.

En effet en chefs de projets avertis que vous êtes, vous n’ignorez pas l’importance de la gestion des risques liés à votre projet.  Sans quoi, une mauvaise surprise peut vous attendre à n’importe quel moment de la vie de votre projet et mettre en péril la réussite de celui-ci.

Le problème est que « gestion du risque » est souvent associée, dans l’imagination collective, à : réunions longues et fastidieuses, rapports imbuvables, prise de décision absente, etc.  Bref, ça flaire l’usine à gaz à plein nez.

Et c’est là que la lumière apparaît au bout du tunnel et que la « génialitude » d’Agile s’exprime.  Et bien oui, il est tout à fait possible de gérer les risques d’un projet à la façon Agile.

Alors concrètement, c’est très simple.  Tout d’abord, il vous faut le matériel de survie du parfait Scrum Master : des feuilles format xxl, des post-it, des marqueurs de couleurs.  Bref rien de neuf sous le soleil.

Dans un premier temps, tracez un tableau à 2 dimensions identifiant le degré de probabilité qu’un risque se produise (de 1 à 4), ainsi que l’impact de celui-ci (de 1 à 4).  Un risque ayant une très grande probabilité de survenir et mettant en péril votre projet aura une quotation probabilité = 4, impact = 4. (1)

"Les

Dans notre tableau, nous avons identifié (en rose) une zone où les risques devaient être monitorés avec d’avantage de fréquence. (2)

Ensuite, le principe peut être découpé en 3 phases :
–    Identifier les risques
–    Les catégoriser
–    Prendre des actions pour réduire / supprimer / éviter les risques

La première étape consiste à identifier l’ensemble des risques liés au projet et de les catégoriser dans le tableau en fonction de leur probabilité et de leur impact.  Ici, nous avons utilisé des post-it de couleur jaune.  A noter, que nous avons également prévu des post-it de couleur bleue pour les risques sur lesquels nous ne prenons pas d’action (3).  Exemple, si le fait que votre seul et unique développeur tombe balade est identifié comme un risque.  Il vous est impossible de supprimer ou de réduire ce risque et ce même si vous servez un thé chaud à votre développeur tous les matins.

Pour la deuxième étape, vous devez classer dans le tableau l’ensemble des risques identifiés. (4)

La troisième étape consiste à identifier la ou les actions que vous allez prendre.  Dans notre tableau, nous avons utilisé des post-it de couleur verte.  Aussi, il est très utile de catégoriser les actions. (5)

En effet, les actions peuvent agir de différentes façons sur un risque :
–    Réduire : ce sont des actions qui permettent de réduire l’impact si le risque se produit ;
–    Eviter : ce sont des actions qui permettent d’éviter que le risque se produise ;
–    Repli : ce sont des actions qui permettent de limiter la probabilité que le risque se produise
–    Transférer : ce sont des actions qui permettent de transférer le risque vers d’autres départements ou acteurs du projet qui ont le mandat pour influencer l’impact ou la probabilité que le risque se produise.

Le Risk Board terminé

Enfin, il est impératif de prévoir un review régulier de la situation.  Pour cela rien de plus simple, organisez des réunions récurrentes au format daily scrum durant lesquelles les différents intervenants passent en revue les actions prises (+ résultats obtenus).  Ensuite, revoyez la situation actualisée des risques durant laquelle vous pouvez supprimer des risques, en ajouter de nouveaux, changer le niveau d’impact, etc.  Bien sûr, n’oubliez pas d’identifier de nouvelles actions !

Voilà, c’est déjà fini.  A vous de jouer maintenant et restez aware…

Giuliano.

(photo par Manitoba49)

A propos de l’auteur:

Je suis consultant, chef de projet depuis 3 ans et j’ai une expérience dans l’IT de plus de 8 ans.  Plus précisément je suis spécialisé en SCRUM et en PRINCE 2 (certifié Foundation).
Après un master en sciences économiques et financières, je suis tombé un peu hasard dans le monde de l’IT.  Depuis je ne le quitte plus…
Durant mes différentes expériences, j’ai eu l’opportunité de recouvrir différents rôles (Analyste, Product Manager, Chef de projet) et d’être actif dans de nombreux secteurs (banques, finance, secteur public).
Ma motivation principale en tant que chef de projet est de satisfaire le sponsor du projet, et de faire en sorte que l’ensemble de l’équipe projet y trouve sa place.

En dehors de ma vie professionnelle, j’adore voyager et je suis un mordu de sport.
Vous pouvez me contacter via giuliano.abraini@yahoo.fr

Risks management with Agile

This is a guest blog post from Giuliano Abraini…

Hi everyone, you all know the popular saying: “a project manager not managing risks is under big risks…”.  No? Well it’s mine anyway!  But still it does make a lot of sense right?

Anyway, you folks are experienced project managers so you do know how important is to carefully manage all the risks during your project’s cycle.  If not, some bad surprises could eventually occur and lead your project to a dead-end way.

But you’re probably thinking “yes, but “risk management” implies endless meetings, unreadable reports, no decision making,…”.  In a word, it’s usually a large process for no result.

And this is when I come to my point: it is possible to manage risks without all the above constraints thanks to Agile … true story!  And when you see the light at the end of the tunnel, you just realize that Agile is AWESOME (“High five” would say my friend Barney Stinson).

First of all, you need to use your Scrum Master survival kit.  I.E. a large paper board, some post-its, color pens.

To start with, you have to draw a 2 dimensions table.  A first one, identifying the probability that a risk occurs (scale from 1 to 4).  And a second one, assessing the impact on the project when a risk occurs (from 1 to 4).  Like this, a risk with a high probability to occur and with big impacts will get a quote of “probability = 4” and “impact = 4”.(1)

"Les

In our table, we have also identified (in pink) a “zone” where risks should be monitored more carefully. (2)

Then, you need to split “the thing” in 3 phases:

–    Identify risks

–    Put them in categories

–    Take actions to reduce / delete / avoid the risks

The first step consists in identifying all risks (and I really mean all) linked to your project and to put them in the table previously prepared.  Here we just use 1 yellow post-it for each risk and we simply write down the risk description.  Please note on the photo, that we also use blue post-its.  These are used to identify risks for which no actions can be taken (3).  For example, if you have only one analyst programmer in your team, the fact that this person can be sick a not be able to take part to the project for a few days is an identified risk.  But you cannot do anything to reduce this to happen even if you buy a brand new scarf to your analyst programmer.

For the second step, you need to classify all the identified risks in your “risk” table according to the probability and the impact. (4)

The third step consists in identifying all the actions that could be taken for each risk and to write them down on green post-its.  Then, you will also classify each action according to the following categories (5):

–    Mitigate: these are actions that will reduce the impact if the risk happens

–    Avoid : here you will put actions that makes the risk not to occur

–    Contain: there are actions that will lower the probability that a risk occurs

–    Transfer : here you will transfer the risk to other departments or stakeholders that have the needed tools to positively influence the probability or the impact of the identified risk.

Risk Board completed

Last but not least, you now have to set-up regular reviews.  The best is to organize “reviews” in the same mindset as daily scrum meetings where people discuss about the taken actions and the consequent results.

After each review, it is important to re-assess the risks, identify new ones and finally schedule new actions.

That’s all folks.  Enjoy!!!

About Giuliano

I am consultant – Project Manager for 3 years now and I have 8 years of experience in IT.  I am specialized in SCRUM and PRINCE 2 (Foundation certified).

I have a master in Economy & Finance and I went into the IT world by chance.  Since then I am still active in IT. I had experiences as Analyst, Product or Project manager in various activity sectors such as banking, finance, public sector.

As project manager I am focused on satisfying the project sponsor.  I also want to make sure that all team members enjoy taking part to the project.

Outside the IT world, I like travels and all kind of sports.

You can contact me at giuliano.abraini@yahoo.fr


Définir le scope de son projet de manière Agile, créative et visuelle

[English version below: « Project Scoping using Visual Management »]

Découper votre scope projet…mais pas seulement.

C’est toujours face à un problème ou à des contraintes que l’on a l’occasion d’être créatif. Passé bien entendu l’indispensable étape de râler un bon coup, shooter dans la corbeille à papier et maudire le monde entier.

Sur mon projet actuel je suis dans l’étape de définition du Scope. Mes difficultés sont les suivantes: multiplicité des intervenants et de nombreux documents d’inputs. De plus, ni mes documents, ni mes intervenants ne parlent la même langue. J’entends par là que mes stakeholders sont très compétents et connaissent leur métiers mais utilisent les même mots pour désigner des choses différentes. Exemple lorsque l’on parle d’un segment, cela peut être un terme marketing (segmentation client) ou un terme financier (segmentation des actifs financiers).
Vous imaginez donc la difficulté de définir le Scope ! Certains ont-ils déjà vécu pareille situation ? 🙂

Et bien cette problématique m’a permis de mettre au point une méthode de découpe de Scope créative et visuelle. Et vous savez quoi ? Ben j’ai envie de la partager avec vous. Voici les différentes étapes

Étape 0: Rassembler l’input

Multiplicité de documents en input
Une multiplicité de documents en input

De quoi je disposais en input ?
Une liste de Business Requirements « High Level » et d’une série de documents: Project Charter, Budget, Planning, Resources Planning, Milestones qui proposaient déjà une certaine découpe.

Voici la technique utilisée pour découper le scope: coût 4heures/homme

Étape 1: Pré-découpe en produit

Liste des produits
Liste des produits

Au préalable j’avais identifié 10 produits (au sens Prince2) potentiels. Le projet est prévu pour deux ans et une fois ces 10 produits terminés le projet peut être considéré comme terminé. Pour les intitulés des produits j’ai maximisé l’utilisation du vocabulaire existant. J’ai aussi essayé d’orienter le vocabulaire vers le besoin Business (maitrise d’ouvrage) et pas vers la solution IT (maitrise d’oeuvre).

Exemple je préfère parler de segmentation client et pas de « lier contrat X via système Y et faire un export XML vers Z ».

Assurez-vous que les produits sont rédigés dans une langue maitrisée par tous les stakeholders, dans notre cas l’anglais. S’il n’y a pas de langue commune, rédigez en deux langues et faites valider l’exactitude de vos traductions. Dans la mesure du possible n’utilisez qu’une seule langue.

Étape 2: Découpe du scope…au sens littéral

Découpe des produits
Découpe des produits

Imprimez tous les document en grand format, usez et abusez des zooms d’imprimantes et des pages format A3, voire A0.
Au plus c’est lisible au plus vous serez efficace. Prenez tous vos documents d’inputs et découpez chaque ligne, chaque chapitre.

Étape 3: Préparation de l’espace de travail

Trouvez vous un grand espace de travail ou vous ne serez pas dérangé. Ex: Une grande salle de réunion, La cafétéria en dehors des heures de lunch, une réception,… Disposez sur une table tous vos produits

Étape 4: Disposition des différents inputs

Etape 4: disposition des produits et des inputs
Disposition des produits et des inputs

Disposez sur la table tous les découpages provenant de vos documents (budget, projet charter,…)

Étape 5: Début du Workshop

Présentez les différents produits à vos participants, assurez-vous que les noms sont explicites pour chacun.

Etape 5: début du workshop
Début du workshop

Et maintenant action ! Demandez à vos stakeholders quel papier (requirement, milestones,…) ils mettent en dessous de quel produit. L’idée est la suivante. Posez des questions comme « Telle ligne de budget tu la mettrais dans quel produit ? » ou « Cette ligne du capacity planning, elle est liée à quel produit ? ». Au départ il est possible que vos participants soient quelque peu déstabilisés. La technique n’est pas habituelle. N’hésitez pas à prendre le lead et montrer l’exemple dans un premier temps.

Votre objectif est simple: tous les découpages provenant de vos documents d’input, doivent se retrouver sous un produit.
Si ce n’est pas le cas: ça devient du out of scope ou il faut créer un produit supplémentaire. Dans le cas du out of scope, il peut être possible de la rattacher au scope d’un autre projet. Lors de cette étape, des dépendances avec d’autres projets peuvent être identifiées.

Réservez sur votre emplacement de travail un emplacement « Out of Scope » et un emplacement « Dépendances avec autres projets ».

Une fois que tous les stakeholders sont d’accord sur les différentes composantes de chaque produits, vous pouvez passer à l’étape suivante
Attention à ce moment on ne parle pas encore de timing !

Étape 6: Dépendances

Demandez aux participants d’identifier les dépendances entre produits, certains doivent-ils être réalisés avant d’autres ?

Étape 7: Ligne du temps

Triez les bloc produits sur une ligne du temps imaginaire. Placez le produit qui doit être réalisé le premier tout à gauche et le dernier tout à droite

Étape 8: Go live

Si c’est possible définissez pour chaque produit pour quand il doit être terminé (en production). Dans notre cas nous n’avons la possibilité de mettre en production que 4 fois par an. Cette contrainte se prêtait bien à notre exercice. Nous avons donc pu mettre une date de Go Live (un trimestre) pour chaque produit.

Étape 9: Consolidation

Un exemple de produit avec le contenu validé par tous
Un exemple de produit avec le contenu validé par tous

Relisez ensemble ce qui se trouve sur la table et validez avec les participants le contenu. Nom des produits, timing, contenu,…

Étape 10: Un petit sourire

Prenez des photos du travail effectué, ce sera votre compte rendu de réunion.

En fonction de la complexité ou de la maturité de votre projet, Il est possible que vous ayez à refaire plusieurs fois cet exercice

Les produits et leur contenu sont stockés dans des enveloppes en vue d'une éventuelle réutilisation
Les produits et leur contenu sont stockés dans des enveloppes en vue d

Et voilà…

De quoi disposez-vous ? De votre Scope défini ainsi que le partie out of scope. Et…petit cadeau de la maison, si vous avez effectué les étapes 7 et 8 vous disposez d’un planning High Level.

Pour en avoir discuté avec d’autres, cette technique peut également être utilisée pour du Business Modeling, définir une hiérarchie de menus dans une application et pour bien d’autres choses.

Avantages de cette technique:

– On dispose de son Scope rapidement
– On évite de multiples réunions avec échange de compte rendus
– Des documents qui doivent être mis à jour plusieurs fois
– Une manière d’être certain que chacun a bien compris la même chose
– Un coût en jour/homme très bas

Essayez cette technique et donnez moi du feedback !

Bye

Bruno

Project Scoping using Visual Management

How to quickly have a first draft of your project Scope ?
How to quickly have a first draft of your project Scope ?

You’re facing a problem ? Having some (many) constraints ? Good for you ! You have the opportunity to be creative. Before that there is for sure a mandatory step. Grumble a little bit, Curse the whole world asking him ‘Why me” and “Shoot twice in the garbage” .:-) Ok now, calm down and let’s go further with this problem.

On my actual project I’m in the “Scope Definition” step. My difficulties are: I have a lot of stakeholders and a lot of input documents. And neither my documents, neither my stakeholders speak the same “language”. I mean vocabulary is always different.

E.g for someone a segment is a marketing term to divide the market, for another one segment is a categorization of financial asset. So if i read in a document Segmentation which one is it ?

You can easily imagine how difficult is it to scope the project in those conditions. Sound familiar for some of you guys ?

To fix that I’ve set up a simple technique that I would like to share with you.

So you will find below how I was able to fix that for a cost of 0,5 man day

Step#0 : Gather input

Multiple input documents
Multiple input documents

My inputs are a lot of docs: High level Business Requirements, Project Charter, Budget, Planning, Resources Planning, Milestones,…

Step#1: Cutting scope into products

List of products
List of products

I had already identified 10 potentials products (Prince2 based). Project is planned for two years. Once those 10 products are done, le project is considered as finished. For naming the product, I’ve tried tu use as much as possible existing vocabulary.

I’ve also tried to use a Business vocabulary (client oriented) rather than a too technical vocabulary. E.g. I prefer to speak of “client segmentation” rather than link contract X in system Y to export it in XML to Z.

Assure you that you will write in a language that everybody can understand ! English in our case.

Step#2: Cutting the scope… literally

Cut the products
Cut the products

Print all your input documents, use print zoom and A3, A0 big format. The more readiness you have more efficiency you will have. Take all your inputs documents and cut each line, chapters

Step#3: set-up workspace

Find a large room where you will be quiet, e.g A large meeting room, Cafeteria outside lunch hours, a reception desk,… Put all products on the table.

Step#4: Place products and input

Place all inputs on the table
Place all inputs on the table

Place all “pieces of products” on the table.

Step#5: Workshop

Start the Workshop
Start the Workshop

Introduce all different products to your stakeholders, assure you that all product names are understood the same way by everyone.

And now, action ! Ask your stakeholders to place pieces of document (requirement, minestrones,…) beside products. If your participants feel a bit lost at the beginning, it’s up to you to support them. You can take the lead and after some times step-back.

Your objective is quiet simple: each piece of document must me linked to one product. If not, then this is out of scope or you need to create an additional product. When you are working the « out of scope » part, it is possible that you will identify interdependencies with others existing projects.

On your workplace, leave a place for interdependencies and out-of-scope.

Once every stakeholder agree on each product, you can move forward to the next step.

At this time we don’t discuss timing yet

Step#6: Dependencies

Ask people to identify dependencies between products. Should a product be ready before another one ?

Step#7: Timeline

Put all your products on a virtual timeline, 1st product to be done on the left and the last one on the right.

Etape#8: Go live

If this is already possible, define for each product a « Go Live » date. In our case we had 4 possible go live date a year. So we specified each product a end date.

Etape#9: Consolidation

Example of validated product and his content
Example of validated product and his content

Read together what you have defined, make sure everyone agree. Product naming, timing, content of product,…

Step 10#: Say “cheeeese”

Take pictures, it will be your minutes of meeting… or content for a blog post as well 🙂

Depending of the maturity and complexity of your project, you will have to do this exercise several times.

Keep each product and his content in an envelope, for using them later
Keep each product and his content in an envelope, for using them later

And…this is it !

What do we have now ? A defined Scope with his « out of scope » part. And, gift from the house, if you achieved step 7 and 8, youe have a High Level Planning.

I’ve discuss this with several people and you can use this technique also for a lot of stuff: Business Modeling, define a menu hierarchy,…

Benefits of this technique:

– Now you have your scope

– You avoid multiple meetings with minutes

– Update a lot of documents

– A way of working to ensure that everyone has understood the same thing

– A very low cost (man/days)

Try this and give me some feedback !

Bye

Bruno


Ma première conférence

Au menu de cette journée, une rencontre avec l'équipe IceScrum
Au menu de cette journée, une rencontre avec l’équipe IceScrum

Le 19 mars j’étais à Toulouse pour la conférence du SigmaT13. Le but de la SigmaT est de développer une communauté d’agilistes -personnes qui s’intéressent aux méthodes agiles-, à Toulouse et dans le Sud-Ouest, par des actions diverses de promotion, de rencontre et de communication.

Cette conférence a été une très belle expérience que je vais vous narrer dans ce billet.

14h30 arrivé sur le campus de l’université Paul Sabatier, ma mission trouver Claude « La force tranquille » Aubry. Claude étant ponctuel cela n’a pas été trop dur. Nous commençons par faire un tour des locaux et Claude m’invite à rencontrer l’équipe IceScrum.

IceScrum

IceScrum est une application J2EE pour utiliser Scrum tout en gardant l’esprit « espace collaboratif ». Il offre aussi un tableau virtuel, avec des post-its pour le  sprint backlog, product backlog et autre.

Je participe à leur Daily Meeting, les nouvelles sont bonnes. A titre personnel je trouve ça une belle opportunité pour des étudiants de faire évoluer un outil open-source en guise de travail d’étude.

Ensuite nous discutons tranquillement en attendant l’arrive de Laurent Carbonnaux qui s’occupe également de l’association.

La soirée

16H (+ le quart d’heure dit « Toulousain » 😉 démarrage de la soirée.

La première présentation est intitulée « Refactorer son Project Manager » par Hervé Desaunois de Valtech. Intéressant on voit qu’il connaît son sujet et les valeurs qu’il véhicule dans sa présentation ma parlent bien.

Ensuite c’est au tour de David Gayerie de nous parler de FitNesse, un outil d’automatisation des tests dit « d’acceptation ». Un bel outil que j’ai bien envie de tester. En plus David était accompagné d’un de ses clients.

Ensuite à mon tour, ma présentation s’intitulait Réalisation de deux portails web à l’aide de méthodes Agile. Cette présentation m’a permis de donner un retour sur un projet de 18 mois pour l’administration Belge. Ce projet ayant été réalisé à l’aide de SCRUM. La présentation parle de différents aspects:

  • Comment sommes-nous arrivés à travailler en mode Scrum chez un client qui ne travaillait pas, à l’origine, avec les méthodes Agile.
  • Comment amener les méthodes Agile chez le client ?
  • Retour sur les aspects Agile et Scrum du projet

La présentation

J’ai aimé le côté organisé, on avait 3 projecteurs en cas de problème et un time tracking efficace. L’interaction avec les gens était très bien organisée. Nous avions une séance de question réponses de 15 minutes, plus l’apéro juste après ce qui nous a permis d’échanger pas mal. Je dois dire que j’ai aimé rencontrer autant de monde.

J’ai été surpris positivement par le côté « communauté ». Quel plaisir de rencontrer autant de gens qui « y croient » et appliquent concrètement les méthodes Agile. Mon seul regret est de ne pas avoir pu accompagner les membres de l’association au restaurant par après. Mais ce sera pour la prochaine fois ?

Si je devais résumer ce séminaire ce serait pas ces mots…

« MERCI TOULOUSE 🙂 »

Les slides de la présentation sont disponibles ci-dessous

Bruno.

My first conference

texte
This conference was for me the opportunity to meet the IceScrum team

March 19, I was in Toulouse France for the Agile SigmaT13 conference. Goal of SigmaT is to develop an Agile community in the « South-West » part of France. To do so, they make different actions, promotion meetings and conferences.

This conference was indeed a very nice experience for me.

14.30 I arrived at the university of Toulouse. My mission find my contact Claude Aubry. Claude was there, show me the place and invite me to meet the IceScrum Team.

IceScrum

IceScrum is an J2EE application for using Scrum while keeping the spirit of a collaborative workspace. It also offers virtual boards with post-its for sprint backlog, product backlog and others.

I was there for their Daily Meeting, Good news Relase2 Sprint#15 is on his way. I personally think that this is a great opportunity for IT student to take part in an open-source project.

Then we chat a little bit waiting Laurent Carbonnaux who is also member of the association.

The evening

16H The conference begin…

First keynote is named « Refactoring your Project Manager » by Hervé Desaunois. Interesting, he knows what is he talking about, and share some nice values with me.

Then the speaker is David Gayerie. He speak about FitNesse, a tool to automatize acceptance testing. Nice open source tool !

Then it’s my turn, my presentation was Making 2 Web portals using Agile methods. This presentation was the opportunity for me to give feedback and lessons learned on a project. This project was for the Belgian administration and took 18 months. This project was made using SCRUM. Presentation is about 3 different aspects:

  • How was be able to work in a Scrum mode. In a « not » Agile company.
  • How to bring your client to use Agile ?
  • Lessons learned using Agile and Scrum

I liked the organization. We had 3 beamers and an efficient time tracker. Interaction with people was very well organized. We had an Q&A session and the possibility to join a drink after the conference.

I was positively surprised by by the « community » aspect of the conference. Those guys truly believe in Agile principles and used them at the client’s place. I was so sorry not joining them after at the restaurant…maybe next time ?

« THANK YOU TOULOUSE 🙂 »

Slides


Bruno.