Les maisons sont construites en agile

« Laissez-moi tout d’abord préciser un point : je parle du cas de construction dans une relation client-fournisseur : c’est-à-dire que je suis client et je demande à un fournisseur de construire ma maison. Je ne parle pas de ceux qui construisent en auto construction. Ils ne sont pas dans une relation client-fournisseur, ils sont à la fois le client ET le fournisseur, c’est donc (censé) être plus simple. Mettons-nous dans la position du client. D’après vous quel scénario est le plus réaliste ?

1. Vous signez un prêt à la banque. Vous engagez un architecte. Vous attendez que l’architecte vous appelle dans un an pour vous faire découvrir la maison et pour qu’il vous donne les clés.
2. Vous signez un prêt à la banque. Vous engagez un architecte. Vous allez souvent sur le chantier PENDANT toute la durée de la construction. Dans un an vous connaitrez déjà la maison et vous signerez les papiers officiels.

En général tout le monde est d’accord : la vraie vie c’est le scénario 2. En effet, le scénario 1 correspond au cas où on achète une maison “sur plan” : tout est figé au début sur des plans et chaque changement au plan coûte (très) cher.

J’ai construite une maison et j’ai joué le scénario 2.

Je sais bien que mon banquier ne me donnera pas un euro de plus et que j’ai signé les devis de 10 artisans qui vont intervenir. Dans tous ces devis il y a la liste exhaustive du matériel à acheter et des activités à réaliser. Malgré cet engagement fort de ma part auprès de mon banquier, de mon architecte et de mes artisans, cela ne m’empêche quand même pas de me déplacer sur le chantier toutes les semaines. Tous les samedis matin pour être précise. Je m’assure que tout le monde sache qui je suis. “Bonjour, je suis madame PONTHUS, la propriétaire.” Sous-entendu : “La cliente qui doit être contente c’est moi, je représente toute la famille !” Je me présentais ainsi car je voulais créer un lien avec l’équipe de production, je veux qu’ils me connaissent et me comprennent. Je représente ma famille, c‘est à dire les utilisateurs de la maison et leurs besoins (le Product Owner en Scrum). Je viens voir l’équipe de développement souvent. Souvent ce n’est pas tout le temps, j’ai autre chose à faire de ma semaine. Mais je n’imagine pas laisser passer du temps sans avoir donné mes retours sur la production en cours. Je ne passe pas pour contrôler le travail réalisé. Je n’en suis pas capable. Contrôler c’est le travail de l’architecte, moi je passe pour me rendre compte si c’est bien ma plus belle maison que je suis en train de faire construire. Je valide l’adéquation au besoin et non la conformité à la demande initiale. Le plan de la maison, je l’ai vu 100 fois (ou plus !). J’ai hâte de voir le produit. Au début quand je me suis déplacée j’ai été déçue, il n’y avait rien à voir. Une dalle de béton ça n’aide pas beaucoup à se projeter. On se dit même que ça ne rentrera jamais toutes les pièces là-dedans ! Impossible d’imaginer une utilisation de l’espace, ça paraissait vraiment trop petit. L’équipe de développement (les artisans) était en train de préparer le socle technique et n’était pas encore prête à me montrer un produit avec de la valeur métier. Puis quand ils ont monté les murs, ma visite hebdomadaire était bien plus sympathique. Beaucoup plus facile de se projeter, les pièces ressemblaient à quelque chose.

Et là ce fut intéressant. J’avais bien précisé à mon architecte : « Je voudrais boire un verre de vin ou une bière avec mes amis pendant que je cuisine. »

