Edito

Par Luc Legardeur

C'est l'été. Déjà !.

Que le temps passe vite ! Pour le SUG ces 6 premiers mois d'activité ont été riches en activités.

Nous sommes plus de 340 membres, nous nous sommes rencontrés deux fois à Paris (à l'occasion de la soirée inaugurale et au World Café mais aussi en Province grâce à Meetup à Rennes, Nantes et Bordeaux, publié 3 newsletter avec celle-ci, lancé une enquête nationale à laquelle plus de 200 personnes représentant quelques 150 entreprises ont répondu.

Merci à toutes et à tous

A propos de l'enquête, où en est on ?

Elle est finie mais nous avons dû procéder à une traduction en anglais pour la faire diffuser au-delà de la communauté francophone et obtenir la co-signature de Jim Cundif, le Président de la Scrum Alliance. Nous devrions donc la rendre disponible sous huitaine. Les résultats, vous le constaterez, sont très encourageant et nous sentons un véritable tournant dans l'histoire agile française.

Merci donc aux nombreuses et nombreux participants. C'est Borland qui a gagné la Wii au tirage au sort du 18 Juin.

En ce qui concerne les activités du bureau du SUG, nous nous sommes réunis afin d'élire un nouveau secrétaire et c'est Nicolas Martignole qui prend cette responsabilité. Nous nous verrons le 24 Septembre à l'EPITA également. L'agenda de la soirée vous sera fourni dès la rentrée. Bonnes vacances à toutes et à tous. Luc Legardeur.

Retour sur XP Day France 2009

Par Yannick Ameur

Organisateurs :

• Sébastien DOUCHE
• Sandrine OLIVENCIA
• Thibault BOUCHETTE
• Yannick AMEUR

PO :

Laurent Bossavit et le board de XP France

Aides :

• Luc Bizeul
• Raphaël DERBIER
• Yann Picard-de-muller
• Et d'autres...

XP day en quelques chiffres :

• Plus de 70 orateurs
• 180 participants soit environ 265 personnes avec les organisateurs et les orateurs
• 1 an de préparation et une nouvelle équipe déjà en marche pour 2010
• Satisfaction :
  • + 98 % des participants reviendront
  • 100% des sponsors Full sont contents de leur visibilité et nous demandent plus pour l'an prochain

Nos enjeux et chalenges

• Augmentation des tarifs pour les participants
• Nouveau mode de sponsoring
• Passer de 150 personnes en 2008 à 250
• Trouver un site sympathique
• Cibler aussi les managers Cet objectif n'a pas entièrement été réussi mais nous y travaillons pour 2010.

Ma conclusion

Avec tous les retours positifs que nous avons : Liste des retours sur le dernier XP Day 2009

Je ne prends pas vraiment de risque en vous disant que ce fut une "Success Story".
Le cadre enchanteur de la Porte Jaune, la qualité des présentations et un temps +/- clément
nous ont permis de vous faire participer à une conférence agréable sur l'agilité au milieu d'agilistes confirmés.

Actuellement, nous préparons l'édition 2010 qui se nommera ... ??? à suivre dans le prochain numéro

Retour sur le Scrum Café à Bordeaux le 11 juin 2009

Par Philippe Launay

Le 11 juin est une date importante à Bordeaux.

En effet, pour la première fois, SCRUM a réuni une vingtaine de personnes autour de ce sujet.
Les participants se sont retrouvés dans les locaux de Capgemini qui, pour l'occasion, nous a accueillis dans ses locaux, et offert le café et les viennoiseries.

Après un accueil convivial, chacun a pu se présenter et indiquer son niveau de connaissance ou d'attente en ce qui concerne SCRUM.
Les participants étaient d'origines diverses : SSII, éditeurs de logiciels, grands comptes, développeurs indépendants ainsi que des organisateurs de l'agile tour Bordeaux http://www.agiletour.org/en/node/14.

Après une introduction de la part de nos hôtes Capgemini, une première thématique a été lancée, en rapport avec le changement de modèle économique sous-jacent à l'emploi d'une méthode agile, en particulier SCRUM. La question est lancée, mais reste pour l'instant d'actualité.

La rencontre s'est poursuivie par un retour d'expérience, ce qui a permis ensuite d'échanger autour. La discussion a été très ouverte, très enrichissante et alimentée par des opinions divergentes, plus ou moins radicales. Tout cela était tellement prenant, que le temps accordé à la discussion a été totalement insuffisant : de trente minutes nous sommes passés à presque une heure trente. Au plus grand plaisir de tous les participants.

De nombreux sujets ont été abordés, certains très passionnés comme faut-il garder de la documentation et laquelle ?, ou le rôle du Product Owner, mais la confrontation des divers points de vue ou des diverses expériences a permis à chacun de sortir de cette rencontre avec une certitude : Avancer avec SCRUM.

Ce premier rendez vous s'est conclu sur la volonté de renouveler ce type d'évènement, probablement sur un créneau horaire en fin de journée pour attirer plus de monde.

Alors qu'on se le dise, en Septembre, SCRUM aussi fera sa rentrée à Bordeaux et gageons que nous serons encore plus nombreux!

Retour d'expérience

Par Claude Aubry et Antoine Vernois

Interview de Julien Patou de la société People In Action

SUG : Tu peux nous présenter la société et le projet ?

Julien Patou : People In Action (PIA) est une société qui a 5 ans avec un effectif d'une quinzaine de personnes qui se positionne sur les applications internet riches (RIA). Les projets sont des logiciels sur mesure livrés clés en mains souvent orientés cœur de métier et stratégiques pour le client. Dernièrement, nous avons travaillé sur des sujets assez critiques notamment pour les banques. Au niveau technologie, c'est Adobe/Flex pour l'IHM. Du coté serveur c'est J2EE/Hibernate/Spring/Oracle/....
On utilise aussi pas mal Drools, le moteur de règle, notamment sur le projet dont je vais vous parler.

Le projet en question porte sur la gestion d'assurances vie pour l'un des leaders mondiaux de la gestion de fortune (souscription, arbitrages, versements, ...).
C'est un projet qui a duré 1 an avec jusqu'à 6 personnes plus un Scrum Master.

SUG : Qui a demandé à introduire Scrum ?

JP : Scrum a été introduit chez PIA en juin 2007 sur un projet auquel je n'ai pas participé. Le bilan a été très positif et la Direction a souhaité le généraliser à tous les projets dès 2008.
Pour ce nouveau projet, nous avons décidé d'y aller totalement et c'est, je pense, ce qui nous a permis en partie de décrocher le marché.
Dans la phase d'avant vente, nous avons présenté Scrum au client. Ils auraient pu dire non, mais ils ont été motivés pour essayer cette approche.
C'est toujours un peu hasardeux pour un décideur, ça représente un changement et il faut avoir confiance.
Cela se base sur une relation de confiance.

SUG : Une question critique dans ce genre de relation : qui va jouer le rôle de Product Owner ?

JP : Un des deux dirigeants de notre société avait la casquette AMOA et Product Owner.

SUG : Le PO était donc de chez vous ?

JP : Oui, complètement. Une fois le projet signé, dans une première phase, le PO a rédigé les use cases de la V1 avec le chef de projet de la banque.

SUG : Use cases ou user stories ?

C'est bien des use cases.
Cette première phase a ensuite donné lieu à des story boards "low fidelity" : plus ou moins des copies d'écran en noir et blanc orientées fonctionnalités et dynamique de l'application.
Ensuite a eu lieu un sprint 0 afin d'étudier la faisabilité et réaliser des "proof of concept" car il y avait des choses un peu dangereuses, notamment au niveau de l'IHM et du moteur de règles. L'application devait pouvoir permettre au client d'écrire lui même toutes ses règles métiers en langage naturel (le français).

SUG : Combien de temps a duré le sprint 0 ?

JP : Un bon mois et demi.

SUG : C'est à ce moment là que le backlog de produit a été constitué ?

JP : Oui après, à partir des use cases on a fait un backlog de produit. Deux versions de l'application ont été prévues : la v1 en 6 mois et la v2 6 mois de plus.

SUG : Des sprints de quelle durée ?

JP : Au départ, on a fait des sprints de 3 semaines. Puis on est revenu sur des sprints de 2 semaines car c'était trop long. On a fait 23 sprints en tout.
Au niveau organisation, nous avions une équipe distribuée entre Paris et Toulouse. Nous faisions tous les daily meetings par skype.
En fin de sprint, nous faisions une démo au client.

SUG : A Paris ou à Toulouse ?

JP : 1 fois sur trois, c'était à Paris ou Toulouse pour qu'on se voit tous. 2 fois sur 3, cela se faisait à distance en vidéoconférence.

SUG : Le client était toujours là ? C'était plusieurs personnes ?

JP : En général, il y avait toujours au moins 2 ou 3 personnes plus le PO.
Ils avaient préparé le backlog pour le sprint suivant.

SUG : Le client et le PO ?

JP : Oui, ils se voyaient quelques jours avant la fin de sprint, parfois même pendant, pour établir les nouvelles fonctionnalités et les prioriser.
Derrière on faisait une séance de planning poker pour les estimer, puis on les découpait en tâches pour les planifier.

SUG : Vous utilisiez un outil ?

JP : Oui, Rally Dev, qui permet bien le travail à distance.

SUG : Les clients utilisaient Rally ?

JP : Oui, ils s'en servaient pour rentrer des bugs et des defects.

SUG : Le client a t'il pu redéfinir le périmètre des fonctionnalités ?

JP : Oui, en continue. Pour les petites fonctionnalités, ils le faisaient directement via des defect-request de Rally. Pour les choses plus importantes c'était fait en concertation avec le PO. Parfois, en plein cours de sprint, une nouvelle fonctionnalité arrivait nous poussant à en sortir d'autres du sprint backlog en cours.

SUG : C'est pas tout à fait la règle ?

JP : Non, mais le projet était très critique pour le client. Au départ, on pensait utiliser Scrum de façon stricte, au final on est resté assez souple par rapport à ça.

SUG : L'équipe était globalement à Toulouse ?

JP : Sur Toulouse on a été jusqu'à 4 développeurs, et 2 3 maximum sur Paris en plus du PO et du Scrum Master.
Sur la fin du projet, j'ai été Scrum Master et le PO était directement une personne de la banque. Ça c'est très bien passé.

SUG : Le projet a été livré ?

JP : oui, la v2 a été livrée fin mai, la v1 en octobre 2008. On n'a pas livré à chaque fin de sprint, mais entre la v1 et la v2 il y a eu des livraisons intermédiaires, des bug fixs, mais aussi de nouvelles fonctionnalités. 4 ou 5 livraisons après la v1.

SUG : C'était pour mettre en production ?

JP : Oui, sur Paris d'abord puis à l'échelle nationale ensuite.

SUG : C'était un appel d'offre, comment avez-vous géré les changements de périmètre ?

JP : D'un point de vue client, on peut voir la gestion de projet avec deux approches : soit c'est à budget fixe, soit c'est à périmètre fixe.
Dans notre cas, nous étions sur un mix des deux approches. Notre client avait un budget max avec lequel nous devions réussir à implémenter un périmètre minimum tout en respectant les délais. Au final, nous avons réussi à aller au-delà du périmètre minimum tout en respectant le budget max. Un autre point important est que si le périmètre était globalement bien défini d'un point de vue macroscopique, au niveau micro (critères d'acceptation), il a constamment évolué.
A la fin de la v1, le client était vraiment enchanté, il nous a reçus dans ses locaux, on n'avait jamais vu ça.
Surtout par le respect des spécifications et de ses besoins propres.
Grâce aux démos régulières, la qualité était vraiment bonne.
Sur la fin de projet, ils se sont rendus compte qu'il allait manquer des choses dont ils avaient besoin, ils ont donc rallongé un peu.
Ça a été une négociation permanente.
Justement, je pense que cette façon itérative de travailler permet une meilleure gestion de contrat. Mais il faut de bons clients. La clé de la réussite d'un projet, c'est un bon client. Et là, c'était le cas.

