Archives 2010

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

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.

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)

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.

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

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

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

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

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

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

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.

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

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

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

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

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

Step#1: Cutting scope into 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

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 “pieces of products” on the table.

Step#5: 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

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.

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

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

SigmaT13 mars 2010 Toulouse from Bruno Sbille

Bruno.

My first conference

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

SigmaT13 mars 2010 Toulouse from Bruno Sbille

Bruno.

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

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

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

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

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

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

Le positif:

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

Ce qui pourrait être amélioré

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

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

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

Merci d’avance,

Bruno.

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

Les slides

Comment la PNL peut vous aider sur votre projet SCRUM from Bruno Sbille

Quelques retours

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

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

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

Par Twitter

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

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

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

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

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

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

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

Positive points

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

What can be improved ?

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

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

If you were there could you send me some feedbacks ?

Thanks in advance,

Bruno.

Below you will find the slides and some feedbacks.

Slides

Comment la PNL peut vous aider sur votre projet SCRUM from Bruno Sbille

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

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

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

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

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

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

Jim Yuill – jimyuill at pobox dot com

Bye bye,

Bruno.

Scrum and Agile are taught at school !

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

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

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

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

If you want to contact Jim here are the coordinates

Jim Yuill – jimyuill at pobox dot com

Cheers

Bruno.

[English version below]

Tout d’abord et une fois n’est pas coutume…je vous présente mes excuses…En effet, je le reconnais j’aurais difficilement trouver un titre plus racoleur…;-) Mais passé votre surprise… qu’est-ce qui se cache derrière cette expression « Scrum 2.0 » ?

Lors d’un projet nous venions de travailler 6 mois en mode Scrum, la mise en production était réalisée et nous avions un mois d’arrêt avant de recommencer 6 autres mois de projet. Nous en avons alors profité pour faire un review / lessons learned de nos 6 mois de travail. Un de points portait sur notre méthode de travail. Allions nous continuer comme ça pour les 6 prochains mois ?

Une chose est rapidement apparue lors de nos discussions, beaucoup de team member trouvaient que la découpe d’une User Story en différentes tâches (+ l’estimation de la tâche en heures) était une étape très lourde. J’ai pris le feedback et ensuite j’ai rencontré chaque team member individuellement pour creuser l’idée. Quels étaient les points positifs et quels étaient les points à améliorer. J’ai ensuite confronté ces idées avec mes contraintes et besoins de Scrum Master et nous sommes arrivés à une méthode différente et qui a fonctionné pendant les six mois qui ont suivi.

Scrum 2.0: La méthode

Tout d’abord quelques pré-requis:

• L’équipe reste la même ou presque. Dans notre cas remplacement d’un team member par un nouveau.
• Durant les 6 sprints précédent, l’équipe est devenu plus autonome qu’au départ.
• La productivité de l’équipe a augmenté au fur et à mesure des sprints.

Voici donc ce que nous avons mis au point. Et comment nous avons fait évoluer notre mode de fonctionnement

1. Plus de découpe en tâche

On ne découpe plus une user story en tâches. Mais on conserve les principes de User Stories et de complexité (fibonnacci). On n’abandonne pas les post it pour autant ! Si lors du sprint planning certaines tâches ou certains points paraissent important, on précise ces points sur des post-it et on les colle sur la User Story correspondante.

2. User Story leader

Pour réaliser une user story, durant le sprint on fonctionne comme suit: La première personne qui démarre la user story est considérée comme le Story Leader de cette user story. Afin que ce soit clair pour tout le monde il colle sa couleur sur la user story et ajoute une étoile sur sa couleur. L’étoile voulant dire, ce team member est le leader pour cette story. Ce principe est expliqué plus en détail sur la figure « Scrum 2.0 en images » ci-dessous.

Le Story Leader a alors la responsabilité de la Story, ce qui recouvre 2 choses principales. Si plusieurs personnes doivent travailler sur la story, c’est le story leader qui en parle aux teams member correspondant et qui en assure le suivi. Deuxièmement, le story leader a le devoir d’information, c’est lui qui parle lors des daily meeting et si le Scrum Master ou le Product Owner a une question sur une story, le story leader connaît la situation et peut immédiatement donner les infos.