J’en avais assez d’être dans une autre pièce. J’aime cuisiner, et je veux quand même participer aux échanges du salon. Mon architecte avait répondu : “Très bien, je vais concevoir une cuisine américaine avec un bar accolé au plan de travail. Ainsi vous serez toujours à côté de vos invités.” Sur le papier, ça semblait super. J’ai validé sa spécification. Quand, lors d’une visite hebdomadaire, je me suis retrouvée dans ma maison en construction avec les murs montés, je me suis imaginée dans ma cuisine. A l’endroit précis du bar. Il était facile de constater que le salon était rectangulaire. Je le savais bien, j’avais vu les plans une centaine de fois. Rectangulaire et profond. Profond, je n’avais pas imaginé autant. Ce salon rectangulaire je le trouvais très bien, mais quand j’ai été dedans la première fois j’ai réalisé qu’il créerait surement un peu d’ombre dans l’espace du bar. J’ai répété ma demande à l’architecte “Je voudrais boire un verre de vin ou une bière avec mes amis pendant que je cuisine”, et d’ajouter “l’endroit ne sera pas très agréable, un manque de lumière évident”. Et qu’on ne me dise pas que je ne sais pas ce que je veux, j’ai passé deux ans sur Pinterest, je suis à fond. Mon architecte ne se démonte pas, il répond :

• Lui : “Madame PONTHUS ne vous inquiétez pas, nous pouvons ajouter un Velux juste au-dessus du bar.”
• Moi : “D’accord, il coûte combien ce Velux ?”
• Lui : “2 000 €”.
• Moi : “Dans toute la liste que j’ai signée, il y a quoi qui coûte 2 000 € ?”
• Lui : “La porte électrique du garage coûte 2 000 €”.

C’était parfait.

Dans ma liste de priorités je m’en f… de la porte électrique du garage. Je suis tout à fait capable d’ouvrir une porte de garage, pas besoin d’assistance. Et puis l’utilisation sera peu fréquente, nous prévoyons peu d’y faire dormir une voiture. En tant que Product Owner, j’avais trouvé un item peu prioritaire dans mon Backlog, donc je pouvais m’en passer, et il me permettait d’ajouter un nouvel item bien plus important, et au même coût ! Cette histoire utilisateur a été validée sans me coûter un euro de plus. Le Product Owner décide de ce qu’il faut faire et de ce qu’il ne faut pas faire. Il est responsable de faire travailler l’équipe de développement sur le plus important d’abord, ainsi il lui est facile de déprioriser les items moins importants qui ne sont pas encore produits au profit des changements qui sont importants. Le Product Owner priorise le plus important en terme de valeur métier. Il restait même une décision technique à prendre pour la porte électrique du garage (le mécanisme devait se situer à côté ou au-dessus d’une porte en fonction de la place que l’on souhaiterait utiliser à l’intérieur) : cette décision n’avait pas été prise, nous n’y avions pas consacré du temps car pour nous ce n’était pas important. Nous avions déjà décidé que cet item était peu prioritaire. Notre changement a donc été facile à prendre en compte, notre item peu prioritaire a été sorti de la liste rapidement.

Cette situation s’est reproduite plusieurs fois.

Nous avions prévu initialement de ne pas faire de terrasse, puis nous avons changé d’avis. Le charpentier a dû revenir. Le carreleur avait fini et nous avons demandé à ce qu’il repasse pour en ajouter à côté d’un lavabo (la projection d’eau rendait la présence du carrelage évident), dans une pièce non carrelée initialement. Nous avons manqué d’items peu prioritaires à enlever. Nous voulions tout ! Comme nous ne sommes pas riches, nous avons enlevé un item : la peinture. A la fin nous avons peint toutes les pièces par nous-même, c’était suffisant pour payer nos changements supplémentaires. Ceci mesdames messieurs les informaticiens, c’est de l’agile ! Heureusement que je n’avais pas figé toute l’architecture au début du projet : aucune option de changement n’aurait pu être possible. Si l’architecture du toit n’était pas modifiable je n’aurais pas pu avoir un Velux. Même histoire pour le carrelage :

• Moi : “Je n’ai pas encore décidé du carrelage c’est normal ?”
• L’architecte : “Ce n’est pas encore le moment.”

