Neal Ford, Crédit photo : USI 2010 album sur Flickr.com

De l’importance de la communication
Après cette première partie, Neal Ford nous parle maintenant de la communication. Plus importante que la technologie, nous allons voir que la communication est l’un des points clés pour réussir des projets.

Neal demande à la salle si nous avons déjà fait partie de projets qui se sont plantés. Rires, quelques mains se lèvent. Il demande ensuite si la raison de l’échec était le mauvais choix d’une technologie, ou une mauvaise communication ? L’ensemble répond : la communication.

Il est donc plus facile de planter un projet car vous communiquez mal, que parce que vous avez pris un framework exotique au lieu de prendre un framework standard.

Les projets se plantent souvent à cause des gens. La communication entre les gens devient très importante. Nous sommes des créatures massivement communicantes. Notez qu’en prison, la plus grosse punition est d’aller au mitard. De ne plus pouvoir communiquer avec d’autres humains… Dingue non ? Pensez aussi aux gens que l’on met « au placard »… Nous avons besoin de communiquer. C’est vital.

Alistair Cockburn explique dans un graphe que la qualité de la communication avec les outils modernes est très inégale.

Pour travailler, nous sommes bien plus efficace devant un tableau blanc qu’au téléphone, ou même pire, via un document Word. Le pire des processus de communication est le papier écrit. Et le drame, c’est que c’est l’un des plus utilisés dans les Entreprises. C’est marrant, mais la semaine dernière je suis allé chercher un grand tableau blanc pour notre équipe, et je l’ai installé dans notre bureau… Croyez-moi cela marche.

Neal Ford explique que c’est pour cette raison, qu’il est illusoire de croire qu’une spécification technique envoyé à des développeurs en Inde donnera le logiciel escompté. C’est une perte de temps et d’argent. Cela ne fonctionne pas.

Cela va plus loin. Nous avons même une capacité limitée à communiquer et faire autre chose en même temps. Vous ne vous êtes pas demandé pourquoi il est dangereux de téléphoner et conduire en même temps ? Pourtant vous avez le droit de parler avec votre voisin, vous pouvez écouter la radio, mais on vous interdit de téléphoner en même temps. Or pour ceux qui ont essayé (moi le premier) vous vous rendrez compte que la communication au téléphone est moins bonne que lorsque vous avez la personne à côté de vous. Cela vous demande même un effort plus important pour comprendre. Et cet effort vous déconcentre de la route. C’est bien là la preuve que les canaux de communications demandent plus ou moins d’efforts.

Un document écrit est aussi très destructif, car la possibilité de donner son retour n’existe pas ou peu, par rapport à une communication face à face. Bien entendu, ces documents sont souvent écrits à la suite de réunions, où nous nous sommes vus… Mais souvent le développeur n’aura pas eu l’opportunité de discuter avec le client, et de poser quelques questions simples. Il est donc primordial pour réussir un projet de prendre en compte ce facteur de communication.

Le manifeste Agile propose 4 valeurs clés, dont l’une est exactement ce que Neal Ford vient d’expliquer.
Les quatre valeurs fondamentales Agiles sont :
– Davantage l’interaction avec les personnes que les processus et les outils.
– Davantage un produit opérationnel qu’une documentation pléthorique.
– Davantage la collaboration avec le client que la négociation de contrat.
– Davantage la réactivité face au changement que le suivi d’un plan.

Voir l’article original en Anglais : http://agilemanifesto.org/

Neal Ford présente ensuite un projet supporté par ThoughWorks au Malawi. Ce projet permet à des infirmières de transmettre via SMS des bilans de santé, alors que les moyens de communications sont très mauvais, et que la vie est très dure. Ce projet RapidSMS, est un projet open-source réalisé pour l’UNICEF en Python.

La communication dans ce projet est vitale, et elle permet de sauver des vies.

Le Feedback
Martin Fowler attaque maintenant la deuxième partie de sa présentation. Pourquoi certains projets réussissent bien ? Il souhaite nous parler de l’importance du retour d’information, le feedback en Anglais.

Martin nous montre une photo d’un gâteau. Réalisé avec une approche prédictive, tout le monde sait qu’il faut respecter la recette en cuisine pour réussir. Ma grand-mère me disait de mettre 75g de farine, et de ne pas poser de questions. La cuisine est une alchimie intéressante. Si vous avez une recette pour 4 et que vous voulez faire un gâteau pour 8, il ne faut pas doubler les quantités. En effet, lorsque vous doublez les quantités, vous avez toutes les chances de planter votre gâteau. Curieusement, la cuisine est bien plus compliquée que ce que nous pensons. Et bien le développement logiciel, c’est pareil. Il ne sert à rien d’ajouter 2 développeurs en pensant que vous irez 2 fois plus vite. Parfois même, vous irez 2 fois moins vite, car il faudra former ces nouveaux arrivants…

Martin nous montre une photo de gâteau donc, et une photo de pomme de douche. Quelles différences y-a-t-il entre une pomme de douche « chaud-froid » et un gâteau ? Et bien une histoire de retour, de feedback.

La cuisine est un processus défini alors que régler une douche est un processus adaptatif/empirique.

La cuisine suit un plan précis, une recette. Et le feedback ne sera fait qu’à la fin. Peut-être que votre gâteau sera raté, peut-être qu’il sera excellent, vous ne le saurez qu’à la fin. Au contraire, si vous prenez une douche dans un Hôtel, et que vous devez régler la température, vous allez utiliser un feedback permanent pour adapter la température. C’est l’approche Agile.

Cette illustration nous permet de comprendre qu’il existe 2 types de processus, et que cela fait partie de notre vie quotidienne. Dans le cas d’un processus empirique (la douche) nous examinons le résultat final pour adapter le signal d’entrée. Dans le cas d’un processus défini, si je suis la recette à la lettre j’aurai toujours le même gâteau, je serai capable de reproduire à l’identique la même chose.

Or chaque développement de chaque projet est différent et donc l’approche prédictive ne semble pas une bonne chose. Par contre pour mélanger des ingrédients chimiques dans une usine, vous serez d’accord qu’un processus défini est primordial, pour des raisons de sécurité. Pour le développement d’un logiciel, Martin Fowler nous demande de bien réfléchir avant de choisir une méthode de développement.

Si vous prenez l’approche empirique (la douche) pour construire votre logiciel, il est donc très important de mettre en place un système de feedback. C’est pour cette raison que les équipes Agiles s’installent des murs de post-it, des Kanban, des indicateurs visuels et toutes sortes de trucs sympas : pour avoir du feedback disponible à tout moment.

Martin Fowler montre la photo d’un immeuble de 20 étages en Chine. On voit qu’au 15ème, les fenêtres sont couvertes de post-it. C’est l’étage de ThoughWorks, facilement identifiable de la rue… Rires dans la salle.

L’intérêt d’un Kanban est que ce tableau est lisible par tout le monde. Ecrit clairement, il donne une vision de l’avancement du projet. Tout le monde peut y participer, et donc doit pouvoir y accéder facilement.

Feedback sur la construction du logiciel
Martin Fowler insiste ensuite sur l’importance de donner un indicateur sur l’avancement de la construction du logiciel. Nous devons savoir où nous en sommes en terme de développement du logiciel.

L’intérêt d’afficher sur le mur le planning de son projet est primordial. Martin Fowler explique qu’il lui arrivait auparavant d’aller dans des équipes de développement, et de constater que les développeurs n’avaient pas accès au planning global du projet. Mettez en place un tableau avec les prochaines semaines de développement, cela permettra de donner plus de visibilité et donc de sens, au travail de chacun.

A propos des outils électroniques, les équipes de développement préfèrent utiliser un vrai tableau plutôt qu’un logiciel. Je confirme : ne vous jetez pas sur un outil, privilégiez une solution simple à base de post-it et de fiches bristols. Cela fonctionne très bien.

Dans ce qui est de donner du feedback, Martin rappelle que le seul moyen de voir un progrès dans le développement d’un logiciel, c’est d’avoir un logiciel qui marche. Cela veut aussi dire, un logiciel déployé et testé.

Le processus de construction de votre logiciel est très important. Certains projets aiment bien utiliser des Lava Lampes rouges ou vertes pour signaler que la construction du logiciel fonctionne, ou non. A titre personnel, j’ai mis en place cette pratique à la BNP il y a un an et nous avions une Lava Lampe rouge que nous allumions pour signaler un « Build failed ». C’était sympa.

Neal Ford parle ensuite de CCBoard, un tableau de bord de construction de projets. Ce logiciel open-source permet d’afficher le status de toutes vos builds.

Faire de l’intégration continue c’est compiler, tester, packager, déployer, retester et valider un logiciel. Cela demande un effort, qui permet cependant de réduire à zéro l’effort de « release » d’un logiciel. Si vous êtes capable de construire à tout moment votre logiciel, et de le packager, vous comprendrez que faire « une release » devient facile.

