Entretien avec un pape sur le Sprint-0 du Jihad de la méthode

Si vous cherchez sur Google le terme « Sprint 0 », vous obtenez près de trois millions de résultats et dix millions avec « Sprint zero ». Le plus étonnant : mis à part le classique blabla, pas une seule vraie définition de contenu et surtout pas la première idée d’un début de méthode pour le faire.

À la lecture des résultats des premières pages d’une recherche « sprint zero » sur Google, il est évident que les intervenants n’ont jamais dû être en charge d’un projet conséquent ou travailler dans une grande organisation. Sinon, ils n’ignoreraient pas que généralement un projet découle d’une étude d’opportunité, se justifie avec un business plan – lequel persistera parallèlement au projet et tiendra compte des évolutions de tout type impactant les coûts et bénéfices. Ils auraient aussi pris en compte les  impacts organisationnels (nouvelles compétences, formation ou changement des RH…). Sans oublier les contraintes administratives ou organisationnelles, celles techniques liées à l’environnement, la complexité de larges déploiements, etc., etc., etc. La compréhension des bases de données et des architectures existantes ou à créer ne pourrait pas non plus être évitée. Il y aurait aussi à prévoir tous les aspects de l’après-projet liés à des contraintes aussi multiples que variées, qu’elles soient techniques, légales ou simplement organisationnelles. Cette partie post-projet pourrait alors se nommer Sprint « Z ». D’ailleurs, entre nous, ce serait quand même amusant de partir de Sprint Zéro pour finir par Sprint Z ? La boucle de l’ésotérisme méthodologique serait bouclée.

C’est de cet ensemble qu’un vrai chef de projet est responsable et non pas simplement de la gestion de quelques Sprints. En fait, actuellement, avec notre fabuleuse « no méthode » de cinq lettres, le projet semble démarrer lorsque tout est prêt et qu’il ne reste plus qu’un vingt dernier pourcent de codage ou de réalisation à effectuer.

• Bien, mais c’est quoi cette méthode de cinq lettres ?
• SCRUM ! En résumé, c’est une planification en lot des fonctionnalités.
  
• Un simple lotissement comme avant ?
  
• Je n’ai pas dit cela ! C’est beaucoup plus sportif et mystérieux à la fois, c’est un découpage en « Sprint ».
  
• Et quoi d’autre ?
  
• Le matin on se réunit pour parler du projet, c’est le « stand up daily meeting ».
  
• Comme notre réunion du matin ?
  
• Pas du tout : on n’est pas censé avoir son café et il faut rester debout. Dans les problématiques complexes, c’est là que se joue toute la différence théorique.
  
• Oui, mais il y a l’arrivée du « Product Owner », et cette fois, ce concept est bien nouveau ! La preuve : il y a plein de gens qui cherchent à le définir…
  
• Depuis leurs origines voilà des décennies, les méthodes qui se sont rebaptisées « Agiles » en 2001 ont toujours imposé une présence du métier lors de la réalisation du produit. La première en 1991, le RAD, nommait cela « validation permanente ». Vous voyez bien la différence, j’espère…
  
• « Accepter le changement en cours de projet », j’ai compris que c’était cela le point fort des méthodes Agiles. Ces notions d’itératif et d’adaptatif, là au moins c’est indiscutable ?
  
• Pour certaines méthodes Agiles peut-être, mais pour Scrum il n’est pas question de changer le contenu du travail en cours sans remettre tout en question. Au mieux, depuis 2010, peut-on effectuer des changements cosmétiques. Cela tient au fait qu’il n’y a pas de métrique formelle des changements.
  
• Et personne n’a proposé un principe de gestion de ces modifications en cours de projet ?
  
• Pas nos intellectuels payés pour ce genre de recherches en tout cas. Vous savez, des chercheurs qui cherchent, on en trouve. Mais des chercheurs qui trouvent, on en cherche.
  
• Vous-même, pourquoi ne publiez-vous pas sur ce sujet ?
  
• Je l’ai fait ici et sur la page méthode Agile de Wikipédia. Mais l’ « imbéciligencia » locale a encore frappé.
  
• Mais est-ce toujours correct pour Scrum de parler d’Itération ?
  
• Bien sûr que non ! Mais éviter d’évoquer ce sujet, ça va nous attirer des ennuis avec les « pyramidalement certifiés ».
  
• Ce sont des experts de la méthode ?
  
• Non, juste des débutants qui ont appris leur métier en deux jours. Bien souvent ils n’ont jamais fait de projet avec, mais ils mènent maintenant un Jihad méthodologique.
  
• Et pour le chef de projet, cela change sa mission ?
  
• Malheureux ! Mais il n’y a plus de chef de projet !
  
• Ah bon, mais qu’est-ce qu’ils vont faire, les chefs de projets et le PMO en place et ceux que l’on continue à former dans toutes les écoles en ce moment ?
  
• Tu poses trop de questions, toi ! Tu vas finir dans le genre « Scrum m’a tuer ! ».
  
• Et toutes les méthodes Agiles imposent ces contraintes ?
  
