‘Walking the board’ : l’autre standup meeting

« Standups keep everyone busy. Walking the board keeps everyone focused on the most important things. » Bret Pettichord.

Le format de standup classique ‘personne par personne’ est utilisé par la majorité des équipes agiles. Mais il existe un autre format appelé ‘walking the board’, ‘ticket based’, ou encore ‘story by story’. (Lire la suite…)

2 pratiques de coaching pour aider votre équipe agile à démarrer

A Agile France, Jean-François Hélie et moi-même avons présenté plusieurs pratiques issues du coaching d’équipe que nous transmettons maintenant aux équipes agiles. Bien que certaines soient réservées à des coachs aguerris, deux sortent du lot car elles sont applicables facilement par toute équipe : les rôles délégués, et le debriefing.

(Lire la suite…)

Mon projet est-il Agile ?

Que la réponse soit « Bien-sûr ! »  ou « Honnêtement, je n’en sais rien. », se la poser est un excellent exercice !

Une équipe qui a choisi l’Agile a toujours la possibilité d’apprendre et de s’améliorer quel que soit son niveau de maturité. Comprendre comment un bug a pu perdurer jusqu’à la démonstration client, réussir ses rétrospectives d’itération et en mesurer le bénéfice,… Les sujets peuvent être nombreux et leur résolution d’autant plus satisfaisante !

En cherchant à améliorer certains rituels agiles sur des projets de delivery mobile, nous sommes parvenus à compiler toutes les pratiques et outils indispensables à nos projets Scrum. Nous en avons fait un document de mesure et de suivi sur nos missions que nous allons partager ici : notre checklist d’un projet agile.

(Lire la suite…)

Formation TDD le 17 et 18 Septembre

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

Faciliter l’adoption de l’Agile grâce au «Shu Ha Ri»

Lors de mes deux dernières missions, j’ai participé à l’accompagnement d’une équipe projet pour l’adoption de la méthode Agile. Ce qui m’a frappé dans ces missions c’est que bien que les deux missions soient très semblables (même objectif, même équipe OCTO, même caractéristiques de l’équipe côté client) nous avons pu améliorer significativement le passage de compétence à notre client grâce à l’adoption de la méthode « ShuHa Ri ».

Cet article aura comme objectif d’expliquer le « Shu Ha Ri », d’exposer comment nous l’avons adopté et les bénéfices que nous avons pu en tirer.

(Lire la suite…)

Apéro Agile chez OCTO Technology

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.

L’artefact ne fait pas le moine

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

Animer une rétrospective projet

Le but d’une rétrospective projet est de prendre le temps de revoir quels ont été les moments importants du projet, les résultats qui ont été accomplis pour en dégager des observations, des leçons apprises et des bonnes pratiques pour les autres projets. Cet article fait suite à l’article animer une rétrospective d’itération. Couramment, la rétrospective projet se déroule en deux étapes, la première qui permet la construction de la timeline projet, la deuxième qui en permet l’exploitation. La durée d’une rétrospective projet est variable, de 3 jours à 1/2 journée, moins de 3 heures est irréaliste et inutile. Je constate que les équipes passent couramment 1/2 journée ou 1 journée.

(Lire la suite…)

Animer des rétrospectives d’itération

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

Perplexité, complexité, vélocité

(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…)