A propos des pratiques de développement logiciel, Martin Fowler parle du Pair Programming. Il a été observé que lorsque 2 développeurs travaillent en même sur un écran, les deux n’utilisent pas la même partie de leur cerveau. Celui qui tape le code sur le clavier est dans la réalisation, alors que celui qui est assis à côté est dans la réflexion, la beauté du code et la vision globale. Celui qui code est le pilote, et celui qui est à côté est le navigateur. Cela permet de réaliser du code de meilleur qualité.

Martin utilise l’image d’un jardin de la Renaissance, tiré d’un château de la Loire. Puis ensuite l’image d’un jardin tropical, tiré d’un parc en Angleterre. D’un côté l’ordre, la clarté. De l’autre le chaos, le foutoir apparent. Et pourtant ces 2 jardins sont beaux. Ils correspondent à deux approches : l’une procédurale, l’autre artistique. Tout ceci pour illustrer qu’il faut des deux pour faire un monde. Et il nous encourage à mélanger ces 2 approches lorsque nous codons, en faisant du Pair Programming par exemple.

Dernière partie
« La perfection n’est pas ce que nous visons, mais ce que nous faisons à tout moment ». Cette phrase de Kent Beck résume l’approche eXtrem-Programming, où l’on fait de tout, mais très bien et en permanence.

L’introspection est alors important. Chaque semaine, l’équipe doit réfléchir et s’assurer de s’améliorer en permanence. Si une équipe ne change pas ses pratiques régulièrement, et qu’au bout de 12 mois vous la retrouvez dans le même état, c’est qu’elle a cessé de progresser. Et c’est un indicateur qu’il manque peut-être des pratiques de rétrospectives.

Neal Ford ensuite à propos de la communication et du retour, nous raconte un peu ses expériences passées. Dans les équipes de développement qu’il a croisé, il a remarqué que les équipes aiment bien laisser trainer des petits jeux, des casse-têtes ou des Rubbik’s Cub. Cela permet en fait de décompresser et de mobiliser d’autres parties du cerveau. Il y a 5 ans, je me souviens que nous avions un petit panier de basket, et que nous faisions des tournois, histoire de lever le nez du code de temps en temps…

Neal Ford dit clairement que mettre des développeurs face à un mur pour coder, n’est pas une bonne idée. Il faut stimuler leur créativité. Il y a des entreprises qui mettent en place des règles et qui vous interdisent d’afficher des photos personnelles, des posters de cinéma, ou de vous balader en tee-shirt « My bozz rebooted » dans les couloirs… Pensez à ces photos des locaux de Google, où à l’excès inverse, les gens peuvent avoir un peu tout et n’importe quoi dans leur espace de travail… La notion de « Cubicle » est cependant très américaine, et c’est un aménagement de bureaux peu utilisé en France.

Ce qu’il faut retenir, c’est qu’il important de traiter les développeurs comme des créatifs. Ils doivent pouvoir aménager leur espace de travail librement. Mettez des tableaux blancs, laissez-les s’installer et s’approprier leur bureau. Si vous n’avez que des prestataires qui viennent de SSII, croyez-moi c’est possible. Nous avions une lava-lampe, j’avais acheté une petite plante verte, nous avions nos posters Scrum, le tout en évidence à côté de la cafétéria, et personne ne nous a jamais dit d’arrêter.

A propos de la construction des logiciels, Neal Ford raconte une histoire sympa. Dans une des équipes où il a travaillé, le logiciel d’intégration continue joue une petite musique de 3 secondes lorsque la compilation fonctionne. C’est très pratique, car cela permet de vous signaler que vos derniers commits fonctionnent, sans vous déranger. Vous entendez vos 3 secondes de musique, et vous pouvez continuer. Chaque développeur avait sélectionné une chanson ou un bruit, et donc pouvait savoir que son commit était passé. Sympa non ?

Ensuite, lorsque le build cassait, une autre chanson se mettait en marche. Dans son équipe c’était « Oups I did it again ! » de Brittney Spears. Et d’entendre cette chanson mettait une bonne ambiance. Toute l’équipe se mobilisait pour aller réparer le logiciel immédiatement.

Neal Ford montre ensuite une photo d’une équipe de développement. On voit une énorme peluche de Kangourou assise sur le fauteuil à côté du développeur. Celui qui a le « Stuff Kangoroo » est responsable du build pour la journée. Lorsque la chanson de Brittney se met en marche, son travail est alors de chercher le développeur et de s’assurer que le logiciel est réparé rapidement. C’est un peu un rôle barbant, donc ce rôle tourne. Et celui qui a cassé le build récupère alors le « Stuff Kangoroo ». Et ainsi de suite…

Notre travail peut être amusant, et sérieux. Derrière cette peluche « pas sérieuse » il y a une pratique très précise de génie logicielle, celle de fixer tout de suite la construction du logiciel. Et ça marche ! Alors n’hésitez pas à aller chez Toyr’us et d’acheter un énorme Ours en peluche, et de le donner à l’équipe de développement. J’ai repéré une peluche de « Sully » du dessin animé « Monstres et compagnie » et je compte bien l’embarquer pour notre projet actuel.

Neal Ford montre enfin une page de Wiki généré automatiquement par l’outil de construction, sur laquelle les développeurs peuvent aussi écrire. Ce carnet de bord quotidien raconte la journée passée. A quelle heure Nicolas a commité son code… a quelle heure la compilation s’est terminée, puis les tests. Ensuite on voit que Pierre a annoté la page et qu’il a marqué un détail sur l’installation… Bref un carnet de bord, comme en marine, mais généré en partie automatiquement.

Conclusion
En conclusion, Neal Ford reprend la question du départ : « Pourquoi le développement Agile fonctionne-t-il si bien ?« . Et bien grâce au Feedback, grâce à la communication, et aussi parce que nous percevons le métier de développeur différemment. Nous pensons que la réflexion est aussi importante que la réalisation. Et nous pensons aussi que le développement est fun !

J’attaque la journée par une présentation sur la PNL. Ensuite nous avons présenté Domain Driven Design avec François Wauquier. J’ai passé un bon moment et je n’ai pas vu l’heure passer. Juste le temps de remballer le Mac, et nous passons dans la salle d’à côté.

Jean-Laurent de Morlhon et Eric Mignot présentent un sujet sur Scrum intéressant : « Comment j’ai remplacé 30% de mes développeurs en adoptant l’Agilité« . Jean-Laurent présente son retour sur la mise en place de Scrum chez Vidal Software. Avec une expérience de presque 4 ans sur le sujet, ce fut très intéressant. Eric Mignot de Pyxis était là pour jouer le rôle du Coach et pour nous aider à trouver le sens et à nous faire réfléchir sur le témoignage.

J’ai beaucoup aimé cette présentation. C’est un témoignage vivant de la mise en place de l’Agilité dans une organisation, chez un éditeur. Une équipe de 10 développeurs, plusieurs produits, la place des Product Owners, la relation avec la hiérarchie, tous les sujets ont été abordés.

Jean-Laurent présente les différentes versions de leur « Scrum Board ». La version v1 classique avec « To Do/Checkout/Done ». Puis l’ajout d’une colonne « Good » pour que le Product Owner puisse donner son retour. Les Stories restent sur une ligne, et ce sont les Tasks de la Story qui naviguent de colonne en colonne. En 4 ans, le tableau s’est plus enrichi que simplifié. Mais il a répondu aux besoins de l’équipe.

La validation au fil de l’eau par le P.O est une démarche intéressante. Elle consiste lorsque le P.O est disponible, à faire une validation dès lors qu’une Story est terminée.

Eric insiste aussi sur l’importance du mot « démo ». Lorsqu’il arrive dans des équipes et que celles-ci disent « on fait la démo au PO ? « , c’est très intéressant. Le mot démo véhicule une intention différente du mot « rétrospective ». Ce mot tend aussi à influencer la personne qui vient assister à la rétrospective. Ce n’est pas un mauvais mot, c’est un mot qui donne de l’information sur la manière dont l’équipe perçoit son travail.

La rétrospective justement, est le point qui pendant les 6 premiers mois, n’a pas du tout été fait par l’équipe. Avec le recul, Jean-Laurent explique que l’équipe étant jeune avec l’Agilité, ils ne percevaient pas l’intérêt immédiat de la rétrospective. Puis ensuite, petit à petit, le besoin a émergé. Après le Design émergeant, on a la « Rétro-émergence »…
Pour donner son retour, Jean-Laurent détaille les techniques simples utilisées lors des rétrospectives. Elles permettent en fait de se congratuler entre membre de l’équipe, sans rendre cela « artificiel » ou génant, mais en permettant naturellement de reconnaître les efforts de chacun. Intéressant, surtout dans la culture Française assez peu friande des congratulations.

