Comprendre le besoin

Ce billet fait suite au précédent que j’ai posté, « Pourquoi veut-on travailler en agile? », et il va nous permettre de mieux comprendre le besoin de nos utilisateurs.

Notre priorité en tant qu’équipe Scrum (ou Agile) est d’apporter de la valeur à nos utilisateurs. Et pour atteindre cet objectif, il nous faut commencer par comprendre leurs besoins.

Mais cet exercice n’est pas toujours facile. Ce n’est pas parce que l’un de vos utilisateurs commence sa phrase par « je veux… » ou « j’ai besoin de… » qu’il vous exprime forcément son vrai besoin. Loin de là!

Développer une solution logicielle à partir d’un mauvais besoin vous amènera sûrement à livrer quelque chose qui n’apporte pas de la valeur à vos utilisateurs.

Je vous propose donc, dans ce billet, que l’on étudie ensemble quelques cas communs de problèmes liés à la collecte du besoin.

Henry Ford et la Ford T

Pour commencer, je vous propose l’étude d’une citation du très célèbre Henry Ford :

Si j’avais demandé aux gens ce dont ils ont besoin, ils auraient répondu des chevaux plus rapides.

Nous savons tous qu’il n’a jamais vendu de chevaux à ses clients, par contre il leur a vendu la célèbre Ford T. Pourquoi? Parce qu’il y avait parfaitement compris le besoin de ses clients! Mais quel était donc le vrai besoin de ces derniers?

Pour comprendre ce fameux besoin, nous pourrions imaginer la conversation suivante entre Henry Ford et son client :

H.F. : « Pourquoi as-tu besoin d’un cheval? »

Le client : « Pour pouvoir me déplacer. »

H.F. : « Si tu as besoin de te déplacer, pourquoi n’utilises-tu pas tes jambes? »

Le client : « Parce que j’ai besoin de me déplacer rapidement et sur de longue distance. »

H.F. : « OK, alors pourquoi ne prends-tu pas simplement un vélo? »

Le client : « Parce que je veux me déplacer sans effort. »

H.F. : « Donc ton besoin n’est pas d’avoir un cheval plus rapide, mais de pouvoir te déplacer rapidement sur de longue distance et sans effort. Est-ce bien ça? »

Le client : « Oui. »

Donc le vrai besoin du client d’Henry Ford est de pouvoir se déplacer rapidement sur de longue distance et sans effort. Besoin que comble la Ford T avec une vitesse maximale de 70 km/h et une autonomie de plus de 250 km. Mieux qu’un cheval, non ?

C’est l’histoire d’une balançoire

Il arrive parfois que le client sache exactement ce dont il a besoin, mais il n’est malheureusement pas toujours capable de nous le transmettre, de nous le décrire, et cela provoque des confusions lors de la livraison de la solution à son besoin.

Pour illustrer ceci je vous invite à regarder l’image suivante qui conte l’histoire (très connue) d’un client qui veut se faire fabriquer une balançoire :

balancoire

Nous pouvons voir sur cette image la belle différence entre le besoin exprimé/décrit par le client (première vignette) et la solution qui l’aurait simplement satisfait (dernière vignette).

De plus, dès la deuxième vignette, nous nous apercevons qu’il y a une différence entre ce qu’a décrit le client et ce qu’a compris le chef de projet. D’où la difficulté à pouvoir livrer une balançoire qui pourrait satisfaire le client.

D’ailleurs, cela nous amène à un autre problème que l’on peut observer dans certaines entreprises ou organisations…

Du bruit sur la ligne 

Nous pouvons aussi appeler ça le syndrome du « téléphone arabe ».

Cela se produit lorsqu’il y a trop d’intervenants entre le client et l’équipe de réalisation. L’information provenant du client se corrompt à chaque fois qu’elle passe par un intervenant qui doit la communiquer à l’intervenant suivant. Cette « corruption » de l’information entraine fatalement une mauvaise compréhension du besoin du client se traduisant dans la livraison d’une solution logicielle qui n’apporte aucune valeur à nos utilisateurs.

Il existe bien entendu d’autres raisons pour lesquelles le besoin utilisateur n’est pas bien compris, et donc pas satisfait, mais cela reste en dehors de la portée de ce modeste billet.

Mais qui peut donc nous sauver de ces situations? Qui va nous permettre de comprendre le besoin des utilisateurs dans un contexte Agile?

Pourquoi veut-on travailler en agile ?