SUG : Vous avez mesuré la vélocité ?

JP : A chaque fin de sprint on mesurait la vélocité. On ne s'en est pas servi de façon très efficace : dans le sens où la vélocité était très
volatile.
C'était essentiellement pour prévoir ce qui allait rentrer dans le sprint suivant.

SUG : La satisfaction du client au final ?

JP : Très bonne. D'autant que ceux qui ont initié le projet étaient soumis à une pression importante de la part de leur direction car il s'agissait d'un point vraiment critique pour eux, le véritable cœur de leur métier. Ils étaient donc vraiment contents que les délais aient été respectés tout comme les fonctionnalités avec une application robuste.

SUG : Il y avait une anticipation sur l'IHM ?

JP : Oui, chez PIA on insiste beaucoup sur l'ergonomie, l'ergonomie cognitive même. Il y a un designer, transverse à tous les projets, qui ne fait que ça. Après les story boards low fidelity dont je parlais tout à l'heure, il réalise des story boards high fidelity qui définissent les interfaces au pixel près. Cela est fait en étroite collaboration avec le client dans le respect de sa charte graphique.

SUG : Il y a eu des modifications de cette interface ?

JP : oui, à chaque démonstration le client faisait ses remarques. Pour nous, au dev, ce qui importait le plus c'était les fonctionnalités. Le client, lui, voyait en premier les défauts graphiques : un trait mal placé, une couleur mal adaptée, etc. Grâce aux démonstrations régulières, on a pu faire les retouches en continu. Avec une unique revue, il aurait listé cinquante pages de commentaires qu'on n'aurait jamais pu traiter. C'était du refactoring permanent.