Faire de l’Agilité, cela entrainera aussi des frictions. Il y eu quelques échanges mémorables. Le premier P.O est parti, remplacé par une personne qui prendra ses fonctions un peu plus tard. En attendant, l’équipe a pris le rôle de P.O, mais ce ne fut pas l’idéal.

La « Sprint review » (plutôt que le terme « Demo ») permet de se resynchroniser entre membres de l’équipe, et avec le Product Owner. Il est primordial d’avoir un logiciel qui tourne. C’est le bon moment aussi pour s’assurer que le Product Backlog est à jour.

Eric demande si certains font faire la « Demo » par le Product Owner ? Après tout il faut qu’il tire le meilleur parti de cet événement. A peu de moment, le mot Scrum est cité. Eric emploie souvent le mot « Processus Itératif Incrémental« .

Jean-Laurent montre aussi des graphiques en forme de radar, qui montre Spring après Sprint l’évolution des critères de qualité de l’équipe. Sans le savoir, je faisais la même chose il y a 2 ans chez Reuters ! Great minds gets together !

Le sujet des Estimations est intéressant. Jean-Laurent n’essaye pas d’expliquer ce qu’est une estimation, ou ce qu’il faut faire. Il raconte ce qu’ils ont fait, à l’époque.
Au début, l’équipe utilise l’échelle « jour/homme ». Calculé en amont des Sprints, c’est finalement assez mal vécu et utilisé par l’équipe. Cela permet par contre de travailler « à l’ancienne » avec les équipes externes de management, en demande de chiffres.

Ils essayent ensuite une autre approche : une Story est côté en terme de « points de complexité », puis les Tâches de cette Story sont estimées en jour/homme au moment où la Story est dépilée. C’est assez pratique car on attend le dernier moment pour donner un engagement.

Personnellement, j’essaye de rester sur les points de stories. J’ai appelé cela « un nombre de patates » pour vraiment montrer aux développeurs que ce chiffre regroupe une estimation de temps, de risque et de confiance. J’aime bien avoir une unité virtuelle, afin de ne pas tordre ensuite l’agenda avec une notion de jour/homme.

Jean-Laurent raconte l’histoire d’un développeur qui avait pour habitude de suivre à la lettre les estimations en jour. Une tâche est estimée à 2 jours ? Il prend 2 jours. Une autre tâche est estimée à 5 jours ? Il prend 5 jours. Un jour, il voit le développeur entrain de faire autre chose sur son PC. Il lui demande ce qu’il fait. Comme celui-ci a terminé, il attendait en fait d’avoir écoulé les jours pour prendre une tâche suivante sur le tableau…

Nous parlons ensuite du Daily Stand-up Meeting. Dans certaines organisations, cette cérémonie est vécue comme du Reporting. Chaque développeur donne son point d’avancement et le Scrum Master (qui soit-dit en passant n’a rien à faire à cette réunion) met à jour les « reste à faire ».

Eric ré-explique l’utilité et l’organisation du Daily Stand-up meeting. C’est une cérémonie où tous les sens sont en action. La vue, l’ouïe, le toucher pour bouger les post-its. Bien mieux qu’un compte-rendu de réunion sur papier ou une téléconférence par exemple. Son utilité est de synchroniser les activités de chacun au sein de l’équipe. Le Scrum Master doit s’effacer. ll peut noter quelques points à vérifier, mais son rôle est simplement de s’assurer que la réunion a lieu chaque jour. Ensuite, il peut aller prendre un café.

Eric propose de faire le test suivant si vous êtes Scrum Master. Ne venez pas un matin à la réunion. Que se passe-t-il alors ? Est-ce que l’équipe se regroupe ou non ?

Pour terminer, Jean-Laurent balaie quelques points sur la mise en place de méthodes Agiles et certains mots comme « Stress » par exemple. Il reconnaît que depuis l’adoption de Scrum, 3 développeurs sur 10 en 3 ans sont partis. Pour certains, c’est trop violent. Devoir se réunir chaque matin et dire à haute voix : « hier j’ai bien galéré et je n’ai pas codé une ligne » est parfois un exercice insurmontable.

Le Scrum Master a un devoir de communication. Eric enfin termine en nous donnant l’une des utilités de passer en mode « Processus Itératif Incrémental » : ces approches font ressortir les dysfonctionnements dans l’entreprise et dans les équipes. J’évoquais il y a un an et demie l’effet « pétard » de Scrum : il tend à faire exploser les tensions et les points de dysfonctionnement d’une organisation. Et puis il a un effet euphorisant lorsqu’il fonctionne, car avoir une équipe qui délivre un logiciel, sans souffrances, et avec plaisir, c’est un peu le sens de notre métier non ?

Fin du premier billet

J’ai ensuite assisté à deux présentations que je couvrirai demain dans d’autres articles :
- Pierrre Piezzardi d’OCTO Technology sur la question suivante : « Le Lean management peut-il transformer l’entreprise ? »
- DRH, Agile, WTF avec Iva Konstantinovic et Gabriel de Pyxis. Débat très intéressant sur la mise en place de Scrum chez un éditeur dans la finance.

La soirée s’est terminée comme l’an dernier par un repas assis, sur des grandes tables rondes de 8-10 convives. L’occasion de parler recrutement, recherche d’emploi, Git, Spring WebFlow, les vieux développeurs, DVCS et Agilité…

Cette conférence essentiellement francophone, est aussi le point de rendez-vous de nos voisins Suisses, Belges et Canadien comme l’an passé. Avec 280 personnes l’an passé, chaque session fut bien remplie. Les sponsors sont invités à se faire connaître pour aider l’équipe Agile France qui fait un travail remarquable.

Le site Agile France vous donnera tous les détails nécessaires : http://conf.agile-france.org/

Voici les articles publiés sur le Touilleur Express l’an dernier, afin de vous donner un avant-goût de ce qui vous attend :
XP Day France 2009 – journée 1 publié le 2009-05-27 00:22:41
XP Day France 2009 – jour 2 publié le 2009-05-27 20:03:05
XP Day France 2009, Scrum est-il dangereux ? publié le 2009-05-29 21:50:38
XP Day France 2009 – jour 2, Dans la peau du Challenger et Business Value Game publié le 2009-05-31 13:57:32

Les amis, je veux lancer mon navigateur dans 2 jours, pouvoir remplir un questionnaire d’inscription et ensuite recevoir par email mon identifiant et un mot de passe.

Bravo tu viens de faire ta première User Story. Je me permet cependant de revenir sur un mot dans ta phrase qui m’agace : « …dans 2 jours« .

Au nom de quel pouvoir magique penses-tu que 2 jours c’est suffisant ? Et que se passe-t-il si nous pouvons le faire en 1 jour ? Nous irons boire des bières le deuxième jour ?

L’un des premiers principes de Scrum, comme lorsque vous allez chez le médecin, est le suivant : tu t’assois, tu écoutes et tu ne négocies pas le traitement pour ta maladie.

- Euh docteur, je pense que j’ai une angine et qu’il me faut des antibiotiques
- Euh cher patient, je pense que vous êtes un abruti et que si aviez fait 10 ans d’étude, vous seriez en mesure de me dire ce que je dois faire.

Vous devez faire confiance à l’équipe de développement. Et en retour, les développeurs doivent faire un effort de transparence, d’engagement et de communication. Car eux aussi ne sont pas parfaits, loin de là.

Il faut travailler sur le contenu, pas sur son prix
Lorsque vous devez travailler avec une équipe de développement, voici mes conseils : soyez précis dans votre demande. Mettez vous en situation dans quelques jours, et racontez sous la forme d’une histoire ce que vous voulez. Surtout, ne cédez pas à la tentation de proposer une solution technique pour l’instant. Exprimez votre besoin, et faîtes-le en direct devant les développeurs. Voici ce que cela donnerait si je reviens à votre demande de tout à l’heure :

- Les gars, en tant qu’utilisateur anonyme sur notre site, je souhaite remplir le questionnaire d’inscription et recevoir mes identifiants par email
- Combien de questions y-a-t-il ?
- Il y a 8 questions
- Est-ce que tu veux que l’on divise cela sur plusieurs écrans ou est-ce que l’on place les 8 questions à la suite ?
- Celaa change quoi ?
- Si tu divises sur plusieurs écrans, nous devrons sans doute gérer le bouton « Back » du navigateur, cela prendra un peu plus de temps.
- Et bien vu que les questions sont assez complètes, même si cela coûte plus cher je préfère en tant qu’utilisateur, utiliser plusieurs écrans successifs, et même revenir en arrière pour corriger ma saisie
- Est-ce que l’identifiant peut être constitué d’un email seulement ?
- Oui
- Est-ce que tu veux un Captcha pour bloquer les bots qui spamment ?
- Ah oui ! mais pas cette semaine. On est pas en ligne avant 2 mois
- Que faisons-nous avec ce questionnaire ?
- Je veux le stocker dans une base de données et ensuite regarder avec Excel son contenu
- Pour cela, il faut 1 à 2 jours pour définir le modèle et t’installer la base.
- En fait mon besoin pour l’instant c’est que les 30 béta-testeurs puissent s’incrire et tester
- Donc une solution sans base de donnés, avec un fichier texte tabulé sur le serveur, avec un fichier par identifiant créé te suffira ?
- Oui c’est parfait, et je vous recommanderai plus tard la base de données, car on est pas en ligne avant 2 mois
- Ok merci. Allez les gars on vote !

