Bref, comme lors de toutes les formations, les participants prennent des notes sur leur cahier … et quelle a été ma surprise de découvrir ce qu’avait fait Sophie sur son cahier (Cf. photo ci-dessous). C’est encore mieux qu’un MindMap car beaucoup plus percutant !

Bien sur, il faut avoir les compétences graphiques nécessaires … ce qui est la spécialité de Sophie qui est graphiste dans une société sur Annecy … enfin quoiqu’il en soit j’adore … et cela m’a même donné des idées pour Agile Grenoble 2012 … chut, secret … à suivre …

Photo Sophie Mollard (tous droits réservés)

Voici l’offre telle que je l’ai reçu … et surement disponible sur le web si vous cherchez un peu

J’ai besoin rapidement d’un ingénieur en informatique, pour le développement d’utilitaires softwares, dans le cadre de notre flot d’implémentation. Quelqu’un qui ait une bonne aptitude a résoudre des problèmes logico-mathématiques. Au moins quelques années d’expérience dans le développement CAD et les outils C/C++/Tcl/shell sont souhaitables. Une expérience dans les méthodes de développement agile (extreme programming ou scrum) seraient aussi très intéressantes pour participer a leur mise en place. Cet ingénieur rejoindrait la petite équipe que je dirige ou les développeurs ont un ou plusieurs projets sous leur responsabilité tout en ayant une responsabilité partagée sur le processus et l’infrastructure software. Cet équipe travaille en relation très étroite avec les utilisateurs, qui sont partie intégrante de notre processus de développement.

« Je suis Product Owner d’un produit réalisé en mode Agile depuis plus d’un an, est-ce que vous pensez que j’ai besoin d’une formation de Product Owner Agile ? »

La question est intéressante puisque le principe de l’agilité est un peu « d’apprendre en marchant » et donc il est tout à fait raisonnable de se poser la question de l’intérêt de se suivre une formation pour se faire expliquer le travail que l’on pratique au quotidien

Comme la réponse n’est pas binaire et dépend forcément du contexte dans lequel le travail est réalisé, voici ce que j’ai répondu :

-          Si vous utilisez une modèle de valeur métier pour prioriser vos exigences

-          Si vous savez utiliser les techniques de planification agile basée sur la vélocité

-          Si vous savez faire un diagramme d’affinités pour identifier vos utilisateurs

-          Si vous savez décrire une User Story de petite taille qui soit démontrable

-          Si vous savez définir des critères d’acceptation compréhensibles par l’équipe technique

-          Si le Burndown Chart de Release est votre outil de reporting principal (voir unique)

-          Si vous avez compris pourquoi votre présence à la rétrospective est indispensable

-          Si vous avez compris pourquoi votre présence au daily stand up est facultative

Alors vous n’avez aucunement besoin de formation spécifique

Qu’en pensez-vous ?

Cette exercice de relecture avait généré quelques polémiques, car ma vision de Scrum diffère parfois un peu de celle de Claude, et donc des échanges très intéressants et surtout très enrichissants.

Je ne peux que vous inviter à acheter ce livre qui vous donnera beaucoup d’information sur la pratique de Scrum, et cela même si vous le pratiquez déjà.

Sinon, c’est vraiment beau un livre et cela me donne une sérieuse envie de tenter l’aventure moi-même … il ne me reste plus qu’à trouver le temps … car j’ai déjà le titre et le thème

Ken nous a présenté le concept du SCRUM.ORG qui est maintenant le seul dépositaire de la méthode Scrum et qui propose à des sociétés d’utiliser les matériels mis à disposition sous contrat de « licensing » … et c’est sur cette base que la ScrumAlliance va fonctionner.

Il a également présenté le nouveau concept de « Certification Scrum Developer », qui consiste sur 5 jours à former à Scrum et aux pratiques d’ingénierie issues de XP. La certification est basée sur un questionnaire relativement difficile et n’est donc pas automatique à ce jour (seulement 73% des participants l’ont obtenues). C’est un peu mieux que ce qui est proposé par la ScrumAlliance … mais cela reste très scolaire !

