C’est votre 10eme itération, vous êtes en plein stand-up et Roger le nouveau ne sait toujours pas quel post-its prendre. Il faut dire que Roger n’arrête pas de vous demander quelle tâche de développement il doit prendre aujourd’hui.

Vous êtes tech –lead sur un nouveau projet et vous recherchez un nouveau framework de test en Javascript.

Vous êtes RH, et vous êtes en train de rédiger une fiche de poste pour ce curieux métier qu’est le « product owner ».

Vous êtes responsables produit d’une grande assurance et on vous demande de rédiger un backlog.

Vous avez envie d’en parler, venez le 27 Septembre à l’Apéro Agile !

Autour d’un verre, nous discuterons de l’état de l’Agile, de carrière, de pratiques, de techniques et de vos réussites.
Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

Pour venir à l’apéro agile, inscription ici.

Dans ce billet, nous nous basons sur un expérience vécue de mise en place d’une méthodologie (Scrum) sur un projet de développement, pour analyser un piège qui, selon nous, guette toute organisation désireuse de s’améliorer via l’adoption d’une méthodologie : le piège de l’Artefact.

(Lire la suite…)

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

(Lire la suite…)

(Charles est un coach agile. Daniel est un développeur dans un projet agile. Un vendredi à 18h30, l’heure de la bière).

Charles: Alors comment va votre projet ?
Daniel: Hmm. Y a des hauts et des bas. Jusqu’ici on avait une courbe de vélocité en progrès, et puis là, soudain, le trou d’air. Le client nous refuse 4 scénarios sur les 7 prévus dans l’itération… C’est logique d’ailleurs, ses tests de recette ne passent pas.
Charles: Qu’est-ce qui a changé ?
Daniel: Difficile à dire. On n’a pas de problème majeur, plutôt des tas de petits soucis qui s’accumulent depuis des semaines. Du coup le manager nous revoit lundi pour mieux comprendre ce qui se passe. Il nous a dit “votre courbe de vélocité, je n’y crois pas”.
Charles: Il a raison.
Daniel: Bah voilà. Merci pour l’encouragement. A la tienne.
(Lire la suite…)

« Et après avoir enregistré la livraison, on voit que le stock du produit… n’est pas mis à jour… »

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l’application… l’ »effet démo » devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres « stacktraces » présentés à l’écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d’un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l’effet démo qui, un peu à la manière du « Plouf« , s’instille sournoisement dans les habitudes d’une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode « Scrum ». Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

(Lire la suite…)

UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

(Lire la suite…)

Afficionados de méthodes agiles, voici venue iDailyScrum : une application mobile spécialement conçue pour vous aider à améliorer vos daily Scrums tout en leur conférant un côté plus fun !

En combinant un chronomètre et l’outil de management préféré du consultant OCTO, j’ai nommé la « Boite à Meuh », iDailyScrum vous rappellera sans ménagement lorsque le temps de parole est dépassé ou lorsqu’une conversation privée vient polluer votre stand-up.

iDailyScrum est disponible gratuitement sur iPhone et WindowsMobile.

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?
(Lire la suite…)

« Scrum sans itérations ? » un concept étrange que d’imaginer une méthode itérative sans itérations … Et pourtant nombre de blogs de l’écosystème agile présentent Kanban, un processus par définition non itératif, comme une évolution intéressante pour les projets Scrum.

L’objectif de cet article est donc d’illustrer comment ces deux approches, d’apparence contradictoires, peuvent se compléter pour le plus grand bonheur de nos utilisateurs ! L’article s’adresse à des lecteurs déjà sensibilisés à Scrum, si vous ne connaissez pas ce kit méthodologique, Wikipedia est un bon point d’entrée.

Quelques illustrations de cet article ont été récupérées de l’excellent blog de Henrik Kniberg.

(Lire la suite…)