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

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

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

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

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

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

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

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

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

Voici comment procéder:

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

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

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

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

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

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

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

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

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

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

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

This is it !

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

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

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

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

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

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

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

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

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

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

Bonne visualisations à tous,

Bruno.

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

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

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

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

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

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

But the truth is far more simple…

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

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

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

Here’s how to set up this tool:

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

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

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

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

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

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

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

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

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

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

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

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

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

This is it!

With this tool you can immediately answer questions like:

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

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

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

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

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

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

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

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

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

Cheers,

Bruno.

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