Archives novembre 2009

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

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

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

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

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

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

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

Documentation

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

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

La mise en production

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

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

Capitaliser sur les tests

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

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

Merci principalement à Bob et Gérard 😉

Bruno.

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

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

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

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

Bob: « On my workstation it works ! »

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

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

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

Documentation

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

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

The Go Live

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

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

Capitalizing on tests

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

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

Bruno.

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

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

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!

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

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

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

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

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

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

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

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

Musique: Red Hot Chili Peppers « Snow »

Scrum Video: Scrum works in the real world!

Here it is !

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

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

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

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

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

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

Music : Red Hot Chili Peppers « Snow »