Ce billet est le premier d’une longue série, il a été rédigé en parallèle d’une présentation que j’ai préparée pour le lancement d’une communauté de pratique agile au sein d’une organisation.
J’ai choisi pour cette occasion de faire une présentation autour du besoin.
Avant de commencer ma présentation j’ai posé la question suivante à l’auditoire : « Pourquoi veut-on travailler en agile ? ».

Depuis plus de huit ans maintenant, l’entreprise VersionOne nous partage les résultats de son étude annuelle sur l’état de l’art de l’agilité. Dans sa huitième édition, publiée cette année, les personnes sondées avaient dû répondre à la question : « Pourquoi l’agilité ? » (« Why Agile ? »). Pour répondre à cette question, les participants étaient invités à noter treize critères en fonction de l’importance qu’ils leur accordaient (très important, important, peu important ou pas du tout important). Les quatre critères les mieux noté furent :

  1. Accélérer les délais de mise sur le marché (livrer plus vite)
  2. Gérer les changements de priorités
  3. Un meilleur alignement entre les TIs et les affaires
  4. Augmenter la productivité

Le premier et le quatrième critère m’interpellent d’une certaine manière. Le besoin de livrer plus vite un grand nombre de nouvelles fonctionnalités à nos clients et/ou utilisateurs est totalement louable. Mais si leurs besoins ne sont pas compris, nous nous retrouvons à leur livrer tout simplement un grand nombre de fonctionnalités qui leurs sont inutiles, mais nous le faisons plus rapidement qu’avant. Je vous invite d’ailleurs à lire le billet de Louis-Philippe Carignan intitulé « Agile, is it just a delivery mechanism ? ».

Revoyons ensemble le premier principe du Manifeste Agile :

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

J’ai délibérément choisi de mettre en valeur le terme « valuable software » car, pour moi, c’est l’essence même de l’agilité : livrer des produits qui apportent de la valeur à nos utilisateurs.

Donc, dit autrement, vouloir livrer plus vite ou en plus grand nombre des fonctionnalités qui n’apportent rien à vos utilisateurs, et qui par conséquent ne répondent pas à leurs besoins, ce n’est pas faire de l’agilité.

Mais comment apporte-t-on de la valeur à nos utilisateurs ? C’est que nous verrons dans les prochains billets !

Livre : Agile Software Requirements

La mise à l’échelle de l’agilité est devenue une nécessité pour les entreprises et les organisations qui veulent profiter pleinement des bénéfices de l’agilité. Pour répondre à ce besoin plusieurs modèles ont fait leur apparition sur le marché, dont les plus connus à ce jour sont Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) et Large Scale Scrum (LeSS). Parmi ces différents modèles j’ai fait le choix de commencer par étudier SAFe et, dans ce sens, je me suis donc procuré le livre qui semble supporter ce modèle, Agile Software Requirements de Dean Leffingwell.

SAFe est-il vraiment agile ?

C’est la première question que je me suis posé lorsque j’ai vu pour la première fois le poster SAFe avec ses 3 couches : « Portfolio », « Program » et « Team ».

Avant de continuer, un petit rappel de la première des valeurs du manifeste Agile :

Individuals and interactions over processes and tools

De là mon sentiment, suite à la lecture de ce livre, que SAFe n’est pas si Agile que ça car le livre traite plus des processus et des outils que des personnes et de leurs interactions.

Attention, je ne remets pas en cause les idées de SAFe, qui sont tout à fait louables, car le besoin de coordination dans la gestion des différents projets d’une entreprise est une nécessité. Mais doit-on (ou peut-on) pour autant appliquer ce modèle à grande échelle dans de grandes entreprises ou organisations ?

Il me semble, par exemple, que les responsabilités que perd le Product Owner au profit du Product Management peut-être problématique pour certains projets:

  • « Augmentation » du nombre d’intervenant entre le client (et/ou utilisateur) et l’équipe de réalisation (l’information sur le besoin risque d’être « parasité »)
  • Risque de réduire le sentiment d’engagement de la part de l’équipe de réalisation (effet cascade)
  • Le PO qui ne porte plus la responsabilité de la vision du produit (re)devient finalement un chargé de projet

Cela me rappelle une expérience dans une structure où le rôle du Product Management était tenu par le marketing et le rôle de Product Owner était par ma chef de projet. Tous les « besoins » étaient commandés par le marketing et seuls ces derniers devaient être satisfait. Mais nous avons eu une fois l’opportunité de travailler sans le marketing, juste avec la vision et l’expérience de ma chef, et c’est cette fois-ci que nous avons sorti le meilleur produit. Les clients et les utilisateurs étaient très satisfait par ce nouveau produit même si celui-ci changeait radicalement d’approche par rapport au précédent.