Et l’équipe va vous donner le prix. C’est un devis, non négociable. Si le prix en jours/hommes vous fait peur, c’est que votre perception de la complexité n’est pas la même que celles des développeurs. Il faut absolument rediscuter tout de suite avec les développeurs sur le contenu.

Demandez un devis détaillé
Si vous sentez qu’il y a une zone de flou dans la réponse chiffrée, demandez à détailler les étapes. Essayez de voir s’il est possible de valider une première partie. Restez pragmatique, c’est vous le client. Ne laissez pas non plus les développeurs vous vendre des options dont vous n’avez pas besoin.

Ne vous focalisez pas trop sur les jours/hommes
Je vous pousse un peu plus loin. Attention à la notion de jour/homme. C’est une vision des années 90 de l’informatique. Ce serait penser que 3 développeurs vont plus vite qu’un développeur, ce qui est souvent le cas, mais pas toujours. Cette notion est dépassée. Ce qui est important aujourd’hui, c’est de travailler sur de nouvelles valeurs : l’engagement et la transparence. Et vous allez voir que cela fonctionne. Ce que vous demandez avec un chiffrage, c’est un engagement sur une date. Or le plus important, c’est le contenu.

Comment suivre les jours alors ? et s’assurer que les développeurs bossent ?
Lorsqu’une équipe vous donne un chiffrage en jours ou en nombre de patates, marquez-le et gardez-le sur une feuille de papier, avec les détails de la discussion. Si l’équipe s’est engagée, elle vous livrera ce que vous avez demandé, en temps et en heure. Si vous constatez un décalage, attendez la rétrospective si vous souhaitez en parler. Mais attention : ne revenez pas sur le passé.

Une équipe s’engage pour développer la fonction expliquée ci-dessus en 4 jours. Finalement lors de la rétrospective, elle a travaillé sur ce sujet 2,5 jours. Après enquête, un des développeurs a trouvé une librairie et ils ont donc gagné un peu de temps. Et bien c’est très bien, laissez tranquille les développeurs. Ils ont livré à temps ce que vous aviez demandé, et au lieu de remplir 4 jours en ajoutant d’autres fonctions, ils se sont arrêtés à 2,5 jours. Et croyez-moi, un développeur a vite fait de vous rajouter des trucs qui ne servent à rien.

Ce que je vous demande c’est de faire confiance à l’équipe. Lorsque je vais chez le garagiste, je lui fais confiance. Il me donne un devis, c’est trop cher, je ne vais pas faire réparer ma voiture. Lorsque je suis au restaurant, le menu affiche 19 EUR pour un steak-frite. Je ne vais pas négocier le prix avec le serveur en demandant à retirer 8 frites pour que le steak coûte 15 EUR. Lorsque vous êtes au rayon fruits et légumes, que vous remplissez votre sachet de tomate pour le faire peser, vous faîtes une estimation de la quantité qu’il vous faut. Est-ce que vous revenez prendre une autre tomate après avoir fait peser votre sac ? non. Alors laissez tomber cette mauvaise habitude de négocier le prix d’un développement. Négociez et discutez sur ce qu’il faut faire, et faîtes confiance aux développeurs.

Un mot pour nos amis les développeurs
Les gars, si vous voulez qu’on arrête de vous prendre pour des garagistes, soyez plus transparent. Il faut aussi tenir vos engagements. Si vous annoncez 2 jours, expliquez pourquoi. Il est important d’être honnête et de faire un effort pédagogique afin d’expliquer ce que vous allez faire. Lorsqu’un sujet demande un peu de recherche et que vous n’êtes pas certain, dîtes-le. Il vaut mieux être clair dès le départ. Utilisez le mode interrogatif pour bien comprendre et écouter la demande du client. Par expérience, je me suis rendu compte qu’une discussion de 10 minutes évitait parfois des développements de plusieurs semaines. Un des gros soucis de notre formation d’ingénieur, c’est que l’on a été formé pour être indépendant. Or la vraie vie et le monde informatique vous demande exactement le contraire. On ne vous demande pas d’inventer à chaque fois une nouvelle méthode ou un nouveau framework. On vous demande juste de faire votre boulot, et d’être inventif pour que la solution soit industrialisable, facile à maintenir, bien codée et facile à utiliser.

A vous aussi de vous remettre en question et de faire un effort pédagogique. Si vous vous comportez comme un garagiste, je ne suis pas étonné que votre client négocie avec vous les jours/hommes.

Le secret est bien là : peu importe la méthode, c’est vous qui devez changer si vous souhaitez que votre client change. Et si le client ne change pas, changez de job.

Tout le monde n’est pas prêt à changer.

Je vous laisse, j’ai encore du boulot pour tenir mon engagement.

This article is a French Translation of the original « Scrum doesn’t do anything » wrote by Tobias Mayer. Published with his agreements, thanks again to Tobias for this very good article. Please see : http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/

Tobias Mayer:
« Faire du Scrum » est aussi vide de sens (et impossible) que de créer une instance d’une classe abstraite. Scrum est un cadre pour mettre en avant les dysfonctionnements d’une organisation. Ce n’est pas un processus et il n’est pas prescriptif. Le cadre de base de Scrum, tel que décrit (par exemple) ici et ici, ne fait pas en effet grand chose. Il est, en quelque sorte, un contrat que nous mettons en place entre ceux qui recherchent de la Valeur et ceux qui la construisent. Mais un contrat ne produit rien. Une interface est passive. Il nous faut une implémentation.

Scrum commence à fonctionner quand les gens le comprennent suffisamment pour en créer une mise en application concrète, pour ensuite faire émerger un processus qui leur est propre. Comprendre et respecter Scrum ainsi que l’ensemble des règles permet de s’aligner avec les autres et d’avoir un ensemble commun de valeurs et de principes à partir duquel travailler.

