Retour Agile Tour Marseille

Jeudi 14 octobre 2010 avait lieu, à Marseille, une étape de l'Agile Tour (http://www.agiletour.com/fr/node/964).

Le programme (http://wiki.agiletour.org/files/Marseille/AT2010ProgrammeMarseille.pdf) proposait 3 séries de conférences en parallèle. Toujours difficile de choisir, et un peu frustrant : au final, on aimerait pouvoir en suivre plus ...

J'espère que les diaporamas seront mis en ligne, que je puisse me replonger dans chaque exposé (certains le sont déjà sur http://www.esprit-agile.com/). En attendant, je vous mets ici quelques points forts retenus, et quelques réactions personnelles.

Bonnes et mauvaises pratiques du daily meeting - Céline Stauder

J'ai choisit cette présentation, car en tant que Scrum Master, je considère le Daily (standup) Meeting comme un des points importants de la réussite de Scrum, mais également une étape pas si facile à réussir au quotidien ...

Pour commencer, Céline a rappelé quelques éléments clé pour le daily meeting : pour les pigs (= ceux qui sont impliqués dans le sprint), 15' max et timeboxé, les 3 questions, etc ... J'aime bien le concept Par l'équipe pour l'équipe qui me semble très important.

Ensuite, Céline a donné quelques conseils d'organisation auxquels j'adhère :

• rester debout pour éviter que ça ne dure, 
• mettre des sonneries (à 10 et 15'), 
• couper court aux discussions de problèmes de fond et les reporter à un autre moment de la journée (planifier une réunion si nécessaire), 
• toujours le même lieu et le même horaire, 
• plutôt en début de journée, 
• commencer à l'heure, 
• équipe intégralement présente (s'organiser pour avoir des infos concernant les absents), 
• se mettre en cercle avec le SM à l'extérieur, 
• organiser le tour de parole, 
• personne n'est avec un ordi ou à son poste de travail, 
• se regrouper devant le Scrum Board, 
• mettre en avant les questions 2 et 3, 
• présence du PO souhaitable (mais sans interventions spontanées !), 
• etc ...

J'adhère moins à certaines idées ou pratiques, comme les pénalités pour les retardataires. Mais bon, ça doit dépendre de l'équipe, de son implication et sa motivation, et je n'ai jamais eu ce genre de problème ...

Lors de questions, Céline a évoqué des tâches d'une durée de 1 à 2h max ... Personnellement, par expérience, je m'étais plutôt orienté vers de tâches de quelques heures à 2 jours maxi. Je comprends l'idée de tâches courtes de 2h, permettant d'avoir un rythme motivant, une bonne visualisation de l'avancement, etc ... Par contre, je trouve que le temps nécessaire à un tel découpage est souvent excessif, avec souvent, au final,  un découpage maladroit et inefficace. Mais là encore, c'est probablement lié au contexte métier, à l'équipe, à son rodage des pratiques agiles, etc ...

Concernant les questions, j'aime bien l'idée de changer les libellés en intégrant un lien avec le done (terminé) :

1. Qu'est-ce que tu as terminé hier ?
2. Qu'est-ce que tu vas terminer aujourd'hui ?

Cela me semble très intéressant pour la 1ère question, mais un peu moins pour la seconde. Selon la taille des tâches, une personne peut prévoir d'attaquer une tâche qui ne sera pas finie aujourd'hui, mais c'est intéressant de le savoir et de le mentionner. Donc peut-être rester sur la question classique : Qu'est-ce que tu vas faire aujourd'hui ? ...

Une autre idée que j'ai noté est la suivante. Lorsqu'une tâche est terminée, l'équipier la déplace sur la droite de la colonne "en cours", en la laissant dans cette colonne. Ainsi, on peut déplacer les post-its lors du daily meeting dans la colonne "Fait". Par contre, l'équipe est parfois intéressée pour avoir un workflow plus détaillé pour les tâches, avec notamment des colonnes "à vérifier", "à réceptionner (PO)", etc ... Dans ce cas, il peut être dommage de "ralentir" le cycle de vide des tâches en attendant le daily meeting pour les faire avancer. Encore une fois, ce sont certainement des idées à retenir et à proposer à l'équipe qui choisira le mode qui lui covient le mieux !

Concernant la 3ième question et les points bloquants, on rappelle que rendre les problèmes visibles, au plus tôt, est un des objectifs de Scrum. Céline propose 2 choses intéressantes :

• sur le Scrum Board, avoir une case "problème" pour pouvoir y mettre des post-its à évoquer lors du daily meeting
• par contre, lors du tour de parole, éviter de s'attarder sur ces problèmes : pour cela, se mettre rapidement d'accord sur un lieu, une heure et les personnes à réunir pour en parler

Ensuite, Céline a évoqué les signaux d'alerte montrant un dysfonctionnement du daily meeting et de Scrum en général (indispensable à identifier pour s'améliorer) :

• les participants parlent au Scrum Master
• trop longues discussions sur les problèmes
• intervention du PO ou d'autres personnes non membres de l'équipe
• problèmes de présence de certains participants
• le Scrum Master doit répéter tous les jours les 3 questions
• le Scrum Board n'est pas à jour, voir "abandonné"

Parmi les questions-réponses qui ont suivi, j'ai retenu les remarques sur la durée d'un sprint, préconisée entre 2 et 4 semaines, dans la pratique plutôt 2-3 semaines. C'est à l'équipe de trouver son "bon" rythme. Mais l'important est d'avoir une durée fixe, au moins pendant quelques sprints, pour que l'équipe puisse s'adapter à cette durée et évaluer au mieux si elle lui convient.

En s'élargissant, le débat a amené le point concernant le temps à prévoir ou pas, dans un sprint, pour les imprévus comme le support, la correction de bug, etc ... avec une idée intéressante : prévoir un volume temps dans le sprint, et s'il n'est pas utilisé, en profiter pour de l'auto-formation de l'équipe ! Cool ! A condition de réussir à "vendre" cela pour avoir le "budget" ...

En conclusion, cette session m'a permis de revoir les principes de base, de confirmer mon approche et mes idées sur le daily et, plus largement, l'agilité et Scrum, et de noter quelques idées complémentaires intéressantes.

Comment concilier agilité et projet au fordait ? - Jean-François Jagodzinski

Ce sujet m'intéressait car c'est une question qui revient souvent, sur laquelle je m'interroge régulièrement, et pour laquelle je n'ai pas encore trouvé d'éléments de réponse. Elle rejoint d'ailleurs un peu la question d'un fonctionnement agile en interne, au niveau de l'équipe de développement, par rapport au reste de l'entreprise (mais ça n'est pas du tout le sujet ici).

La présentation de Jean-François est intéressante sur la forme puisqu'il a présenté 2 cas concrets, 2 leçons, où il a essayé de proposer une approche agile, sur des appels d'offre "classiques".

Pour commencer, JF a fait quelques rapides rappels sur l'approche agile. J'ai noté ce comparatif intéressant :

Approche classique	Approche agile
Méthodes	Pratique
Jeu d'échec	Jeu de cartes
Qualité des procédures	Qualité des relations et des échanges
Approche par la théorie	Approche par la pratique

J'ai bien aimé l'analogie avec une comparaison Jeu d'échec / Jeu de carte, pour laquelle il faut imaginer la suite de la partie si un joueur change :

• dans le premier cas, tout est sur l'échiquier, si le joueur a le même niveau, la partie peut continuer
• dans le 2ième cas, le nouveau joueur n'a pas l'historique de ce qui s'est déjà passé, des cartes déjà tombées, il aura du mal à bien reprendre la suite de la partie ....

Cette analogie permet de mettre en évidence la particularité de l'agilité, énormément basée sur les échanges et la pratique.

Une phrase retenue : l'agilité c'est changer son point de vue ! ..... Et comment !  Non seulement pour les membres de l'équipe Scrum (PO, SM, équipiers), mais également pour toute l'entreprise, l'agilité est une révolution culturelle de toute l'entreprise !

A noter qu'ici encore la question de la durée des sprints a été abordée avec une remarque évidente mais intéressante de JF : les itérations courtes permettent une feedback client plus rapide. Mais personnellement, je trouve qu'une durée de 2 semaines est un minimum pour prendre en compte les différents meetings de Scrum, et permettre à l'équipe de bien rentrer dans le sprint.

Pour la leçon 1, il s'agissait de répondre à un appel d'offre pour la mise en ligne d'un site pour les certifications, en relation avec la parution à court terme d'une loi. Les specs et les maquettes écran étaient là, mais globalement, le projet ne s'est pas bien passé, pas mal de retards, d'échecs de livraisons en court de projet, et un dépassement de délai conséquent.

Au final, le bilan est le suivant :

• un client plutôt satisfait malgré les retards (mais la loi est sortie plus tard que prévue ... ;-) ....)
• une équipe en demi-teinte, satisfaite par l'ambiance, mais déçu du résultat pour le travail fourni
• une qualité mauvaise
• et les financiers fournisseurs mécontents (retards, bugs, avenants)

