Je me suis rendu le 21 janvier à Itterswiller en Alsace pour la seconde édition de l’Agile Open France qui vaut vraiment la peine d’y assister et cela pour plusieurs raisons :

D’abord, le cadre et l’endroit choisi pour les 3 jours de l’évènement sont magnifiques : village d’Alsace isolé en plein milieu des vignobles sur la route des vins. Le coup d’œil le matin sur les vignes sous un soleil naissant depuis sa fenêtre de chambre vaut vraiment le coup.

Ensuite et c’est à mon sens le plus important, la qualité des personnes présentes issues de différents univers professionnel avec des expériences variées de mise en œuvre concrète de l’Agilité, etc. mais avec UN point commun, la volonté de partager la connaissance acquise et le fait de pouvoir bénéficier de points de vue des différents acteurs de l’Open Space sur les interrogations et problématiques rencontrées au quotidien.

Nous étions au total 23 personnes dont une forte présence de l’entité commerciale Orange Business Services  (6 personnes) et de nos amis belges (3 personnes) qui vont organiser prochainement un Agile Open en Belgique.

Pour ma part, c’est la première fois que je me rends à ce type d’évènement avec comme thème fédérateur l’Agilité et je fus agréablement surpris au fil de la première journée malgré mes craintes du départ – N’avions-nous pas rigolé ensemble au bureau sur le fait que se réunir épisodiquement sur l’Agilité pouvait s’apparenter à l’appartenance à une secte ?

Il est vrai que le jeu de groupe organisé en début d’évènement, pour attendre les derniers retardataires, m’y a fait penser. Tous debout en cercle en train de crier à tour de rôle un dialecte composé de 3 mots barbares en accord avec le geste adéquat pour passage de témoin avec pour objectif d’éliminer un par un les participants dans le cas où le geste ne correspondait pas au mot prononcé.

En étant plus sérieux,  il est vrai qu’un Open Space (ensemble de conférences auto-organisées par les participants) est reconnu comme étant une méthode efficace qui permet de tenir des réunions dynamiques et productives alliant une communication franche et ouverte.

Après un rappel des règles de base par les organisateurs (“les personnes qui sont là sont les bonnes personnes”, ”quand ça commence, c’est que c’est bon moment pour commencer”, “quand c’est fini, c’est fini”, etc.), la planification des sessions a pû débutée. Un premier constat, beaucoup de sujets ont été l’objet de problématiques rencontrées par les participants sur leurs projets au quotidien.

Personnellement, je me suis positionné sur plusieurs sujets portant essentiellement sur des problématiques d’organisation de projets Agile, par exemple :

L’autonomie du Product Owner vis-à-vis des tests d’acceptation. Il s’agissait principalement de tenter de résoudre le problème du non-engagement du Product Owner (pour l’occasion) à fournir (ou à faire faire) des tests d’acceptation avec pour objectif  de soustraire l’équipe de production à ce genre d’activité.

A ce sujet, il a été mis en avant l’utilité de définir des cas de tests et jeux de données associés le plus en amont du processus de développement  de par l’approche développement orienté par les exigences. L’approche Test-Driven Requirement a été explicitée à travers nos quelques retours d’expériences sur le sujet.

Le Business value game de Pascal Van Cauwenberghe . C’est un jeu très sympa et utile qui permet de simuler la réalisation et la mise en production de versions de produit d’un point de vue du Product Owner. C’est le genre de jeu indispensable pour des mises en situation lors de formation Scrum dédié au Product Owner ou équivalent. Pour expliquer rapidement le déroulement de la session, nous avions constitué 2 équipes de Product Owner afin de pouvoir, au final, comparer les stratégies adoptées de priorisation. Il s’agissait de planifier les itérations en fonction du niveau de satisfaction des clients finaux et du retour sur investissement attendu par le développement des user stories. Est-ce le fruit du hasard ? En optant pour des stratégies différentes, nous avons obtenu les mêmes résultats : niveau de satisfaction du client et retour sur investissement identiques pour les 2 équipes.

Les problèmes de maturité et de cohésion des équipes Scrum. Il s’agissait de répondre à une problématique d’un des participants au regard de l’organisation de son projet, du contexte multi-site et de la non stabilité permanente des équipes projet. Pour cela, une analyse causale a été menée avec des premières pistes d’amélioration en guise de plan d’action par les participants qui ont fait valoir leur expérience réciproque.

Autres sujets liés au Product Owner auxquels j’ai participé : Qui doit être Product Owner ? Comment gérer des versions d’une même User Story dans un Product Backlog et les différentes manières de le visualiser.

Pour conclure, un grand bravo aux organisateurs de l’Open Space que sont Bernard Notarianni, Emmanuel Gaillot, Luc Bizeul et  Raphael Pierquin pour leur superbe idée de faire en sorte que des personnes envieuses d’apprendre et d’échanger sur une thématique commune puisse le faire.

C’est vraiment très agréable et enrichissant de pouvoir partager ses expériences projet avec d’autres praticiens Agiles ou en devenir, d’échanger des idées et de participer à des petits forums de discussions en mode communication directe.

Hé oui, même Scrum va en chine, il n’y a pas que la flamme.

L’article présente un retour d’expérience de 5 cas de mise en place de l’agilité (Scrum) dans les entreprises chinoises.

Il est, je dirais normal, d’y voir les mêmes causes d’échec,