Ce-ci est peut-être une exception mais je ne pense pas qu’il faille pour autant étouffer les projets avec des structures trop rigides ou non adaptées au contexte de certains projets juste pour des raisons d’alignement organisationnel.

Masse critique

La « masse critique » est un terme que j’emprunte au domaine de la physique pour parler d’une structure organisationnelle ayant atteint une certaine taille (que je n’ai pas quantifié) qui rend impossible la mise en place d’un processus (ou méthode) de travail unique au sein de celle-ci.

D’ailleurs dans les grandes structures organisationnelles nous observons souvent des différences culturelles entre les différentes directions, voir même dans les différents services de ces directions, même quand celles-ci vous assure que tout le monde utilise les mêmes pratiques et les mêmes règles.

Tenter de changer les cultures de ces différents services et/ou directions peut-être parfois très coûteux par rapport aux bénéfices réels tirer d’un alignement culturel et organisationnel.

Dan Cobley reprenait un principe physique dans sa présentation « What physics taught me about marketing » qui peut, je pense, aussi s’appliquer à un changement organisationnel :

For a larger masse it require more force to change it direction

Donc, au lieu de se lancer dans une quête perdue d’avance vers le grand alignement, les grandes organisations pourraient s’inspirer du proverbe « Diviser pour mieux régner gérer » et ainsi offrir une certaine autonomie aux différentes unités qui les composent.

Dans le livre How Google Test Software les auteurs nous apprennent que chaque unité de Google a sa propre façon de réaliser les essais des applications qu’elle développe. Il semble que les tentatives d’alignement sur les pratiques des tests ont plus débouché sur des partages de bonnes pratiques que sur des règles formelles pour l’ensemble de l’entreprise.

On peut donc se poser la question suivante : « Est-il donc bon de mettre en place SAFe à grande échelle dans de grandes organisations ? ».

De bonnes choses tout de même 

Comme je l’ai dit plus tôt, tout n’est pas mauvais dans le modèle SAFe. D’ailleurs j’ai eu une intéressante conversation avec un conférencier certifié SAFe, suite à sa présentation. Il s’est trouvé que lui aussi est un grand de ce qui se fait chez Spotify au niveau de l’agilité (lire l’excellente publication Scaling Agile @ Spotify). Pour lui il n’y a aucune obligation à adopter le modèle dans son ensemble, on peut y piocher les éléments que nous trouvons utiles et pertinents dans notre contexte.

C’est un peu ce que je fais aujourd’hui en m’inspirant de l’événement Release Planning que nous propose SAFe pour l’appliquer au niveau du service dans lequel je travaille. Je ne pense pas que cet événement soit une idée originale de l’auteur mais l’adoption d’une bonne pratique qui a su émerger dans la communauté Agile.

Les bénéfices que je recherche avec le Release Planning sont :

  • une meilleure vue sur les interdépendances des projets des différentes équipes qui nous permettra de mieux gérer nos livraisons
  • une meilleure compréhension de la vision du service de la part des différentes parties par leurs participations à la planification des livraison, ce qui permettra aussi de renforcer le sentiment d’engagement chez ces dernières

En conclusion un livre dont je recommande la lecture même si je ne suis pas toujours d’accord avec le contenu (surtout celui de la page 52). 

Une mêlée quotidienne bien difficile

Cela fait maintenant presque un an et demi que je suis le Scrum Master de la même équipe, et durant cette période la composition de cette dernière a bien changé. Elle est maintenant composée d’un noyau de 4 personnes travaillant ensemble depuis plus de 2 ans auquel ce sont ajoutés 3 nouveaux membres (externes) durant les 6 derniers mois.

Avec ces changements j’ai dû enseigner aux nouveaux membres les valeurs de Scrum et de l’agilité afin de les aider à s’intégrer à l’équipe. Et pendant quelques itérations il m’a fallu rappeler les objectifs de la mêlée quotidienne afin que celle-ci ne déborde pas.

Mais il y a quelques jours de cela j’ai vécu la mêlée la plus difficile depuis que je suis le Scrum Master de cette équipe, j’ai été confronté à un vrai manque de discipline de la part de certains de mes coéquipiers. Certains se permettaient de discuter entre eux pendant qu’un de leurs coéquipiers répondait aux 3 questions, et il m’a été difficile d’obtenir leur attention sans monter le ton. Mais le meilleur m’a été réservé pour la fin de la mêlée lorsque l’un des derniers externes à avoir intégré l’équipe s’est mis à donner des ordres/tâches à un autre membre, je suis malheureusement resté sans voix…

Les limites du rôle de Scrum Master