L'approche brute n'est pas la bonne ...

La leçon 2 est dans un contexte différent puisqu'il s'agissait de refaire et considérablement étendre un outils existant (mesures et contrôles techniques d'onduleurs). Il n'y avait donc pas de cahiers des charges, à part le logiciel existant et les expériences utilisateurs sur ce logiciel.

L'idée retenue est intéressante puisqu'il a été proposé au client une période de calibrage, c'est-à-dire de mesure de la vélocité pendant 3 sprints. Un backlog produit a été commencé, avec des estimations en points, pendant la mise en place technique de l'équipe qui a ensuite attaqué ses 3 itérations pendant la fin de la décomposition fonctionnelle.

L'équipe est alors capable d'estimer sa vélocité et donc sa capacité à produire pour les sprints et releases suivants. A ce stade, le client avait la possibilité de tout stopper, en ne payant que la moitié du temps passé, et en partant avec un début de logiciel et les sources.

Cette étape ne semble pas facile, elle comporte l'étude de plusieurs pistes, solutions, moyens d'actions (puisque les prévisions étaient revues à la hausse), mais elle a le mérite de permettre à chacune d'avoir une bonne vision sur la situation, et de meilleures cartes en main pour décider.

Le client a décidé de continuer. Un planning a donc été mis en place, avec des releases planifiées, comportant chacune 2 à 7 sprints, et avec la possibilité pour le client de stopper à chaque release, moyennant compensation financière (donnant-donnant).

Le bilan de cette leçon est bien plus positif :

• une client satisfait malgré une augmentation de budget, mais une bonne collaboration, et surtout, un logiciel adapté
• une équipe également satisfaite, notamment par cette collaboration, mais également une bonne ambiance et un rythme soutenable
• une bonne qualité logicielle
• et les financiers fournisseurs contents grâce à des couts maitrisés

JF fait quand même remarquer que dans les 2 cas, le contexte était favorable, avec notamment des personnes motivées par l'agilité, une direction décidée, des clients ouverts, etc ...

La meilleure réussite de la leçon 2 est probablement dûe à un meilleur équilibre dans le triptique périmètre-budget-délai ! Mais également d'autres points importants :

• une préparation basée sur une vision et du fonctionnel
• un budget orienté sur l'essentiel et des releases intermédiaires
• une organisation basée sur un début de développement, une acceptation du changement, etc ...

En conclusion, je pense que l'approche agile sur des contrats au forfait est possible, mais encore délicate. Il faut quand même faire attention, et profiter d'opportunités, de contextes favorables. Et espérer un développement fort des approches agiles dans les esprits ...

Informaticiens agiles, les agents du changement - Thierry Montulé

Thierry devant prendre un train sans trainer (grèves), la présentation a été ... express ! ;-)