Autant vous dire que je ne suis pas un fervent supporter de cette approche par certification pour plusieurs raisons :

• Il est nécessaire de bachoter le scrum guide pour connaître les réponses « in the book » … alors que pour moi rien ne remplace l’apprentissage par la pratique et l’expérience qui consiste bien souvent à faire des erreurs pour apprendre. Par exemple, pour obtenir le permis de conduire, il faut avoir son « code », mais la connaissance parfaite et « in the book » des règles du « code » ne garantit pas d’avoir une bonne conduite.
• Le questionnaire ne prend absolument pas en compte l’aspect culturel de chaque pays. Même s’il faut excuser nos amis américains qui ne peuvent pas penser autrement, il est fort dommage que le questionnaire ne soit pas traduit en Français ou dans d’autres langues. Mon expérience personnelle de mise en place de Scrum en Corée est riche de cet enseignement. Hier soir la réponse de Ken à cette question n’est pas terrible puisqu’il a simplement dit hier soir « qu’il comprenait la question, mais que ce point était très bas dans son backlog »
• Il me semble également que la Scrum.org cherche à créé un besoin qui n’était pas demandé par les clients, et bien que je comprenne tout à fait la démarche business (c’est le modèle de beaucoup de sociétés innovantes), je regrette que cela ne soit pas rendu visible (un des grands principes de Scrum) et masqué derrière le message : « Nous sommes là pour aider les organisations, les équipes et les individus ».

Sinon je vous rappelle/informe que la soirée anniversaire du FrenchSUG se déroulera le 30 mars sur Paris et les thèmes proposés sont très intéressants, pensez à le noter dans vos agendas.

Ce matin deuxième session sur l’agilité en Master Miage 2 avec une 30aine d’élèves plutôt assidu entre 8h et 9h30 !

L’agenda du jour était :

• Les Origines de Scrum
• Les rôles de Scrum
• Le fonctionnement général de Scrum
• Les pratiques XP

S’il est relativement facile d’expliquer les concepts de Scrum et la singularité des pratiques XP, je me suis rendu compte que, même si le message était percutant et remettaient en cause certains des principes qui leur sont enseignés, malgré tout certains messages semblaient avoir peu d’impact sur l’auditoire (comme l’établissement de la confiance, la fiabilité des estimations en points …).

Après réflexion, cela me semble tout à fait normal puisque ces étudiants

• Ont l’habitude de croire leurs professeurs, donc autant moi qu’un autre
• Possèdent très peu d’éléments de référence – d’expérience – car ils ne sont pas encore dans la vie active

Leur professeur m’a fait un retour sympathique en me disant que j’étais l’intervenant extérieur qui avait le mieux réussi à les captiver et qu’en général les élèves étaient moins attentifs, alors j’espère que d’ici une 10aine d’années ces étudiants seront les leaders de l’agilité dans leurs entreprises … laissez moi réver

C’est la seule réunion Scrum qui n’est pas exclusivement réservée aux membres de l’équipe et donc il n’est pas rare (voir même souhaitable) d’y voir participer des managers, directs ou indirects, et des membres d’autres équipes présentes sur le site. La présence de personne non directement concernée par le projet a souvent tendance à faire tomber l’équipe dans un piège que j’appelle : « La présentation du produit ».

L’objectif de la démo est de faire le point sur ce qui a été réalisé durant le sprint, mais un interlocuteur externe sera beaucoup plus intéressé par avoir une démonstration de l’ensemble des fonctionnalités du produit plutôt que de voir quelques fonctionnalités nouvelles, quelques corrections de bugs et quelques réalisations techniques (exigences non fonctionnelles).

Souvent l’équipe est fière de voir quelqu’un qui s’intéresse au produit et donc à ce que l’équipe fait, de ce fait, elle ne se fait pas prier pour donner des explications supplémentaires sur des fonctionnalités qui n’ont pas été réalisées durant le sprint et finir par faire une présentation complète du produit … ce qui prend beaucoup de temps.