Pour rappel, le Scrum Master n’est pas un chef d’équipe mais plutôt un facilitateur, un guide, voir un coach pour l’équipe. Il est là pour accompagner l’équipe dans son apprentissage de Scrum. Il est là pour conseiller l’équipe et l’aider à s’améliorer dans ses pratiques de développement. Il est là pour retirer les obstacles qui empêchent l’équipe d’être efficace. Mais en aucun cas il peut donner des ordres à l’équipe.

Dans ce contexte j’ai 2 possibilités qui s’offrent à moi :

  • notifier la gestion sur le problème de discipline dans l’équipe,
  • réexpliquer une énième fois les principes de la mêlée quotidienne lors de la prochaine mêlée.

Personnellement je vais privilégier la seconde approche et garder la première pour les situations extrêmes. En effet, je trouve que la première solution a un côté infantilisant et qu’elle risque, d’une certaine manière, de briser la confiance que les membres de l’équipe ont en moi.

Que ce soit dans le guide Scrum ou dans les 12 principes agiles il est fait mention d’équipes auto-organisées. Mais pour avoir une équipe auto-organisée il nécessaire, à mon avis, d’avoir des membres auto-disciplinés et respectueux de leurs coéquipiers.

The Year Without Pants

ImageJ’avais vu passer ce livre lors de sa sortie en septembre 2013 mais je ne lui avais pas prêté une grande attention à cette époque car j’avais déjà une bonne pile de livres sur mon bureau et sur ma table de chevet.

Il y a quelques semaines je lisais le billet « WHAT IF MANAGERS DIDN’T GET PAID MORE? » sur le blogue de Scott Berkun et là je me suis rappelé que son dernier livre m’avait tout de même intrigué à sa sortie (c’est sûrement du à la couverture 😉 ). Je me le suis donc procuré.

De quoi ça parle ?

En 2010, Matt Mullenweg (WordPress.com) approche Scott Berkun (auteur, conférencier et ancien de Microsoft) et lui propose de venir travailler pour son entreprise Automattic. Matt Mullenweg lui offre alors de prendre en charge une équipe de développeur. Une première pour cette entreprise. Cette équipe, tout comme la grande majorité des équipes travaillant pour Automattic, à pour particularité d’avoir ses membres répartis sur l’ensemble du globe.

Scott Berkun nous livre donc l’aventure qu’il a vécu durant son année passée chez Automattic dans un contexte de gestion très différent de ce qu’il a connu auparavant.

L’héritage du monde du logiciel libre

Pour comprendre le fonctionnement de la société Automattic il faut revenir aux origines du moteur de blogue WordPress.

En 2002, Matt Mullenweg utilisait un logiciel nommé Cafelog (aussi connu sous le nom de b2) pour publier ses photos sur son site d’alors photomatt.net. Mais il trouva rapidement des limites à ce logiciel et malheureusement ce dernier n’était plus entretenu par son principale développeur, Michel Valdrighi.

Cafelog étant un logiciel libre, Matt décida de partir un nouveau projet à partir du code source de ce dernier. Et le 27 mai 2003 Matt publia, avec l’aide de Mike Little, la première version publique de WordPress. Ils seront, petit à petit, rejoint par d’autres développeurs intéressés par le projet, dont Michel Valdrighi.

Vers la fin de l’année 2005 Matt Mullenweg fonde Automattic, l’entreprise derrière WordPress.com, afin d’offrir des services d’hébergement pour le moteur de blogue WordPress (ce dernier reste sous licence GNU GPL). Il propose alors aux principaux contributeurs de le rejoindre dans ce nouveau projet.

La culture de l’entreprise Automattic hérite donc de la philosophie du monde du logiciel libre sur plusieurs aspects.

« Culture Always Wins »

C’est le titre du chapitre 4 de ce livre, celui qui m’a le plus marqué par son contenu et les idées que je partage avec l’auteur. L’extrait suivant est d’ailleurs un bon message pour beaucoup de gestionnaires :

A great fallacy born from the failure to study culture is the assumption that you can take a practice from one culture and simply jam it into another and expect similar results.

J’ai pu observer ce genre de comportement dans mes précédentes expériences. On allait chercher un gestionnaire qui avait réussi à implanter le Lean ou l’agilité dans son organisation et on lui demandait de refaire son « tour de magie » dans une autre entreprise, dans un autre contexte et surtout dans une autre culture. Je vous laisse deviner le résultat…