Exemple: Le Scrum Master demande à Soulira (Story Leader) « où en est-ton sur la Story 45 ? »

Mauvaise réponse: « heu c’est pas moi qui est dessus, ya Vincent qui code pour le moment faut voir avec lui »

Bonne réponse: « Vincent termine le code ce soir, ensuite je dois repasser sur le design, on prévoit la fin pour demain soir »

3. L’analyste Web

Lors des 6 premiers mois, nous avions hérité d’un cahier des charges pour notre projet. Nous l’avions alors transformé en Product Backlog. Ce cahier des charges comportait un énorme avantage, il avait été validé par l’ensemble des intervenants côté client. Or dans la seconde partie de notre projet nous nous retrouvions face à un problème. Il allait falloir identifier rapidement les user story à réaliser pour le sprint, mais beaucoup de personnes devaient donner leur accord sur le « Scope ». Concrètement, le product owner n’était pas seul, il devait faire valider les priorités à chaque fois par un groupe de travail.

Pour remedier à cette situation nous avons créé un rôle d’Analyste Web. Que doit-il faire ? Il a un mois d’avance sur l’équipe pour aider le product owner à rédiger et prioritiser les user story. Ensuite ces priorités sont présentées au groupe de travail et sont prêtes le mois suivant pour être réalisées par l’équipe.

Exemple: Pendant le mois de janvier, l’analyste travaille avec notre product owner. Fin janvier on fait le sprint planning tous ensemble. On discute alors un set de user stories déjà négociées et discutées avec les client. Le 1er février on peut démarrer le sprint.

En résumé le rôle de l’analyste Web est d’être toujours 1 mois à l’avance par rapport à l’équipe.

Pourquoi faire évoluer les choses ?

Pour nous cette méthode de travail a été un succès. Elle a aussi diminué le risque de frustration de l’équipe par rapport à la découpe en tâche. Elle a aussi plus responsabilisé les teams member et permis à chacun de plus prendre « le lead ».

Je me souviens, au tout début de ce projet, avant même de parler de nouvelle méthode, lors des tout premier sprint, j’étais désespéré. Les choses n’allaient pas aussi vite et aussi bien que je l’aurais aimé. Les principes n’étaient pas correctement appliqués. Je me souviens alors d’une discussion avec un coach Agile qui me disait, « c’est normal, l’équipe va monter en expérience au fur et à mesure des sprint » et effectivement à partir du sprint 3 j’ai commencé à souffler un peu… et une fois 6 sprints passés, nous avons pu en refaire 6 autres avec cette nouvelle méthode.

Cette méthode s’inscrit dans la nécessité de faire évoluer votre équipe et vos méthodes au fur et à mesure du projet. Et comment avons nous pu mettre cela au point ? Simplement en étant à l’écoute les uns des autres. Ne sous-estimez donc pas la puissance du feed-back, des sprint review et des lessons learned !

A bientôt !

Bruno.

Ps: Je ne conseillerais pas à une équipe « toute neuve » de travailler en « Scrum 2.0 » par contre c’est une série de bonnes pistes après un certains nombre de sprints.

English Version

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

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

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

Scrum 2.0: How does it work ?

Before we start, some prerequisites:

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

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

1. No more «  breaking the requirements into tasks« 

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

2. User Story leader

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

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

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

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

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

3. Web Analyst

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

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

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

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

Why should we change our way of working ?

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

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

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

See you soon !

Bruno.

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

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

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

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

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

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

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

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

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

Les outils

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

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

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

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

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

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

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

Voilà, c’est tout pour le moment.

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

Tout feedback est le bienvenu !

Portez-vous bien.

Bruno.

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

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

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

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

The team must be « multi-tasks »

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

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

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

Tools

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

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

Multi-tasking in practice, the Sprint #0

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

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

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

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

That’s all for the moment.

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

Feel free to give feedback.

Take care.

Bruno.

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

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

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

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

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

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

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

Bruno.

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

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

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

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

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

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

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