Scrum lui-même peut être considéré comme analogue à un ensemble de règles de jeux. Pensez aux échecs, pensez au football. Les règles sont faciles à apprendre, et les connaitres vous permet de jouer avec les autres. Les règles sont donc les liens qui nous unissent. Mais bien que vous connaissez les règles, ce n’est pas pour autant que vous tirez du plaisir de la partie [d'échec ou de foot]. Vous aurez besoin de jouer pour être impliqué. C’est donc jouer, et pas simplement connaître la règle qui apportera un résultat. D’ailleurs pour bien jouer, vous devez élaborer une stratégie, et dans les jeux d’équipe dont vous avez besoin de développer une relation de confiance et de partage avec les autres.

Dans n’importe quel jeu, dès lors que vous commencez à ne plus suivre les règles, tout s’écroule, et plus personne ne voudra alors jouer avec vous. Et bien c’est exactement la même chose avec Scrum.

Respecter le contrat, les règles, ou dans le langage des logiciels, respecter l’interface, vous permet de créer un processus qui convient à votre contexte – et votre contexte est beaucoup de choses: les gens, l’industrie, des entreprises, une place du marché, un produit, une localisation, une langue, l’environnement physique, la culture, les gens, etc. Il commence et se termine avec les gens. Scrum en fait ne fait rien, ce sont les gens qui font des choses. Le processus Scrum émèrge à travers l’interaction entre les gens, et il sera différent pour chaque organisation et chaque équipe. Et c’est là que les gens trébuchent, trop nombreux à penser que la création de leur propre processus commence par briser les règles. C’est faux ! Faire cela, et vous aurez échoué avant de commencer. (Note de Nicolas : avant d’adapter Scrum, suivez simplement ses principes, votre équipe évoluera ensuite)

La mise en place initiale de Scrum doit s’effectuer avec des paramètres convenus, elle doit être délimitée par des règles. Toutes les méthodes de la Classe abstraite doivent être implémentées, ou la classe ne se compilera pas et ne sera pas exécutée. Si vous essayez de déplacer votre Fou dans un jeu d’échec en ligne droite, alors votre adversaire quittera la table. Si vous voulez ramasser le ballon de football avec les mains sur le terrain et le jeter, vous prendrez un carton rouge.

Le cadre de Scrum est un mécanisme puissant pour mettre en avant les dysfonctionnements d’une organisation et d’une équipe. C’est ce pouvoir même qui pousse les gens à essayer de contourner les règles et à prendre des raccourcis. Ils ne veulent souvent pas regarder. Mais ne pas chercher la cause d’un problème ne fait pas disparaître celui-ci, ou ne réparent pas ce qui est cassé, cela retarde simplement le moment où l’on échouera de manière inévitable. Nous nous en remettons pas pour rien à la valeur de Courage dans Scrum.

Essayer de comparer Scrum à des pratiques d’implémentations comme XP ou de l’artisanat logiciel apporte peu de sens. Chacun de ces mouvements offre par ailleurs d’excellents outils pour mettre en place une pratique solide de Scrum, pour rendre concret l’abstrait. Scrum offre un cadre solide et un rythme implacable pour secouer la poussière des années [sur un projet].

Vous ne pouvez pas « faire du Scrum » mais vous pouvez certainement vous y embarquer, et le plus courageusement vous le faites, plus fort sera votre processus émergeant.  »

FIN DE LA TRADUCTION

Le formulaire F990 est un bilan financier simplifié qui est librement accessible sur le site de la Scrum Alliance. Le document est daté du 11/11/2008, sur l’exercice de l’année 2007. Vous pouvez en avoir une copie sur cette page en cliquant sur ce lien. J’imagine que l’exercice 2008 sera aussi en ligne à la fin de cette année, et qu’il sera possible de retrouver ces chiffres sur Internet aussi.

Avant toute chose, il est important de noter ceci:

[...]The Form 990, entitled “Return of Organization Exempt From Income Tax,” is a report that must be filed each year with the Internal Revenue Service (IRS) by organizations exempt from Federal income taxes under section 501 of the Internal Revenue Code, and whose annual receipts are « normally » more than $25,000 a year. It is an information return and not an income tax return since the organizations that file it do not pay income taxes (except, as explained below, in certain cases an organization may have to pay an “unrelated business income tax”). [1]

L’exercice est clos avec un excédent brut de 899 000 USD. Les recettes sont de 1 494 921 USD pour l’année 2007. Ce chiffre se décompose en 1 053 395 USD de cotisations collectées au près des membres de la Scrum Alliance, 50 000 USD d’aide publique, 13 272 USD d’intérêts bancaires et 381 327 USD de bénéfice des 2 Scrum Gathering organisés en 2007. Le chiffre de 1 053 395 USD de cotisations, bien qu’il paraisse important, n’est pas extraordinaire, rapporté au 64 000 membres de l’association (voir ici). Les dépenses et les frais engagés s’élèvent à 595 099 USD, dont 38 000 USD de frais de voyage, 261 356 de frais de contrats de services, et seulement 130 825 USD reversé pour aider les membres (Page 2, ligne 43-e, Membership support 130 825 USD).
Intéressant non ?

Ce qui est très important à noter, c’est qu’à la page 6, aucuns des membres de l’association ne touche un dollar pour ses heures de travail, précédemment listées à la page 5. Regardez la section V-A « Current Officiers, Directors, Trustees and Key Employees », il est explicitement marqué qu’aucun ticket de présence n’est versé pour leurs heures. Cela ne veut pas dire que leurs frais ne sont pas remboursés, mais que cela ne leur rapporte rien directement.

Les Scrum Gathering ont généré un bénéfice de 381 000 $ en 2007
A la page 13, le bilan financier du Portland Gathering et du London Gathering fait apparaître un bénéfice de 381 327 USD. Le Portland Gathering a reçu 206 800 USD en souscription, a dépensé 73 280, ce qui génère un profit net de 133 520 USD. Le Londong Gathering a reçu 527 066 USD, dépensé 279 259 USD et donc le revenu net est de 247 807 USD. Au total, pour 733 866 USD collectés, et 352 539 USD dépensé, le revenu net est de 381 327 USD. L’organisation des Scrum Gathering génère donc un revenu net d’environ 50% des frais d’inscriptions collectés.

Evidemment tout ceci donne des trucs assez amusants, des débats et surtout un site qui m’a bien fait rire : The Scrum Alliance Jet. C’est est un site parodique qui vous promet de réserver votre Jet privé dès lors que vous aurez passé la Précieuse Certification Scrum.

La Scrum Alliance et les groupes d’utilisateurs Scrum locaux
Mark Levison dans un article sur InfoQ s’inquiétait au début de cette année sur l’agreement que les Scrums User Group doivent signer pour avoir le droit de porter le nom officiel de SUG et l’usage des logos. Le SUG d’Orlando voulait fermer ses portes, un article assez précis relate pour quelles raisons, quelques SUG ne voulaient pas signer d’agreement sans contre-partie, à part le droit d’utiliser le terme Scrum User Group et le logo de l’alliance.

Un avis purement subjectif
Ce que m’inspire ces faits, et là je passe dans le subjectif, c’est que ces chiffres sont assez importants. On peut louer la transparence mais être aussi étonné par les montants collectés. Ce sont des sommes d’argent importantes. Et on ne parle que de 2007.

Alexandre Boutin nous a aussi signalé sur la liste du French SUG une information importante : le 15 septembre dernier Ken Schwaber a annoncé qu’il démissionnait du board de la Scrum Alliance, ainsi que Jim Cundiff (voir la news ici) :

On September 15, Ken Schwaber resigned as President and Chair of the Board of Directors of the Scrum Alliance. Tom Mellor was elected President and Chair of the Board by the Board members. Ken expressed to the Board his intentions to remain active in the Scrum community. The Board expresses its appreciation to Ken for his service and leadership.

Additionally, Jim Cundiff will no longer serve as the Managing Director of the Scrum Alliance effective immediately. Jim will support the transition of his duties to others in the organization and assist as needed until a new managing director is brought aboard. Jim has served the Scrum Alliance very effectively and capably and we thank him for his leadership. A search is underway for a new managing director. The Board anticipates filling the position in the very near future. [...]

Sur le blog de Claude Aubry j’ai vu aussi une référence au départ de Ken Schwaber. Le site www.scrum.org a été lancé par Ken Schwaber, le nom de domaine appartient bien à Ken et le site a été modifié il y a quelques semaines…

Bref il sera important de garder un œil avisé sur la Scrum Alliance dans les mois qui viennent.

Références
http://www.infoq.com/news/2009/05/scrum_alliance_change
http://www.infoq.com/news/2009/04/scrum-alliance-user-group
http://www.aubryconseil.com/post/2007/06/06/241-la-scrum-alliance-me-congratule
http://www.scrumalliancejets.com/
http://www.scrumalliance.org/
Le site de Ken Schwaber
CSP (Certified Scrum Practitioner)

Je vous laisse la découvrir directement sur le site du French SUG : en français ou en anglais.

Bonne lecture et merci à l’ensemble des participants.

Les premier effets de Scrum sont des livraisons plus régulières, un meilleur moral pour l’équipe, une meilleur qualité, la possibilité d’intégrer le changement et une bonne communication avec le Client. C’est le premier effet.
Cet effet finalement est assez salutaire: mettez de l’oxygène dans un aquarium et vos poissons seront contents.

Le deuxième effet qui prend plus de temps, c’est la création de nouvelles Valeurs. Je pense à Transparence, Aider l’autre, Communiquer, Demander de l’aide, etc. La transparence ne vient pas magiquement avec Scrum. Mais les « cérémonies » facilitent ce changement, pour ceux qui le veulent. Le deuxième effet de Scrum ne se mettra en place qu’avec quelqu’un qui fait prendre conscience de ces Valeurs à l’équipe. Cela demande du temps et de l’accompagnement. Je vous le dis clairement : votre formation de Scrum vous aide à répondre aux questions « comment » mais pas aux question « pourquoi« . Il va falloir lire, vous documenter, vous faire aider d’un coach.

Ensuite je me rends compte que pour être Scrum Master, vous ne devez pas être chef de projet. En tant que chef de projet, rien que ce mot « chef » qui est lourd de sens, devient « responsable du projet » lorsque vous passez à Scrum. Vous n’êtes plus chef de rien, votre travail est de faciliter la vie de votre équipe, de s’assurer que l’on suit le framework Scrum, et c’est tout. Le projet est piloté par l’équipe, l’avancement du projet est donné par le framework Scrum, c’est déstabilisant non ?

Vous n’avez plus de rôle de responsable et donc c’est par le leadership que vous serez légitime. Etre Scrum Master, c’est être un capitaine dans une équipe de foot : vous aussi vous allez jouer avec les autres, on vous reconnaît simplement pour votre leadership et votre expérience.
Chez le client pour lequel je travaille aujourd’hui je travaille mon leadership, dans le sens d’aider, faciliter, mettre une bonne ambiance, être là pour aider à résoudre les conflits… ce qui pour moi représente vraiment un nouveau rôle, un nouveau métier. Et franchement, c’est bien plus sympa que de piloter des développeurs à coup de Microsoft Project, en s’excitant pour mettre à jour un diagramme de Gantt…

Si vous envisagez d’utiliser Scrum, prenez le temps de former vos équipes, et prenez 10 fois plus de temps pour trouver un cabinet de conseil ou embaucher un collaborateur afin de piloter vos équipes. Ce métier s’appelle « Coach Agile » pour l’instant, et retenez que ce n’est pas un chef de projet, pas un architecte, c’est un coach.

Si vous pensez que votre responsable ne vous suivra pas, envisagez sérieusement de changer d’équipe, de responsable ou de société. Il est difficile, mais pas impossible, de mettre en place Scrum sans le support de son supérieur hiérarchique.

Rendez-vous le jeudi 18 juin au Scrum World Café

Tout d’abord plantons le décor. Dans une salle de 50 personnes, nous nous asseyons en U, chacun a pris à l’entrée soit une carte verte « Non scrum est une bonne chose » soit une carte rouge « Oui Scrum est dangereux« . Je décide de prendre une carte verte. Un paper-board permet de noter les idées et les points soulevés. Eric et Guillaume seront simplement là comme des arbitres afin que le passage de parole soit respecté. Dans l’assemblée je retrouve toutes les têtes connues de la communauté Agile avec tout d’abord une présence remarqué de Pyxis Technologies : Eric Mignot, Vincent Tencé, Isabelle Therrien et Raphaël Pierquin. David Gageot de Tech4Quant, Jean-Laurent de Morlhon, Emmanuel Gaillot d’OCTO Technology qui dira en préambule « je pense que Scrum est un mot », Yannick Ameur et Sébastien Douche, co-organisateur d’XP Day, bref vous l’aurez compris : pratiquement que des personnes avec une bonne connaissance de Scrum. Voilà pour le décor.

Eric explique que cette session est librement inspirée de la session « Is Scrum Evil » animé par Jeffrey Frerick. Elle sera rejouée en septembre à la conférence CITCON 2009 à Paris le 18 et le 19 septembre, conférence déjà complète co-organisée par Eric.

Il n’y aura pas de débat, nous commençons par exprimer une idée sur « Oui Scrum est dangereux parce que… » appuyé d’arguments afin que le débat soit construit. Quelques suggestions plus tard, Vincent de Pyxis a raison de demander si nous voulons parler du framework Scrum en tant que tel ou de son application. Or il apparaît rapidement que les points levés par les participants se focalisent d’abord sur l’effet Scrum, sur son application et ses effets. Il n’y a pas pour l’instant de critiques sur le contenu de Scrum en tant que tel. Quelqu’un se risque à dire « Scrum est dangereux car il n’y a pas de pratiques logiciels comme la méthode ChlingChling ». Ce à quoi chacun remet Scrum sur son terrain, et on évacue rapidement la question XP vs Scrum.

Voici au fil de l’eau comment s’est déroulée la discussion. Ce qui suit est transcripté en essayant d’être fidèle aux propos de chacun :

DEBUT DES DEBATS

PREMIERE PARTIE: Scrum est dangereux parce que…

Quelqu’un lance le débat en disant que « Scrum est une mauvaise chose car il fragilise les équipes qui le mettent en place par rapport à d’autres, vis à vis du management ». « Scrum est dangereux car lorsque l’on met en place la méthode on a pas le droit à plusieurs essais ». « Le dogmatisme de Scrum est dangereux ». « Scrum est dangereux car le jargon de Scrum peut nous discrediter ». « Scrum est dangereux car le jeu de carte peut nous marginaliser ». « Scrum est dangereux lorsqu’il est appliqué seul sans méthodes logicielles ».

Emmanuel Gaillot demande pour qui Scrum peut-être dangereux ? Eric « Bob » Mignot enchaine avec « Scrum est dangereux car il révèle les incompétents dans une équipe ». Il est dangereux pour les gens qui s’en servent. Scrum est dangereux car il fait partir des gens, il peut casser des équipes. Heureusement que la documentation nous sauve si quelqu’un part… *rires*. L’introduction des méthodes Agile est dangereux, ou amène du danger. Quelqu’un dit que le changement apporte le danger. Toujours pas pour l’instant d’argument sur le contenu de Scrum.

David Gageot explique que Scrum est dangereux car certaines équipes qui ont mis en place avec succès Scrum cherchent ensuite à changer les autres équipes. L’effet viral et l’autopromotion est dangereux, surtout s’il n’est pas accompagné finalement par un coach ou quelqu’un d’assez expérimenté. La radicalisation des équipes est dangereux.

Emmanuel dit que Scrum est dangereux car le chef de projet n’existe plus. Alexandre explique que Scrum est dangereux car il supprimerait certains postes de l’entreprise, et à terme il mettrait en danger l’entreprise. En retour certains expliquent que la structuration MOA/MOE actuelle vient aussi des méthodes classiques. Scrum est dangereux car il empêche l’évolution hiérarchique dans l’entreprise.

Scrum est dangereux car tout repose sur les épaules du Scrum Master et du Product Owner. Scrum est dangereux car les utilisateurs adaptent la méthode à leurs pratiques, ce qui peut entrainer un échec, qui sera attribué… à Scrum. Scrum est dangereux car la responsabilité est diluée, l’engagement à terme est moins clair… On est plus sûr de rien. Tout est flexible…

Emmanuel ouvre la boîte de la certification. « Elle entraine une logique qu’il y a des gens qui savent mieux que d’autres ce qui est bien et et ce qui est pas bien, ce qu’il faut faire, ce qu’il ne faut pas faire. Si on fait bien ce qui est bien on est certifié, si on fait pas bien ce qui n’est pas bien on est pas certifié« . Les personnes certifiées sont un danger pour l’entreprise car elles se comportent comme celles qui ont le savoir, et c’est un danger pour elles-mêmes, elles risquent de se prendre un retour cinglant de la part de l’entreprise. L’autorité de certification est dérangeante. Dans un deuxième point il exprime que la certification payante, le recrutement, nous font penser que l’on tombe dans des arguments marketings, dans une démarche mércantile.
Eric Mignot demande si c’est Scrum en tant que tel ou si c’est l’industrie autour de Scrum qui est dangereux ? Isabelle demande si c’est parce que la certification scrum master est trop facile à obtenir que ce serait un danger ? Eric Mignot replante un jalon afin que le débat continue, en nous réexpliquant Scrum, en expliquant la complémentarité avec XP.
Il tente un coup de force afin que quelqu’un explique Scrum pour que la suite des débats se concentre sur le contenu. Il demande si quelqu’un pense que le Product Backlog est dangereux ? Est-ce que le Sprint est dangereux ? Est-ce que le rôle de Product Owner est dangereux ? Amusant de voir que l’assemblée finalement continue à parler, mais sans suivre la piste proposée par Eric. David Gageot joue le jeu, il dit que le planning meeting est dangereux car le product owner ne vient qu’au début et que l’on ne le reverra qu’à la rétrospective… La rétro fait remonter les problèmes mais c’est dangereux car on ne fait rien après. La démo dans Scrum est dangereux car on ne fait que la démonstration de la fonction, sans montrer le reste du logiciel, en ne passant que sur la démonstration faite au client…

A cet instant, Emmanuel apporte une nouvelle image pour nous résumer quelque part notre discussion : ce ne sont pas les armes qui tuent, ce sont les gens qui s’en servent. Il explique que certains défendent Scrum en disant que ce n’est pas l’outil mais sa mise en place qui est dangereuse. Je trouve l’image courageuse et intéressante à cet instant de la discussion. Je me demande si nous partons pas vers une discussion qui se terminera par la Loi de Godwin.
Il demande pourquoi certains peuvent en faire un jeu de pouvoir, peuvent le tourner à leur sauce, ce qui est vrai. Vincent de Pyxis répond en demandant si finalement, quelque soit les méthodes, celles-ci nous montrent que notre industrie est mauvaise. David reparle de l’effet Matrix, de la pillule bleu et de la pillule rouge, abordé lors de l’inauguration de la soirée du French SUG par Jeff Sutherland. Scrum marcherait pour des équipes de 2 personnes comme 100 personnes… CMMI et PMI arrivent, Scrum est la solution à tout… Bref ce qui est dangereux c’est peut-être plutôt cela d’après David.
Je parle peut-être pour la première fois pour dire que derrière Scrum il y a une industrie, des enjeux, que des gens ont compris que l’on pouvait faire de l’argent. De même comme une arme, il est facile de s’en servir et de faire des dégâts. XP est pour moi un lance-roquette, là où Scrum serait plus facile à introduire. Scrum n’est pas dangereux en lui-même. Le danger c’est nous même résume Vincent. Il demande comment on peut améliorer notre industrie.
Quelqu’un reprend la parole pour dire que Scrum est dangereux, car il est fait pour être facilement adopté, sans peut-être parler des effets secondaires… On a l’image d’un médicament avec ses effets secondaires.
Jean-Laurent dit que Scrum est physiquement dangereux, car il n’y a pas de moments pour souffler comme dans un développement waterfall classique. C’est épuisant
Scrum peut être dangereux car si sa mise en place ne réussit pas, il décrédibilise l’Agilité. On parle de tueur d’Agilité. Une autre idée ensuite, est que le canvas léger mais strict de Scrum empêche l’Agilité, ne laisse peut-être pas la liberté à l’amélioration. Virgile Delécolle rappelle que les projets Scrum qui ont fonctionné ne font pas que du Scrum. Scrum est dangereux car il n’y a pas d’engagements sur le périmètre. Une mauvaise équipe peut livrer peu, la médiocrité ne serait pas punie ?
Quelqu’un se demande comment une entreprise qui utilise Scrum peut être pérenne, s’en sortir financièrement, se battre face à d’autres entreprises sur des appels d’offre. Scrum est dangereux car il y aurait une difficulté pour la contractualisation. Quelqu’un dit qu’il serait plus difficile d’être innovant avec du Scrum. Que l’exploratoire serait plus difficile…
Et la dernière : Scrum est dangereux, car il peut être mal compris ou utilisé incorrectement. Eric Mignot dit « pour moi l’un des seuls points faibles de Scrum, c’est que c’est extrêmement difficile à faire« . Et quelqu’un pour conclure en rigolant « … c’est pour cela qu’il y a une certification ». Scrum révèle beaucoup de choses.

FIN DE LA PREMIERE PARTIE

Après cette première partie, nous enchainons maintenant sur une discussion afin de lister les bonnes choses dans Scrum

DEBUT DE LA DEUXIEME PARTIE : Scrum est une bonne chose car…

Scrum est une bonne chose car c’est un bon moyen pour commencer. Scrum est une bonne chose car il me permet rapidement de mieux connaître mes collègues. Scrum parle aux gens qui ne sont pas développeurs (pas forcément compris). Scrum aide à impliquer les gens. Scrum aide à faire émerger les problèmes, les boulets, les planqués dans une entreprise. Scrum est simple, on ne parle pas de développement logiciel. Quelqu’un dit « quand j’ai voulu former des non-développeurs à XP, cela a été plus difficile qu’avec Scrum. Le package Scrum est plus léger » (euh quelqu’un pour signaler que les 2 n’ont rien à voir s’il vous plaît ? merci). Isabelle propose que Scrum est une bonne chose car il donne des mesures précises sur l’avancement, et qu’il est facile de donner des mesures de cet avancement. Quelqu’un dit « Scrum est une bonne chose car le Waterfall est en recul ». David dit : Scrum est une bonne chose car il a réussit peut-être un peu mieux que XP à faire parler de l’Agilité. Virgile enchaîne: Scrum est une bonne chose car c’est plus facile de vendre des présentations XP. C’est un pied dans la porte pour parler d’XP.

Vincent de Pyxis aborde alors un point intéressant : Scrum est une bonne chose, car plus on aura des implémentations de Scrum qui vont échouer, plus le monde du développement logiciel va réaliser qu’il n’est pas bon. On peut espérer alors que l’on laissera ce job à des gens dont ce sera le métier, et que l’on ne laissera pas des amateurs mettre en place avec les conséquences que l’on sait, la méthode elle-même. Il parle d’amateurisme généralisé. Il faudrait que ce soit une profession…

Quelqu’un dit : Scrum permet d’échouer plus vite. Scrum est une bonne chose car il donne un cadre méthodologique à XP. Eric Mignot est une bonne chose, il favorise les comportements adultes dans les organisations. Scrum permet de montrer à d’autres équipes le résultat du travail des développeurs, grâce à la rétrospective. Emmanuel dit que Scrum ne laisse pas indifférent, il amène les gens à réfléchir sur les autres.

Scrum est une bonne chose car il donne du pouvoir au développeur. Scrum est une bonne chose par rapport à XP car on peut parler facilement des principes de l’Agilité à l’entreprise, aux développeurs. Scrum est une bonne chose car il permet de rendre légitime des pratiques comme les itérations ou les sprints.

Scrum est une bonne chose car il force les développeurs à lever régulièrement la tête de leur clavier, lors des rétrospectives, des réunions, des sprints meetings. Scrum c’est bien car cela évite de coder des choses inutiles. Scrum c’est bien car cela augmente la motivation des équipes. Les gens sont plus heureux.
Eric Mignot explique que des gens essayent le Scrum et reprenne du plaisir à bosser.
Vincent dit c’est une bonne chose car ce n’est pas une méthodologie. Donc cela ne donne pas l’illusion qu’il existerait une bonne recette pour développer du logiciel. On parle tout le temps de « méthodologie » pour Scrum, ce qui n’est pas vrai. Cela va plutôt nous permettre de nous tourner vers nous même pour trouver la solution, plutôt que de se baser sur une méthode pour résoudre un problème.

Scrum fournit des outils de communication, il permet de donner de la transparence et de l’honnêteté. Xavier dit « on jouera carte sur table ».
David Gageot: Scrum donne du rythme. Quelqu’un dit : Scrum est plus humain. Isabelle : Scrum donne le contrôle sur le projet au client. David explique que la notion de focus sur le « produit » est important. On est là pour développer quelque chose. Scrum est une bonne chose grâce au rôle du Product Owner. La notion de Product Backlog, de Product Owner est plus fort. Emmanuel rappelle dans XP la notion de Client qui existe déjà. Mais la notion de « responsable de produit » est plus forte dans Scrum…

Scrum est une bonne chose car il permet d’exploiter mieux l’humain. Les tableaux et la transparence permettent de voir l’avancement du projet. Quelqu’un explique que Scrum est une bonne chose car il est facile de trouver de la documentation et des ressources. Les retours sur expérience. Eric « Bob » dit que Scrum est une bonne chose car il permet de retrouver le plaisir qu’il avait à coder lorsqu’il était jeune.
Scrum est une bonne chose car il remet le bon sens au premier rang. Scrum est une bonne chose car il permet de créer des communautés. Yannick explique que Scrum est une bonne chose car on parle d’heure idéale, pas de 8h bête par jour. C’est une bonne chose encore une fois car cela force à nous réflechir

FIN DE LA DEUXIEME PARTIE

Passons à la synthèse : Eric demande si les personnes avec une carte rouge en main veulent prendre une carte verte, ou inversement. Les débats durent depuis 1h11…

La synthèse

Vincent explique que Scrum est une voie pour lui. Il se demande s’il y a du dogmatisme ? il ne sait pas. David a changé, il a bien aimé entendre que les gens ont conscience que le danger de Scrum est que ce n’est pas qu’un mot, qu’il n’est pas une recette magique, qu’il est difficile, bref que les gens sont réalistes sur Scrum.
Scrum n’est pas qu’une partie de l’Agilité, Jean-Laurent explique que pour l’instant il n’a pas trouvé mieux pour son besoin, dans son expérience professionnelle. En attendant peut-être de trouver mieux demain.
Michel fait une petite synthèse : Scrum peut être dangereux par la radicalisation des équipes (qui n’intervient pas tout le temps) et la certification (bien que finalement peu de gens savent en quoi elle consiste, que l’on confond CSM et CSP… mais bon passons). Il a les qualités de ses défauts et inversement… Il apporte de la transparence, ce qui peut être bien ou pas selon le point de vue. Virgile rebondit pour expliquer que chacun doit choisir sa voie, il permet d’être plus efficace, puis provoque un peu en utilisant l’image de machine-outil, de l’hyper-productivité. Ce qui le dérange avec Scrum c’est que au delà de son côté un petit peu humain, auto-organisé, il ne creuse pas le sujet « auto-organisation ». Par ailleurs, ce qui le dérange beaucoup, c’est qu’il est mis en place par des structures qui sont déjà dans une logique de rentabilisation de nos ressources humaines machines outils. Sur la chaine de production on se retrouve très exposé. C’est une méthode qui demande à la machine outil salarié de travailler en transparence, en binômage, à faire remonter toutes ses difficultés, avec une organisation derrière qui reste très traditionnelle, exploitation, rentabilité…
Note de Nicolas: soit c’est de la provocation intelligente, soit c’est de l’extrémisme qui montre une profonde méconnaissance de notre métier… Je suis effaré des propos, comme si la recherche de l’amélioration pouvait être critiquable, comme si la recherche de la performance, du plaisir de travailler intelligemment était critiquable… Monsieur Virgile je ne vous ai pas compris.

David explique qu’il y a beaucoup de business autour de Scrum. Vouloir embrasser toutes les équipes, c’est dangereux. Il y a toujours une phase exploratoire, mais nous devrions peut-être continuer à chercher, à ne pas s’arrêter à Scrum comme la solution. Il y aura sans doutes d’autres méthodes, d’autres approches plus tard.
Emmanuel enfin s’interroge sur la traduction de la réunion « Is scrum evil? » en anglais se traduit par diabolique, mais Eric Lefevre explique que la démarche était de construire une discussion, pas d’apporter une démarche de valeur.

Il faut accepter que d’autres personnes soient différentes, qu’elles préferent XP, qu’elles préferent du Waterfall, il faut avoir une tolérance sur les autres. L’essentiel est de se sentir bien.

Et pour terminer je me lance: Scrum est une bonne chose car cela va nous faire prendre conscience que dans la vie de l’entreprise, et dans le développement logiciel, notre oeil d’ingénieur qui pense avoir la vérité vraie, je pense à XP, je pense que l’on s’est planté. Et Scrum pour moi c’est un peu l’étincelle qui est entrain de nous faire prendre conscience que notre métier a besoin de personnes qui travaillent avec de la valeur humaine, de l’humanisme car Scrum c’est bcp sur la communication. C’est entrain de nous dire que ce que vous faîtes depuis 15-20 ans c’est quelque chose qui a été structuré historiquement, et Scrum réussit à faire ce que d’autres méthodes jusqu’à preuve du contraire, n’ont pas réussi : faire parler de l’Agilité, nous faire prendre conscience que l’industrie logicielle n’est pas parfaite.

Vincent explique que l’on a relativement peu confiance en l’humain. Il n’y a jamais eu pourtant de tentatives de comparer XP à Scrum, et il est marrant de constater comment le débat s’est en partie organisé face à XP. Quelqu’un dit que même pas 25% des entreprises réussiront avec Scrum.

Eric Mignot dit enfin qu’il pense qu’il y a un fantasme par rapport à la formation certifiante. Il demande « Pourquoi voulez-vous faire du Scrum ? » Les gens vont dire « pour régler tel et tel problème ». Eric dit « mais si tu connais le problème… pourquoi as-tu besoin de Scrum alors pour le résoudre ? ».
Vincent de Pyxis explique que l’origine de la certification est de crédibiliser la démarche par rapport à du Waterfall. Que dans les faits, 85% de ce que les gens vont apprendre lors de la formation sera oublié s’ils ne travaillent pas par la suite simplement en lisant un livre ou deux de Ken Schwaber. Je disais une fois à quelqu’un : Scrum c’est pas ta mère qui te fait passer ton Bac mon coco. C’est ensuite pour que tu fasses des études et que tu bosses, si vraiment tu veux t’impliquer et mettre en place Scrum dans ton équipe.

Eric Lefevre-Ardant propose pour terminer un livre :
« Artisanal Retro-Futurism
X
Team-Scale Anarcho Syndicalism »
Brian Marick

Ma petite conclusion et mon avis à moi que j’ai…
Tout d’abord sur les personnes présentes : les équipes de Pyxis par leur expérience ont conservé le débat sur le fond, chacun a exprimé ses points de vues, quelques remarques de personnes de la communauté purement XP pour pimenter, des interventions intéressantes de David qui avec sa carte rouge a amené Scrum sur la table d’examen, bref je resors de là avec de nouvelles idées et une prise de conscience. Vincent de Pyxis qui demande si ce n’est pas l’industrie qui est malade, Eric « Bob » Mignot assis à côté d’Emmanuel Gaillot, deux acteurs de théâtre c’était marrant.
Bravo à Eric et Guillaume qui ont piloté la séance, en laissant chacun s’exprimer tout en freinant les emballages de certains, c’était un moment agréable.

Une réflexion sur la certification pour faire avancer le débat:

Est-ce que la certification Spring est suffisante pour se déclarer prêt à coder une application d’entreprise dès le lendemain ? non. Elle est une garantie que vous avez reçu une formation par une personne habilitée et pas par un charlatan. Car il faut savoir que pour être CSP (certified scrum practionner) et formateur Scrum, c’est un sacré boulot, une reconnaissance par d’autres CSP, un ticket d’entrée à 7000 $ par an, ce qui fait que les gens qui sont formateur Scrum sont des gens qui DOIVENT en faire à plein temps, et qui doivent aussi être sur le terrain, en faisant de l’accompagnement d’équipe. Avez-vous déjà vu un professeur de fac à vos côtés le premier jour de votre premier boulot pour vous aider ? non. Et pourtant vous avez eu ce sacré diplôme qui vous a rendu « ingénieur » ou autre…
Le côté mercantile fait peur car aussi c’est un domaine que certains ne connaissent pas. Avez-vous déjà discuté avec des gens qui font des certifications sur des progiciels ? Pensez-vous que la certification Microsoft c’est bien ?
Il y a des gens qui savent mieux que d’autres, qui travaillent pour être formateur, afin que d’autres gens qui ne savent pas puissent apprendre. Ensuite il y a des gens, de l’humain. Il y a des vendeurs d’armes, qui savent que l’entreprise va se blesser. Il y a des vendeurs de valeur, d’engagement et de plaisir, qui viennent dans des équipes pour reconstruire un capital humain.
Prendre conscience que le système actuel peut être amélioré c’est une chose. Prendre ensuite les bons interlocuteurs pour progresser, c’est une autre affaire.

Mon avis très personnel est que nous manquons un peu d’objectivité sur Scrum. Nous devrions parler des effets secondaires à nos clients. Pour autant, n’est-ce pas de notre responsabilité de tenter de changer ? Il y a des gens qui sont planqués, qui végètent et qui s’éclatent dans leurs coins. Et puis il y a d’autres gens qui ne supportent pas un système de développement basé sur des techniques vieilles de 15-20 ans, où personne n’a cherché à comprendre l’absurdité de nos comportements. Il y a ceux qui sont frustrés car c’est l’équipe de foot Scrum qui en ce moment se la joue plutôt que son équipe XP.

A XP Day j’ai discuté avec beaucoup de personnes du métier ou des chefs de projets. Tous m’ont dit que sans Scrum ils n’auraient pas fait connaissance avec l’Agilité, puis le Lean, puis XP, bref le changement. Alors que Scrum soit le pont vers un autre monde, c’est quand même une bonne chose.

Je vous donne rendez-vous le jeudi 18 juin à partir de 19h00 à l’EPITA à Paris pour participer à un WorldCafe sur Scrum, organisé par le French SUG. Si vous voulez rencontrer des gens qui font du Scrum, n’hésitez pas à venir en vous inscrivant sur le site MeetUp du French SUG.

Resources
Eric a mit en ligne les photos de cette séance et de la journée
Merci à Eric et Guillaume.

Enfin vous retrouverez l’enregistrement complet de la session sur le podcast, si vous voulez revivre les 1h22 de la séance, avec 45mn pour la première partie…

A propos d’Agilité, préparez vos lecteurs RSS ! Je serai aux XP Days lundi et mardi prochain. J’espère vous faire partager ces 2 jours qui se passeront à Paris via Twitter tout d’abord, puis via le blog. Au programme regardez ce que j’ai sur le Menu. Tout d’abord je laisserai Eric « Bob » Mignot faire une présentation de Scrum avec Eric Seguier, j’irai peut-être voir « Un projet extrêmement ambitieux et flou, utilisant les technos les plus récentes, distribué sur plusieurs continents… vous savez » par Isabelle Therrien et Érik Lebel mais la session « Blanche Neige » me tente bien aussi… Les présentations sur Lean et Kanban m’intéressent beaucoup. A ce propos je vous recommande de lire « Kanban vs Scrum » d’Henrik Kniberg. Attention c’est le PDF qu’il faut lire, pas l’article du blog. On assistera aussi à la présentation « Product Owner, qui es-tu ? que fais-tu ? » de Guillaume Carré et de Guillaume Bodet de Xebia France.

Mais l’une des participations à laquelle je serai sans fautes c’est la présentation d’Eric Lefevre-Ardant : « Scrum est-il dangereux ?« . J’ai rencontré Eric à l’occasion du 4ème BarCamp, il m’a expliqué l’objectif de cette session qui sera de faire une autocritique sur la mise en place de Scrum. L’idée trouve ses sources à la dernière CITCON « Is Scrum Evil? » qui tire son contenu d’un article de James Shore très cité dans la communauté Agile: « The Decline and fall of Agile« . Nous avons discuté ensemble sur la traduction car evil pouvant se traduire par « dangereux » ou « mauvais ».
Au delà du contenu qui sera animé par Eric, du côté des spectateurs je pense que nous aurons l’occasion de voir quelques stéréotypes : les Scrumistes aveugles qui pensent que Scrum se suffit à lui-même, les XPiens extrémistes qui pensent qu’XP peut répondre à l’ensemble des besoins, etc. Ca va être sport !

Pour terminer il y a un article sur le Touilleur dont je suis assez content, qui m’a demandé pas mal de boulot : « Les origines de Scrum« . Si vous voulez le relire, il est encore en rayon dans la section « Scrum » du Touilleur Express. A propos enfin du bashing sur Scrum, à la page People j’ai aussi un bon numéro avec « Scrum c’est fini ou le sujet People de janvier« .

N’oubliez pas enfin de remplir le questionnaire sur l’Agilité sur le site du French SUG.