Le timeboxing de la réunion (généralement 1 heure pour un sprint de 2 semaines) est donc le point le plus difficile à respecter et le piège principal consiste à étendre la durée de la réunion pour donner des informations sur des éléments non réalisés au sprint précédent.

Si ce cas de figure se produit, l’équipe doit être très vigilante et en particulier le Scrum Master – Gardien de la méthode – se doit d’éviter le piège en proposant aux participants d’organiser une réunion spécifique de présentation du produit … mais plus tard.

Je ne parlerais pas dans cet article de la gestion de projet agile (Burndown chart, Dashboard …) mais de la gestion de produit agile et en particulier d’une métrique que je recommande de rendre visible pour connaître ce que l’équipe a fait lors des itérations précédentes.

La plupart des produits sont à la fois en phase de maintenance (des versions précédentes) et de développement (la version à venir), et il est toujours intéressant de connaître le temps passé par l’équipe dans les 2 activités.

Dans les approches traditionnelles, l’équipe est supposée remplir des feuilles de temps détaillées qui indique les heures passées en maintenance et celles passées en développement. La saisie de ces informations est fastidieuse, mal perçues par l’équipe et de plus, certaines activités comme la validation finale ou le refactoring ont du mal à être classé dans l’une ou l’autre des catégories.

Au bilan les informations recueillies sont erronnées et ne peuvent/doivent être utilisées pour prendre des décisions.

Mais que faire ?

Scrum nous propose une solution toute simple grâce à la mise en place d’estimation des fonctionnalités en « points d’utilisateurs ». Il suffit de catégoriser les « user stories » dans le product backlog et, à l’issue de chaque itération, de rendre visible ce qui a été produit sous forme de ratios.

Les 4 catégories que je préconise sont :

• Fonctionnelle : La User Story apporte une valeur ajoutée directe à l’utilisateur final
• Non Fonctionnelle : La User Story est en général à l’initiative de l’équipe technique et à pour but d’améliorer le processus de développement
• Bug : La correction d’un défaut connu a été planifié lors de l’itération
• Urgence : L’équipe est intervenue pour résoudre un problème (généralement en clientèle ou sur les plateformes de production)

Pour la catégorie « urgence », il est nécessaire de mesurer le temps passé (par exemple lors de chaque Stand Up) sur chacune des urgences. Le ratio des urgences se calcule donc par rapport à la capacité de production initiale de l’équipe et non sur la complexité (pas de « points d’utilisateurs » dans ce cas).

Comment utiliser cette métrique ?

De beaucoup de façons différentes, entre autres :

• Pour le Product Owner à évaluer la quantité réelle de nouvelles fonctionnalités que l’équipe est capable de produire par itération
• Pour l’équipe à argumenter la nécessité d’implémenter des tâches non fonctionnelles (voir même définir un seuil minimum)
• Pour l’équipe complète de mesurer l’efficacité de la mise en place de pratiques d’ingénierie spécifiques (TDD, Pair Programming, IC …) sur la qualité des livrables (moins de bugs, moins d’urgence …)
• Pour le Manager … de lui donner de la visibilité sans effort … même si cette métrique ne lui est pas d’une grande utilité

La mise à disposition de cette information nécessite l’ajout d’une colonne dans  le backlog puis de comptabiliser en fin d’itération les User Story « DONE » dans chaque catégorie … et le résultat est disponible en moins de 5 minutes … plus 1 minute pour l’imprimer et l’afficher.

Simple non ?

L’approche Lean se focalise sur la satisfaction du client final, et en particulier cherche a éliminer les gaspillages de temps et donc à livrer le plus rapidement possible au client final.

Il m’a toujours semblé qu’il n’y avait pas d’antinomie entre les 2 approches … et pourtant !

En Scrum, lorsque les items du Backlog sont déclinés en tâches lors du Sprint Planning Meeting, il est recommandé à l’équipe de choisir en premier les tâches associées aux items de priorités les plus fortes et de respecter ces choix quoi qu’il arrive. Le Product Backlog est renseigné avec différents éléments, des exigences fonctionnelles, des besoins non-fonctionnel et des bugs.