• la non application des principes de base par les équipes (Croire que Scrum se réduit aux scrum meeting)
• la non compréhension et donc adhésion du management aux principes Agile

Ça parait bête, mais faire de l’Agilité sans en faire, ne peut que nuire à son image.

Bonne note : 68% des gens se sentent plus productif depuis leur passage à Scrum

Synthèse sur le blog Xebia
Post d’origine sur InfoQ

OCTO Technology organise les 2 et 3 juillet 2008 un séminaire à l’attention “des geeks et des boss” du Système d’Information, sous le nom “Université du SI“.

Dans le cadre de l’alliance Concordiagile, j’aurais le plaisir d’animer une présentation :

Le facilitateur. Un rôle encore méconnu
(more…)

Un excellent post sur la notion de “Done”

Implementing Scrum

Estimation descendante vs Estimation montante
Macro planning vs micro planning (même si ce n’est pas un planning)

Le produit est défini par User Stories, les niveaux « L1 ».
Les User Stories sont estimés par la méthode des Use Case points.
Ces estimations permettent la définition du plan d’itération, roadmap de l’application.

Des User Stories aux fonctions élémentaires, c’est l’estimation descendante.
Les User stories sont décomposés Business Scénarios :
Scénario principal (aux), scénarios alternatifs, scénarios d’exception.
Décomposition jusqu’au niveau fonction élémentaire. Affinage de l’estimation, ré-estimation indépendante à chaque étage. Cette étape peut être assimilée à l’analyse fonctionnelle, et doit s’effectuer de manière itérative aussi, en fonction du plan d’itération.

Pour l’itération à venir, on prépare l’estimation montante :
A partir des fonctions élémentaires, décomposition en tâches de « développement ». J’entends par tâche de développement, toute activité nécessaire à la production jusqu’à terme de la fonctionnalité : code, tests unitaires, revue de code, intégration, tests fonctionnels,…

La grande majorité des développements applicatifs se basant dorénavant sur un ou plusieurs frameworks, il est facile d’établir une sorte de check-list des tâches. Pour chaque fonction élémentaire, on peut choisir les tâches applicables issues de cette check-list.

A partir de là, les niveaux « L2 » sont définis, leur estimation est effectuée lors du planning game par l’équipe. C’est l’estimation montante : La somme des estimations des tâches prises en compte pour l’itération est à confronter avec la vélocité. Cela peut avoir un impact sur le plan d’itération du fait que l’estimation montante n’est pas nécessairement égale (voir jamais) à l’estimation descendante.

Pendant le sprint (l’itération), le reste à faire est mise à jour, ainsi que le consommé.
En fin d’itération, il est important de reconsidérer les trois valeurs :

• Plan estimé : estimation macroscopique, estimation descendante
• Task estimé : estimation unitaires des tâches de l’itération, estimation montante
• Effort réel : Temps réellement passé à produire les tâches

A partir de ces informations on peut évaluer l’impact sur le plan d’itération, la vie du produit.

La décomposition précise des User Stories en scénarios, puis en fonctions élémentaires, et enfin en tâches, permet à tout intervenant sur le projet

• d’identifier,
• de comprendre,
• d’adhérer

au contenu fonctionnel du produit.

Cela permet dans une certaine mesure de s’affranchir d’une documentation de spécification détaillée proche du code qui alourdi le process.
L’autre mérite est de traiter la traçabilité sans s’en rendre compte, c’est le cas de la combinaison d’utilisation des outils Rally et Eclipse Mylin et SVN (ou CVS).

Je viens de participer à un séminaire organisé par le CNES sur le thème :
“Impact et retours du Web 2.0 en entreprise”.
http://cct.cnes.fr/cct05/public/sommaire.htm

J’ai pour ma part présenté l’apport du Web 2.0 dans le contexte de nos projets Agiles.

L’apport fonctionnel dans un premier temps: Communautaire, participatif et créatif.
Puis l’apport des technologies Web2.0 (type Ajax, Flex, …), apportant une souplesse ergonomique fort pratique, et changeant nos vieux sites Web en un framework collaboratif grâce à l’intégration de différents outils : Confluence, Rally, Trac, Eclipse (Mylin), Continuum, …

Il est intéressant de voir que le Web 2.0, tout comme l’Agilité, fait encore peur en entreprise.
Est-ce la peur de la perte de contrôle pour certains au regard de la prise de responsabilité par les autres?
A suivre…

Number one problem I see with projects trying to implement Scrum is the lack of a Product Backlog.

This is strange because it’s one of the first things you have to do to start a project. I’s also one of the first thing you explain in Scrum : ” You’re going to list features in a Product Backlog and these features will be developped and tested by small increments. ”

How can the Backlog disapear so quickly ? Well it depends on the project. What is sure is that a lack of a Backlog make one thing visible and one thing invisible :

• It becomes visible that the Product Owner didn’t understand his role and job.
• It becomes invisible when the projet is to end because no Product Backlog means no Product Burn Down.

During the Scrum trainings I give at Valtech Training, I often get asked how the bugs should be estimated. Sometimes, the question is about various architecture tasks or GUI updates.

First, it should be clear that all these are technical debts. Yes, they are very common. Yes, it might be impossible to completely get rid of them. But still, they are evidence that the work done in previous iterations was less than optimal. It is therefore appropriate to address them during the retrospectives. Ask the usual questions: “we received 20 bugs during the last iteration. What can we do to reduce that number in the future?”

(more…)