Encore une histoire sur le Management Visuel…

[English version below « Yet another story about Visual Management… »]

Exemple de Management Visuel

Au départ, lorsque j’ai découvert Agile, j’ai été rapidement intrigué par le concept de Management Visuel. Je savais que ça me plaisait beaucoup mais je ne savais pas vraiment pourquoi. En tout cas cela m’attirait fortement. J’ai souvent tendance à particulièrement aimer les techniques qui semblent bizarres ou non-professionnelles au premier coup d’œil mais qui, par après se révèlent particulièrement puissantes. Ceci explique peut-être cela…

Donc, par un beau jour de printemps, je travaillais chez mon client. A l’époque on se préparait à commencer à mettre Agile en place. Mon travail à ce moment là étaient de les aider à (mieux) organiser leurs « releases » (mise en production de projets). Et quel principes avons-nous utilisés pour faire cela ? Le Management visuel bien entendu !

Pendant cette période, mon client m’a demandé d’écrire un article pour la newsletter de l’entreprise. Le sujet devait porter sur Agile. Je voulais écrire à propos du Management visuel. Je me demandais comment faire un article sous forme très visuelle et une équipière m’a suggéré de le faire sous forme de BD / Roman photo.

Et bien…, le résultat est en dessous… Comme vous pouvez-voir, vous pouvez utiliser le Management Visuel même si vous ne faites pas (encore) de méthodes Agile.

Merci à Inge pour l’idée et merci à Alan, Florence, Benoît et Gregory qui ont pris leur rôle d’acteur et d’actrice très au sérieux 😉 (Merci aussi plus largement aux deux équipes L' »A-Team » et les « Kiwinners » d’accepter d’essayer tous ces concepts Agile parfois bien étranges… 🙂

Page 1 sur 3
Page 2 sur 3
Page 3 sur 3

Si vous ne connaissez pas (encore) le Management Visuel, le concept est assez simple. Visualisez vos informations de suivi de projets (ou autres) sur un mur. C’est à dire que pour communiquer, pour documenter, pour discuter vous utilisez systématiquement des supports visuels. Vos supports sont en général une feuille A4, des post-it, et de gros marqueurs de couleurs.
Au premier coup d’oeil, celà paraît étrange. Surtout à notre ère du « tout numérique ». Il n’est pas rare qu’on me dise: « hey je ne vais pas faire de bricolages j’ai passé l’âge ! » Mais je peux vous assurer que cette manière de communiquer est simple et puissante (et peu coûteuse 😉 Cela a souvent pour effet d’améliorer la communication et la collaboration.

Faites cet exercice:

– Organisez une réunion, projetez une fiche excel sur l’écran et demandez aux participants d’ordonner une vingtaine de lignes en fonction de la priorité.

– Organisez une autre réunion, écrivez 20 choses à ordonner sur 20 post-it (une idée par post-it) collez le tour au mur n’importe comment et demandez au groupe d’ordonner les 20 idées par ordre de priorité.

Vous verrez qu’on assiste alors à une dynamique d’équipe complètement différente.

Si vous voulez en savoir plus je vous conseille cet article de Kelly Waters: The Power of a Whiteboard

Comme d’habitude, essayez et faites-vous votre propre opinion,

Bye,

Bruno.

Article traduit en français suite à un harcèlement assez intensif de Claude et Ludovic 🙂

Bruno.

Ps: Billet écrit en écoutant  Delta Spirit – People C’mon

Visual Management

In my early days of Agile I’ve been quickly intrigued by the Visual Management concept. I knew I liked it, but I did not always knew why. I have a tendency to enjoy the techniques that seems silly at first sight and then reveals to be extremely powerful. So maybe that’s why.

So I was working with my client. At the time, they were preparing themselves to implement Agile and at first I helped them to better organize their releases. And what’s the best way to do that ? Visual Management of course.

During this period, my client asked me to write something about Agile for a newsletter. I wanted to avoid a classical article and I wanted to do it about Visual Management. I was wondering how I could do it in a visual way and one team member suggest me to do it like a comic.

Well, the result is below… As you can see you can use Visual Management even if you don’t do Agile…yet 😉

Thanks to Inge for the idea, and thanks to Alan, Florence, Benoît and Gregory for acting so well. (Thanks also to the « A-Team » team and to the « Kiwinners » team for not being scared to try all those strange Agile stuff 😉

Page 1/3
Page 2/3
Page 3/3

If you don’t know Visual Management the concept is quite simple. To communicate, to document, to discuss use a maximum post-it notes, A4 pages, Color markers, and stick the informations on the wall. It seems strange, at first sight, people usually told me « hey I’m not at grade school anymore ». But this way of communicating is simple and powerful. It enforce communication and collaboration.

Just try this:

– Organize a meeting using a beamer that project an excel sheet. Ask people to order 20 Lines from this excel sheet.

– Write the 20 things to order on post-it notes stick them on a wall and ask the participants to order them

You will see the « dynamic » of the group is very different.

If you want to know more:

You can read: The Power of a Whiteboard from Kelly Waters.

The link at the end of the comic (how can I learn more) is here.

Kind regards,

Bruno.


Risks of an Agile Initiative

Good to know…

If you are coach, IT Manager or just an Agile passionate…in my opinion it’s good for you to know that implementing Agile has several risks.

It’s important to know it and to handle it. So here is a (non-exhaustive) list of global risks you should discuss in advance with your Management or your client, before starting being Agile.

A first reminder:

The starting point of an Agile initiative is that we realize that the actual system doesn’t give us satisfaction. We have new expectations and we want to change to a new system.

Risks

An Agile intervention is not always easy. A method like Scrum will put a maximum of visibility on what’s happening in the company. A lot of problems will emerge and it could be very frustrating to face them: Risk 1: Minimize problems, or accuse the method. E.g. « Since we do Agile, we are doing fewer projects than before ! »

Agile can be very seducing, seems fun, easy and productive. It’s simple on paper, but complex in applying. We need everybody to take actions in supporting the Initiative. Agile is a lot of discipline and structure: Risk 2: We didn’t realize how much Agile was binding us. We will only do a “Marketing Agile”.

If we want to go “Agile”, it is because the actual system doesn’t give us satisfaction. We have new expectations and we do agree that we want to change the actual system: Risk 3: We say we want to implement Agile, but actually we are comfortable with the actual system. At least we know how it works. Unconsciously we put Agile labels on previous practices.

Sometimes, Agile seems an IT method. In actual reality, it will involve and “touch” all the company: Risk 4: We need the management to understand what Agile is and to support us in that way. E.g. Sales give us better defined projects, CEO empowers the Product Owner and the Team

“Agile” people often criticize Managers, this is a common BIG mistake. We need managers and we need them “on board”: Risk 5: Thinking that we don’t need Managers to do this

“I know that I should do all these Agile stuff…but the actual system is still healthy. Sometimes we do have crisis but…we’ll manage”. “I know that we don’t work as we should do but that’s our company and we can live with that.”: Risk 6: We don’t have enough HUGE problems that could lead us to change.

Agile will put certain person out of their comfort zone. If a manager doesn’t manage, or a team member is clearly not a “Team player” it will emerge: Risk 7: Maybe the Agile method is not for everybody @ The Company. Sometimes people change functions, quit or in certain (extreme) case are fired

It can be good to know…and I assure you it’s worth it !

Hope it helps,

Bruno.

Picture by The Fayj

Post written listening: Anti-Flag – Postwar Breakout


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.


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.


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


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