Cette façon de procéder est basée sur quelques principes :

• Répondre aux attentes du Product Owner qui cherche à produire de la valeur ajoutée rapidement
• Éviter les changements de contexte qui consomme beaucoup de temps à l’équipe
• Assurer que des items du Backlog seront réellement terminés et qu’il ne sera pas nécessaire de revenir dessus

De plus,à titre personnel, je note bien souvent un intérêt grandissant au sein de l’équipe lorsque tous les membres travaillent sur le même item, l’écoute et l’entraide sont alors nettement meilleurs.

Pour le Lean, la satisfaction du client et la réduction des coûts passent en premier, et il est donc nécessaire de chercher à réduire les temps moyens d’attente. Lors du XP Days, Marie-Pia nous a présenté un exercice simple pour illustrer ce principe qui consistait à faire passer 15 passagers à la douane avec le moins d’attente possible sachant que les certains passagers passent en 1′, d’autres en 4′ à 7′, et certains entre 15′ et 25′. La solution optimum pour réduire le temps d’attente moyen des passagers consiste à spécialiser un douanier dans les passagers rapides.

En général, la correction des bugs prend moins de temps que la réalisation des exigences fonctionnelles, dans la logique du Lean, il serait plus efficace de gérer un backlog de bugs indépendant et dédier 1 ou 2 membres de l’équipe à leur correction. De plus, cela pemettrait d’éviter de dire aux utilisateurs que leur « petit » bug ne sera corrigé que dans 4 sprints compte tenu des priorités existantes, ce qu’en général il ne comprend pas … à juste titre.

Coté méthode Scrum, la recommandation est de gérer les priorités de tout ce qui est à faire – bugs inclus – à un seul endroit, le Product Backlog, puis de respecter les priorités … et donc de ne pas choisir la solution qui réduit le temps d’attente moyen des clients au minimum.

Etonnant non, comme dirait Mr Cyclopède

Non seulement c’était très bien organisé (cadre agréable, prestations de qualité …) et très intéressant, mais c’était également l’occasion de revoir et discuter avec un grand nombre des agilistes francophones, pour échanger des idées, des impressions, définir des actions à mener en commun … ou régler quelques contentieux si nécessaire

Pour ce qui est des sessions, voici mes impressions en vrac :

• J’adore toujours autant les sessions de Pascal VanCauvenbergue et Portia Tung. Blanche neige et les 7 nains m’a ravi et le Business Value Game m’a fortement intéressé et intrigué (la longue discussion qui a suivi avec Laurent Morisseau qui était co-animateur m’a même permis d’envisager des pistes supplémentaires …)
• Très belle initiative des Alchimistes Agiles, les bien connus François Bachmann et Jacques couvreur qui œuvrent de l’autre coté de la frontière suisse,  qui nous ont expliqués le déroulement d’une rétrospecttive à grand renfort de nains, de rennes, d’elfes et de petits enfants.
• Suite à la présentation du Kaizen Lean de Marie-Pia et l’évaluation de la variabilité d’un système, j’ai pris un vrai coup sur la tête vis à vis de l’efficacité de la gestion des priorités en mode Scrum … mais cela vaut un article complet … disponible dans les prochains jours … le temps que je me remette de mes émotions !
• Petite déception pour la session du Planning Game car je connaissais déjà trop bien le sujet.
• Un peu frustré par la version écourtée de la présentation de Godefroy Beauvallet sur les raisons des échecs des méthodes traditionnelles que j’aurais bien aimé voir en entier … mais timeboxing is timeboxing.
• Bien aimé le « Product Owner qui es tu, où es tu ? » des Guillaumes, et même si l’exercice a été entièrement tronquée du fait du grand nombre de questions posées par les participants.

C’est sur, j’y retourne l’année prochaine, et si les organisateurs le veulent bien, j’animerais même 1 ou 2 sessions.