• Non, il n’y a que Scrum. Les autres se contentaient de préconiser au responsable du projet d’obtenir un consensus de son équipe. Mais Schwaber, le développeur qui a rédigé pour les deux pages de Scrum, n’aimait pas les chefs. Quant à Sutherland, le « commercial » de l’affaire, il avait surtout en tête l’idée de « choper » les plus simplets à certifier compétents.
  
• Mais alors, s’il y a un problème sur le projet ou « l’appli », le reste de l’organisation s’adresse à qui ?
  
• À un « Scrum master » du genre tampon. Reste juste le problème de savoir qui le paie. Pour toutes les méthodes Agiles, cette rémunération de l’animateur-facilitateur a toujours été la grande question. Du coup on nomme n’importe quel autre acteur à ce rôle. Cela peut être le chef de projet conservé, le responsable du métier s’il a du temps libre, ou bien, comme généralement il n’est pas impliqué, un consultant d’aide à la maîtrise d’ouvrage. Comme aurait dit Cioran : « Être moderne c’est bricoler dans l’incurable ».
  
• La responsabilité de cette fonction doit être terrible !
  
• Tu parles, il s’en fout, il n’a aucun pouvoir sur l’équipe donc il ne peut être tenu responsable de quoi que ce soit. D’ailleurs personne n’a théoriquement à répondre de rien !
  
• Pour que Scrum soit la méthode « la plus populaire », il doit bien y avoir autre chose quand même ?
  
• Franchement, à la réflexion, je ne vois pas. Mais, bon, c’est tellement simplet et déculpabilisant que ça doit plaire à pas mal de monde.
  
• Au fait, pourquoi certains appellent leurs périodes de travail des itérations ? Ils n’ont pas compris la notion immuable de Sprint ?
  
• Si vous commencez à dire que Scrum n’a pas d’itérations mais seulement des incréments, vous finirez par dire qu’il n’a rien à voir avec l’Agilité. Vous ne seriez pas un provocateur ?
  
• Pour finir sur la gestion et le reporting, comment sait-on que le projet se passe bien ?
  
• Pour le grand boss, il suffit de le demander ! : « Ça va les gars ? » Je n’ai jamais entendu personne répondre « Pas du tout ! On est en vrac et dans la mouise ! » D’ailleurs ne cherchez pas le graphe d’avancement, on n’a plus le temps de le faire. De toute façon, c’était de la responsabilité du Product Owner, mais il ne l’a jamais fait. Déjà qu’il n’était pas souvent là pour la spécification et la validation… En revanche admirez les murs comme c’est décoratif, tous ces Post-It colorés !
  
• Mais si le projet ne livre pas le produit attendu, qui est considéré comme responsable ?
  
• Personne ! C’est cela la beauté du machin.  La seule variable d’ajustement est tout simplement le périmètre. Comme on est tous compétents, engagés et de bonne foi, aussi bien le métier que l’équipe, la réponse est simple : si cela devait finir comme cela, cela devait finir comme cela. Il était malin, le Schwaber, il a gravé cela dans du marbre.
  
• Et pour la qualité de mon application et la maintenance ultérieure, vous préconisez quoi ?
  
• De choisir une autre méthode, eXtrême programing par exemple ?
  
• Ah bon, les scrumistes ne connaissent pas tous les techniques de qualité du code ?
  
• Vous rigolez, Scrum c’est « hier je n’y connaissais rien et demain je saurai tout ». En ce qui concerne XP, ce serais plutôt « cela fait des mois que je suis un bon concepteur-développeur mais cela en prendra encore plus avant que je devienne excellent ». C’est un métier, quoi…
  
• J’ai tout compris, c’est fabuleusement moderne. Je vous confie le projet. Il sera fini dans les temps et pour le budget ?
  
• Inch Allah !
  

Depuis 2001, la légende d’une méthode enseignée en deux jours et réglant tous vos problèmes lors d’une seule phase extrêmement simple l’a emporté. Mais comme vous pouvez le constater dans votre réalité, rien n’est si simple dans un monde de plus en plus complexe. Pour se sortir le pied de cette méthode inadaptée en train de polluer les organisations sur la base d’un faux espoir de simplicité, une certaine dose de courage et un retour du sérieux dans le professionnalisme va vraiment être indispensable.

Pour revenir au « Sprint 0 », dans la réalité des organisations, les gens « collent » dans ce truc tout ce qu’il y avait « avant » dans les préalables de leurs projets en mode classique. C’est d’ailleurs bien normal, puisque la profession semble avoir oublié les précédentes descriptions Agiles liées à ces préoccupations ainsi que les pratiques destinées à les obtenir agilement. Enfin, même dans la projection vers l’avenir caractéristique de notre profession, il faudra bien un jour ou l’autre considérer le passé comme une source d’expérience avant que tous ces errements ne finissent par détruire totalement notre efficience.

Ps. Pour l’anecdote, quelqu’un a acheté ce qui tournait autour de Sprint-0 et Sprint-Zero. Cela ne m’étonnerait pas que quelque chose se prépare à ce sujet. Peut-être même une méthode à part entière. Enfin, cela fera toujours du boulot pour les consultants en organisation et quelques articles pour JDN.