Effectivement je dois reconnaître que mes idées initiales de carrelage ont été revues quand j’ai constaté la grandeur de la pièce, que j’ai pu m’imaginer la lumière de l’espace et la navigation entre les pièces. C’est de la production en juste à temps, de l’architecture émergente. Nous avons décidé des choix d’architecture au dernier moment raisonnable. Bien sûr il faut un socle technique. Il faut que ce socle soit prêt, mais pas complet. Si le socle est complet et détaillé, les changements seront difficiles. Si le socle technique est prêt, l’équipe de réalisation peut commencer à se concentrer sur la production de valeur. Le client n’est pas inquiet de ce qui n’est pas encore figé, ce sera à figer quand il le faudra (au dernier moment raisonnable). Souvent l’agilité est réduite à l’incrémental. C’est-à-dire à la production par lots. Mais l’agilité c’est de l’incrémental et de l’itératif. Itérer c’est accepter de refaire quelque chose qui marche déjà, comme ajouter le velux dans la cuisine pour mieux répondre au besoin utilisateur. C’est difficile comme concept, car personne n’a envie de refaire ce qui marche déjà, ou de prendre le risque de le casser. On a peur de perdre du temps à refaire. C’est comme un sentiment d’échec, on rêve de réussir du premier coup. On préfère passer du temps à imaginer ce qu’il faut faire plutôt qu’à refaire ce qu’on a vu. On aurait plus confiance dans notre imaginaire plutôt que dans ce qu’on voit ? Pourtant on a aussi un sentiment d’échec quand on utilise notre produit et qu’il n’est pas aussi bien que celui qu’on voulait. Donc itérer c’est une chance ! Refaire c’est accepter de payer le coût de l’apprentissage, la connaissance ne vient pas de l’imaginaire, du plan, mais de l’expérience.

L’itératif permet d’apporter plus de valeur que la situation précédente, et c’est pour ça qu’on itère justement.

Si nous construisions nos maisons comme nous réalisons nos projets non agiles il se passerait souvent ceci : j’emménage dans ma nouvelle maison juste finie. Je l’habite avec toute ma famille pendant un mois. Nous faisons le point : cela ne nous plait pas assez. Nous lançons la construction d’une deuxième maison. Et nous essayons à peine de revendre ou de réutiliser la maison numéro 1 ! Ce serait inconcevable dans notre vie personnelle, nous sommes d’accord ? Et pourtant, souvent, c’est ça la vie des projets informatiques non agiles. Il faudrait attendre combien de versions pour être pleinement satisfait ? De temps en temps on me répond avec sourire : trois versions ! En agile on répond au changement en montrant souvent un produit qui fonctionne. Les changements sont intégrés pendant la production : les adaptations successives pendant la production permettent l’adoption du produit à la fin de la production. La question est “quelle est la valeur métier à créer pour cette itération ?”, “est-ce le plus important ?”, “qu’est-il prévu pour la prochaine itération ?”. Pour ma maison je savais toujours ce qui se passait chaque semaine, et quelle valeur métier je devais vérifier. Je savais aussi ce qui devait se passer la semaine prochaine. Parfois je ne trouvais pas la valeur métier très claire (“nous devons couler la dalle de chauffage“). Quand la priorisation était technique, il fallait que je comprenne tout de même quelle était la valeur métier à créer. J’arrivais bien à comprendre “pour allumer le chauffage”, “pour mettre en place l’électricité”. Et il n’y avait pas souvent de priorisation uniquement technique, l’architecte arrivait tout le temps à m’expliquer pourquoi. Quand nous avons emménagé dans la maison ça a été pareil. Nous n’y avons pas emménagé quand elle était complètement finie. Nous y avons emménagé quand la valeur métier “pour pouvoir cuisiner” a été validée. Avec un frigo et un réchaud électrique, ça fonctionnait. Nous avons itéré sur la cuisine quand nous avons reçu notre four et alors nous avons fini la cuisine (trois semaines après !). Je constate que l’on arrive à être agile dans un contexte comme celui-ci, donc je me demande bien ce qui nous empêche d’être agile en IT. Pourtant en IT on travaille sur du virtuel, ça doit coûter moins cher de faire et défaire que dans le bâtiment. La planification de monsieur Gantt était utile dans les ateliers des usines de Taylor pour prévoir comment régler les machines. A cette époque les hommes aussi étaient des machines. Pour tout ce qui concerne l’humain et les interactions, il y a l’agile. »