SUG : Le client utilise Scrum pour ses développements internes ?

JP : Non, pas du tout. A ma connaissance en tout cas.

SUG : Vous avez tout de même un fonctionnement peu standard: PO interne, équipe sur deux sites,... Vous avez eu des problèmes ?

JP : Le PO interne n'a posé aucun problème. En fait, il avait une mission officielle d'AMOA donc il était censé vraiment connaitre le produit. Il faisait réellement office de client. Le fait que l'on travaille en offshore ou nearshore n'a posé aucun problème. On faisait les daily meeting tous les matins ponctuellement en mettant à jour le sprint backlog. Dès qu'il y avait des problèmes ou des questions, on s'appelait. Au bout d'un moment, on avait toute la connaissance fonctionnelle à Toulouse et on pouvait passer plusieurs jours sans avoir de questions à poser. Dans l'utilisation de Scrum, je dirais que même au bout d'un an, même en connaissant bien le produit, on se trompait souvent dans les estimations. En général on se trompait dans les deux sens, et en moyenne ça s'équilibrait.

Ça impliquait tout de même que parfois on avait à rajouter ou enlever des User Stories au sprint backlog. Ça n'était pas vraiment gênant. Les développeurs ont été complètement satisfaits de ce fonctionnement.

SUG : Vous avez mis des pratiques d'ingénierie en place ?