Au début, j'ai eu un peu de mal à accrocher, à voir où il voulait en venir. Mais j'ai finit par comprendre !

La société est en changement permanent, avec de nombreux impacts à tous les niveaux et dans tous les domaines, notamment celui du logiciel et de la SI. On tombe vite dans un cercle vicieux entre changements, difficultés d'adaptation, stress, réactions, changements, etc ... Parmi les solutions : l'agilité (bien sûr !) où les développeurs font partie des principaux acteurs !

Une phrase retenue : "Le changement ? C'est faire ce que l'on ne sait pas faire !" ....

Thierry nous donne quelques pistes pour conduire le changement :

• accompagner plutôt que subir
• les problèmes d'ingénierie logicielle sont plus sociologiques que techniques
• il faut mobiliser les acteurs en leur apportant satisfaction et motivation
• "rendre possible de faire ce que l'on ne sait pas faire"
• mais .... pas de recette miracle !

En tant que Scrum Master, je me retrouve bien dans ces idées bien orientées vers l'humain !

Thierry nous explique que dans l'organisation, l'humain se retrouve dans différentes couches. En résumé:

• couche physique, technique : changements les plus faciles et les plus visibles
• couche régulation (mesures, reconnaissances, salaires, ....)
• couche des valeurs (notamment de l'entreprise) : changements les plus difficiles et les moins visibles

Quelques obstacles observés au changement :

• une pression à court terme, pas le temps d'apprendre
• nostalgie, doutes, inquiétude
• pourquoi changer ?
• les objectifs du changement ne sont pas clairs
• manque de leadership, de crédibilité
• saut culturel et technique trop important
• manque de compétences
• ...

La liste de témoignages qu'il nous donne ensuite me fait penser à l'effet vert dont m'avait parlé François Beauregard : plus on remonte la hiérarchie, et plus les voyants sont au vert (tout va bien) ...

Thierry nous a présenté un schéma qui m'a beaucoup parlé. Je ne sais pas s'il a un nom. L'idée est de montrer les étapes par lesquelles on va passer lors d'un changement, avec un axe du temps et un axe de "refus". Une petite recherche internet me montre que ce sujet est souvent traité. Il faudra que j'y consacre un billet ...

Il faut donc communiquer avec les acteurs, et cela commence par : écouter, s'adapter à l'interlocuteur, expliquer, prouver, succiter les envies, célébrer les réussites, ...

La fin de la présentation s'est malheureusement faite au pas de course, mais un nouveau sujet m'a interpellé concernant les différents types de réactions, de profiles. Un nouveau schéma très intéressant (pareto ?), et quelques remarques à noter :

• trouver des alliés et s'y attacher
• identifier les opposants et les ignorer
• et tous les cas intermédiaires ...

En conclusion, une présentation interpellante, avec des retours intéressants sur les aspects humains ! Et encore une fois, le fait que l'agilité nécessite le changement (de point de vue) et implique d'accepter le changement (valeur de base) : tout cela n'est évidemment pas facile !

Vers le chemin de l'amélioration : Sprint rétrospective - Céline Stauder

Pour finir, j'avais choisit cette présentation, à nouveau avec Céline. Par expérience, je sais maintenant l'importance de ces rétrospectives qui peuvent réellement apporter de l'amélioration à l'équipe !

Comme pour le daily, Céline a rappelé quelques éléments de base importants :

• pour les pigs, c'est-à-dire ceux qui sont engagés dans le sprint
• en fin de sprint
• une durée d'environ 1/2 journée pour un sprint de 30 jours (~ 45' par semaine de sprint)
• environnement adapté aux échanges, en toute confidentialité, pourquoi pas "hors cadre" (dans un café, dehors, ...), climat de confiance, pas de jugements l'idée étant l'amélioration
• 2 objectifs :
1. s'exprimer, donner son ressenti
2. monter un plan d'action
• timeboxer les 3 étapes :
1. collecter les informations
2. rechercher des solutions
3. définir un plan d'action

