Scrum notre sauveur

"Oh ! combien de marins, combien de capitaines
Qui sont partis joyeux pour des courses lointaines,
Dans ce morne horizon se sont évanouis !
Combien ont disparu, dure et triste fortune !
Dans une mer sans fond, par une nuit sans lune,
Sous l'aveugle océan à jamais enfouis !

Combien de patrons morts avec leurs équipages !
L'ouragan de leur vie a pris toutes les pages
Et d'un souffle il a tout dispersé sur les flots !
Nul ne saura leur fin dans l'abîme plongée.
Chaque vague en passant d'un butin s'est chargée ;
L'une a saisi l'esquif, l'autre les matelots !"

On le sait peu, mais Victor Hugo fut particulièrement touché par le sort funeste des projets informatiques au forfait au milieu du XIXème siècle, et Oceano Nox, un de ces plus célèbres poèmes, en est une allégorie poignante (je n'ai mis là que les deux premiers couplets, mais lisez la suite, c'est un poème magnifique).

Heureusement, la fin du XXème siècle a vu l'apparition des méthodes agiles qui allaient tous nous sauver.

Fin.

Pas si simple

Hé non, pas "fin", malheureusement cela n'est pas si simple.

Scrum est, en soi, relativement simple à mettre en oeuvre (des post-it, un tableau, du time boxing, et hop), pour autant, on n'échappe pas aussi facilement à nos anciens démons en changeant uniquement de méthode.

Plutôt que d'y chercher un changement d'état d'esprit, on n'y prend que la méthodologie

Le premier écueil, c'est d'y voir une méthode, alors que c'est surtout une non-méthode. C'est tellement tentant en même temps : on sort de notre approche du cycle en V, après plusieurs bouillons plus ou moins douloureux, on nous promet le bonheur avec Scrum, mais plutôt que d'y chercher un changement d'état d'esprit, on n'y prend que la méthodologie.

Scrum tourne alors au simple exercice de style.

Mais ce n'est pas important de faire des user stories qui répondent à un schéma précis, ce n'est pas important de faire un daily scrum tous les matins (en restant bien debout parce que c'est écrit dans le livre), ce n'est pas important de faire une rétrospective en fin de sprint. Tout cela n'a d'intérêt que dans la mesure où cela vient servir un état d'esprit véritablement agile.

Et être agile, c'est plus compliqué que de simplement appliquer une méthode, cela veut dire être capable de rester clairvoyant par rapport à sa façon de travailler, et être capable de changer ses pratiques quand elles deviennent toxiques ou inopérantes. En même temps, on n'a rien sans rien, Kierkegaard disait que ce n'est pas le chemin qui est difficile mais c'est le difficile qui est le chemin, et c'est bien de quoi il s'agit ici : la difficulté qu'on rencontre quand on adopte l'agilité est le signe qu'on franchit effectivement une étape, qu'on acquiert quelque chose qu'on n'avait pas.

Si on ne rencontre aucune difficulté, c'est que soit on a échoué sans s'en rendre compte, soit qu'on était déjà agile sans le savoir.

Chassez le naturel, il revient au galop

Un autre aspect important à bien prendre en compte, c'est l'humain.

On l'oublie souvent, mais dans un projet informatique, une fois qu'on a choisi la méthode, la technologie, les frameworks, etc., à la fin, ceux qui vont faire le projet, ce sont des gens.

On l'oublie parce qu'il y a eu une époque où on croyait qu'on allait se passer des gens (enfin en tout cas s'en abstraire énormément), c'était l'époque où on concevait tout en UML bien propre, et avec un bon générateur, on avait directement toute l'architecture toute faite, et il ne restait plus qu'à remplir le corps de chaque méthode (et encore il y en avait déjà plein toutes écrites), ce qui était effectivement un travail à faire (ou à faire faire) mais qui n'aurait de toute façon aucune incidence sur le projet dans la mesure où la conception initiale était bonne.

En fait, ça ne marche pas, car la réalité c'est que ce sont des gens qui vont écrire du code, des gens qui vont expliquer des user stories à d'autres gens, des gens qui vont tester, des gens qui vont être d'accord ou pas pour dire que le projet est fini, etc.

Cela nous amène à deux conclusions importantes :

• si les gens en question ne comprennent pas Scrum, n'en veulent pas, ou bien retombent systématiquement dans leur approche ancienne, il est inutile de leur forcer la main. Cela ne servira à rien, ce ne sera là aussi qu'un exercice de style,
• pour un projet donné, ayant un périmètre fonctionnel donné, telle combinaison de personnes (on parle là aussi bien de l'équipe de réalisation que de l'équipe cliente) va conduire à un projet réussi, et telle autre combinaison à un projet raté. À cela, Scrum ne changera rien.

Le contrat implicite

Et enfin, un dernier piège à éviter c'est le Contrat Implicite de Scrum. Personne n'en parle, mais il existe. Il découle d'un fait simple et connu mais mal appréhendé: à la fin du sprint, il y a une démo.

Le contrat implicite de Scrum est simple, il ne contient qu'une seule clause: cette démo doit être bien.

Cette démonstration va tout conditionner : la perception que le client a de notre travail, la confiance qu'il va avoir en nous, et partant, le degré de liberté qu'on aura sur les sprints suivants.

La seule préoccupation qu'on doit avoir au cours d'un sprint est donc : que va-t-on montrer à la fin ?

C'est plus ou moins expliqué dans la littérature Scrum. Il y a en effet cette idée qu'on doit livrer des fonctionnalités finies, qui marchent vraiment, qu'on ne compte pas les points d'une story qui n'est pas finie, etc. Mais on n'insiste pas tellement sur l'aspect fondamental de cette démonstration et sur l'impact qu'elle peut avoir sur le cours du projet.

Il faut qu'elle soit préparée, répétée, calée, il faut qu'elle soit dynamique, agréable. Cela peut paraître vain, certains diront que c'est une perte de temps. Au contraire, il faut voir cela comme la mise en valeur finale de tous les efforts produits pendant le sprint.

On sait que le travail de développeur est ingrat : on se coltine des frameworks dantesques, des patterns à décoller les neurones, et le résultat c'est juste un bouton au milieu d'une page. Personne ne va venir admirer notre code, la seule chose qui sera vu, c'est le bouton. Hé bien, il faut en prendre son parti, et ce bouton il faut qu'il soit beau, et il faut qu'il rentre dans l'écran quand on fait la démo sur un vidéo projecteur en résolution 1024. Ça ne coûte pas cher de soigner un peu ça, et ça vaut le coup.