JP : On travaillait en Test Driven Developpment. Écriture des tests d'abord et écriture du service/couche business ensuite. On pratiquait aussi le refactoring et l'intégration continue.
Dans la mesure du possible, nous avons fait évoluer le modèle de données du domaine en permanence plutôt que de le figer au départ.
Au niveau développement pur, dès que l'on avait une fonctionnalité un peu conséquente, le (ou les) développeur(s) - au moins 2 personnes dans le cas de fonction critique -, faisait un document de conception (diagramme UML) posté sur le wiki. Le document était revu par l'équipe puis validé par le Scrum Master et/ou le PO avant d'attaquer le développement. Mais tout était fait dans le cadre d'un sprint.
La plus grosse user story qu'on ait eue avait une durée de deux semaines.

SUG : Vous aviez des post-it au mur ?

JP : Non, nous avons essentiellement utilisé l'outil. Nous utilisions les post-it pour les rétrospectives : la timeline des évènements du sprint, ce qui s'est bien passé, ce qui était moins bien, les actions à mettre en place au prochain sprint.

SUG : Comment s'est passée la transition à Scrum ?

JP : Scrum, c'était un choix de la direction. A Paris, nous avons une personne qui est le responsable méthode et qualité qui connait très bien cette approche.
Nous avons lu des documents puis il nous a fait une formation à tous. Ça c'est très bien passé.
On a eu des prestataires en cours de projet qui se sont tous intégrés très vite. A peine une demi-journée pour les brieffer sur la méthode et c'était bon. Tout le monde a adhéré.
Tous les retours étaient positifs, même de la part des personnes qui n'en avaient jamais fait.

SUG : Merci Julien pour ce très beau retour d'expérience.

JP : Merci à vous.

Des nouvelles de nos régions

Les Bretons Agiles

Par Laurent Morisseau

Les mois de Mai et Juin ont été particulièrement chargés sur Rennes autour de l'agilité:

• La présentation de Patrice Petit sur le thème de "l'illusion et la désillusion" au forum Grafotech Agile avec l'association Granit
• Le retour d'expérience d'une année de Scrum chez Ripple Motion de Nantes au forum Grafotech Agile
• Une présentation Sensibilisation Agile - Scrum au Breizh JUG par Philippe Ensarguet et Laurent Morisseau
• Une formation CSM par Agilbee pour AgileRennes qui a formé 17 Scrummasters, pas mal pour une première session
• Une soirée try-out avec deux sessions: une sur le management visuel par Laurent Morisseau et l'autre sur le pair solving par Karine Sabatier

il était temps de faire un premier bilan:

Les forums Grafotech Agile réunissent entre 40 à 50 personnes par session avec pas mal de renouvellement et une audience très hétérogène: développeurs, DSI, directeur, MOA, chef de projet, ...

Les échanges lors de cette session démontrent un réel interêt pour ces méthodes.

La communauté AgileRennes s'est stabilisée autour de 60 membres et s'est enrichie d'une quarantaine de membres avec le groupe AgileRennes sur LinkedIn.

AgileNantes

Pacte Novation a accueilli une douzaine de personnes le 17 Juin pour une session sur le management visuel par Laurent Morisseau.

Le groupe Nantais compte aujourd'hui une vingtaine de membres.

Ces deux groupes Rennes-Nantes travaillent ensemble à la promotion de l'Agilité en générale et Scrum en particulier et ont créé depuis le début de l'année une dynamique locale qui permet aux acteurs de l'Agilité d'être visibles, aux early adopters de partager leur expérience.

Cette dynamique va encore s'accentuer à la rentrée avec Agile Tour dont Rennes sera ville étape le 1er Octobre et Nantes le 14 Octobre.

Apports d'un coach accompagner le chef de projet vers son nouveau rôle (4)

Par Véronique Messager

« Les individus et leurs interactionsavant les processus et les outils »

Extrait, Manifeste Agile, 2001

Face à l'adoption d'une nouvelle méthodologie agile, le chef de projet est confronté à deux changements : le premier concerne l'évolution de son propre style de management, le second concerne la transformation de son équipe (évolution méthodologique et technique, mais aussi culturelle et comportementale).

Premier apport du coach : aider le chef de projet à intégrer et s'approprier la dimension du changement (voir newsletter de Mars 2009). Ce changement concerne son style de management, moins directif, peut-être, plus « délégatif » pour permettre à l'équipe de s'auto responsabiliser et de gagner en autonomie ; son mode de communication, plus « sincère et honnête » (XP). Le coach sensibilise le manager à l'intérêt qu'il a à écouter ses collaborateurs et à entrer en communication avec eux.

Le deuxième apport du coach est d'amener le chef de projet à accepter de ne plus « faire » mais de « faire faire ». En effet, le chef de projet agile n'est plus un apporteur de solutions ni un donneur d'ordres, mais un « leveur d'obstacles ». Ses compétences techniques, « prétendument supérieures » ou son autorité de facto ne légitiment plus son positionnement. Il doit consentir à se consacrer davantage aux interactions au sein de l'équipe et à celles de l'équipe avec l'extérieur.

Avec bienveillance, le coach permet au coaché de s'interroger sur sa capacité à se détacher de l'envie de tout contrôler ; il l'assiste dans sa recherche de nouvelle légitimité.

Écoute et efficacité dans la levée d'obstacles sont deux moyens de gagner l'adhésion et la reconnaissance des membres de l'équipe. Mais la délégation soulève la question du droit à l'erreur. Souvent, un manager qui ne délègue pas assez argue du fait que « l'on n'est jamais aussi bien servi que par soi-même », ou que « ce n'est pas assez rapide » ou encore qu' il « ne peut compter sur les autres ! »...

Dans une démarche d'amélioration continue, l'expérimentation est un droit ; l'erreur est donc acceptée ainsi que le droit à reconnaître ses erreurs.

Le troisième apport du coach peut être de susciter, chez le chef de projet, une réflexion sur son rapport à l'erreur ; il peut l'aider à réfléchir sur les bénéfices qu'il peut tirer, en termes de sérénité et de liberté, de la responsabilisation et de l'autonomie de son équipe. Il l'amène à réfléchir sur ses propres erreurs et sa façon d'appréhender les erreurs commises dans l'équipe.

Voici quelques exemples où le rôle du coach facilite cette transformation du rôle du chef de projet, progressivement, et non dans la douleur. Bien d'autres circonstances peuvent bénéficier de l'apport d'un coach...

A suivre....le mois prochain.

Les prochains événements

Par l'équipe de la Rédaction