Pour l'environnement "hors cadre", je me souviens d'une rétrospective animée dans le train (2h de TER) avec les posts-its collés sur les vitres, ça avait très bien fonctionné, avec des échanges sincères entre les équipiers (hors contexte quotidien ?).

Pour la phase de collecte d'informations, Céline a rappelé un point important, souvent oublié : il y a des sources existantes comme :

• un backlog de problèmes (s'il existe et a été renseigné en cours de sprint, pratique pour éviter d'oublier les difficultés), 
• les compte-rendus et résultats des précédentes rétrospectives, 
• ainsi que tous les métriques intéressants (vélocité, ...). 

Concernant la collecte auprès des équipiers, Céline a évoqué le tour de table orale, avec l'animateur (le Scrum master à priori) qui crée et colle des post-its sur le tableau dans 2 colonnes + ou -.
Personnellement, j'ai testé et je privilégie une autre solution qui consiste à donner à chacun une pile de post-its et un stylo en se donnant un temps fixe de réflexion (par exemple 6'). Certains vont écrire des posts-its tout au long de ce temps. Mais j'ai observé d'autres personnes qui écrivent quelques post-its en rafale puis pose le stylo et croise les bras du genre "j'ai finit". Mais il reste encore plusieurs minutes, et finalement, ces personnes finissent par reprendre leur stylo pour créer de nouveaux post-its. Comme quoi il y avait encore des choses à dire !