Je ne pense pas qu’une entreprise tenterait de recopier le modèle d’Automattic avec des équipes dont les membres sont répartis sur l’ensemble de la planète et qui travaillent depuis chez eux. D’ailleurs Yahoo! est récemment revenu sur sa politique de travail à distance. Son succès, Automattic le doit à sa politique de recrutement qui lui a permis de construire et d’entretenir sa culture autour de gens engagés et partageant les valeurs de l’entreprise.

Un dernier extrait pour finir

Product creators are the true talent of any corporation, especially one claiming to bet on innovation. The other roles don’t create products and should be there to serve those who do.

Bonne lecture !


Quelques liens :

  1. Memories from the #FutureOfWork
  2. The Year Without Pants: An interview with author Scott Berkun

C’est drôle et triste à la fois

Je m’intéresse beaucoup aux retours d’expérience d’entreprises ou d’organisations sur leurs passages à l’agilité, que ce soit au niveau des équipes de développement ou de l’entreprise au complet.

Lundi dernier, l’association Agile Québec nous proposait d’assister à la présentation de Guillaume Soyer intitulée « Transition agile réussie en grande entreprise« . C’était très intéressant et très instructif malgré le fait que cette transition n’ait concerné qu’une unité de R&D de 45 personnes au sein d’un grand groupe.

Personnellement j’ai beaucoup ri pendant cette présentation, pas parce que Guillaume était drôle mais à cause de mes expériences passées. En effet, les difficultés qu’a rencontré cette unité de R&D lors de sa transition à l’agilité me rappellent celles que j’ai observé dans d’autres entreprises ou organisations. J’y ai donc retrouvé des choix et étapes (naïfs) qui avaient aussi échoué ailleurs et cela m’a fait rire d’une certaine manière.

Tout cela serait uniquement drôle si malheureusement on n’observait pas de nouvelles entreprises ou organisations démarrer leurs transitions agile en passant par ces mêmes choix et étapes voués à l’échec. Comme si depuis la publication en 2001 du manifeste agile aucune entreprise n’avait tenté de passer à l’agilité. Comme si Internet était vide de tout retour d’expérience (réussi ou non) d’autres entreprises ayant tentés une transition vers l’agilité.

Bref, c’est triste…


  1. Retour d’expérience d’un projet Agile SNCF – 2009
  2. Six Common Mistakes That Salesforce.com Didn’t Make – 2011

Le concierge agile ?

L’envie de tenir un blogue sur le thème de l’agilité (et oui, encore un !) me démangeait depuis quelques mois. Mais il me manquait quelque chose d’important pour pouvoir démarrer mon blogue : un nom !

Cette recherche d’un nom a tourné longtemps dans ma tête. Je voulais un nom qui annonce directement la thématique de ce blogue mais qui se distingue des autres. Mais rien ne venait, je trouvais mes idées trop sérieuses, trop communes, trop prétentieuses, etc.

Bref, la page blanche…

Enfin… Jusqu’à cette semaine où il m’a été demandé de remplir un questionnaire dans le cadre d’une compétition en informatique. Dans ce fameux questionnaire il m’était demandé d’inscrire ma profession, mais ne prenant pas cette tâche au sérieux j’ai inscrit dans cette section « Concierge agile ». Par cette réponse potache je voulais exprimer la perception que j’ai de mon rôle dans mon organisation. En effet, j’ai parfois l’impression d’occuper un poste d' »homme à tout faire » (Scrum Master, Architecte, Analyste, Conseiller, etc.) dans un contexte agile.

Avant de choisir le nom de mon blogue j’ai bien entendu consulté l’article Wikipédia dédié au concierge pour être sûr de la définition. On peut donc lire dans cet article qu’un concierge a pour fonction de garder un immeuble. D’une certaine manière le Scrum Master est aussi un gardien, celui du Scrum et de son équipe. Plus loin dans l’article on y apprend que concierge est un métier à part entier en Suisse :

Description de la profession : Le/La concierge a des aptitudes manuelles, des compétences pratiques et une compréhension de la technique. Il/Elle est indépendant(e), fiable et entretient un contact facile et correct avec la clientèle et ses supérieurs.

Le/La concierge est responsable de l’entretien des immeubles qui lui sont confiés. Il/Elle est la personne à laquelle les utilisateurs, les clients et les locataires peuvent adresser la parole pour communiquer leurs désirs. Il/Elle les aide dans le cadre des possibilités.

Si on devait résumer, un bon concierge doit-être polyvalent, serviable, responsable, à l’écoute des autres, bon communiquant, un facilitateur pour les autres, etc.

Hey ! Cela ne ressemblerait pas aux aptitudes que l’on retrouve chez un bon Scrum Master ?

Voilà donc l’origine du nom de ce blogue.