Ensuite, je demande à chacun d'aller coller ses post-its au tableau selon un axe +...-, certains post-its se retrouvant au milieu. J'ai constaté que cette façon de collecter permet une expression plus riche et plus intense de tous en éliminant pas mal les blocages dus à la timidité ou autre !

Ensuite, tous ensemble devant ce tableau, nous parcourons les post-its pour les découvrir ensemble, demander des précisions pour bien les comprendre, enlever les doublons et les regrouper par thème pour dégager les points importants. Puis chacun a droit à un certain nombre de vote (3, 4 ...) ce qui permet de dégager les points les plus importants à traiter.

Céline a également parlé de ce regroupement par thème qui, accompagné par les discussions spontanées, fait parfois ressortir des causes différentes de celle initialement exprimées.

La dernière étape, qui consiste à mettre en place un plan d'action, est évidemment indispensable, et Céline a insisté sur les points suivants :

• retenir quelques points (on ne peut pas tout traiter)
• se concentrer sur des choses simples
• disposer d'indicateurs mesurables pour évaluer le résultat
• pour chaque point, nommer 1 garant qui veillera à l'application et le respect de ce point par toute l'équipe

Ce qui m'a interpellé c'est que c'est exactement ce que j'avais spontanément mis en place, aux indicateurs mesurables près : certains points sont plus difficiles à mesurer, surtout lorsqu'il s'agit de ressentis humains.

En conclusion, là encore, cette présentation m'a permis de me conforter dans l'idée que je me fais des rétrospectives, et l'importance qu'elles ont dans un processus Agile, pour l'amélioration continue de l'équipe, à condition de mettre en place un plan d'action, de le suivre, et de l'évaluer.

Conclusion

Comme je l'ai mis dans ma fiche d'évaluation en fin de conférence, je n'ai pas regretté le déplacement, au contraire. Globalement, j'ai ré-entendu pas mal d'informations que j'avais déjà, mais cela m'a permis de confirmer que pour moi, l'agilité est maintenant incontournable pour une production logicielle de qualité, dans un contexte positif.

Je constate tout de même, vu le public présent et les questions posées, que l'agilité a encore du chemin à faire, mais la curiosité, ou plutôt l'intérêt d'un nombre croissant d'acteurs, permet d'espérer un développement intéressant de ces valeurs, développement auquel j'espère pouvoir contribuer.

Un grand merci aux organisateurs et aux intervenants pour ce bon moment, bien organisé, bien sympathique et très enrichissant !