« La méthode Agile c’est nul ! »

L’un des 17 signataires du Manifeste Agile, Ron Jeffries, a publié récemment un article intitulé « Developers Should Abandon Agile ».

Convaincu par l’Agilité, j’ai bien évidemment été interpellé par son article d’autant plus lorsque je lis ou j’entends des réflexions du genre :

« Ah tu vois la méthode Agile c’est nul : même un de ceux qui l’ont inventée, le dit ! »

Pour moi, être Agile ne peut qu’être bénéfique puisque c’est juste un état d’esprit, c’est :

• Se concentrer sur l’humain (Individus et leurs interactions plus que les processus et les outils)
• Délivrer rapidement de la valeur à des utilisateurs (des logiciels opérationnels plus qu’une documentation exhaustive)
• Echanger (collaboration avec le client plus qu’une négociation contractuelle)
• S’adapter (Adaptation au changement plus que le suivi d’un plan)

Et bien plus !

C’est pour cela déjà qu’on ne parle pas de LA méthode Agile (il en existe tellement !) mais bien d’Agilité ou d’état d’esprit Agile.

 

Abandonner l’Agile ?

Alors pourquoi l’un des signataires de ce Manifeste, qui a tant de succès aujourd’hui, appellerait à l’abandonner ? Penchons-nous un peu sur ce qu’il nous dit.

Il commence son article par :

 « Agile » est devenu un énorme business

avec une note sur le mot « Agile ». Il explique en bas de son article la définition de l’Agile dont il parle alors :

« Ici et dans d’autres écrits, j’utilise le mot « Agile » pour faire référence aux nombreuses instances, approches et processus qui utilisent le mot « agile » pour se décrire mais qui n’adhèrent pas nécessairement à la lettre ou à l’esprit d’Agile Software Développement dont nous avons parlé dans le Manifeste Agile. Je vais parfois me référer à « Faux Agile » pour mettre l’accent ou à « Dark Agile », que j’utilise pour décrire les approches dites « Agiles » qui ont vraiment mal tourné. Je pourrais parler du « Manifeste Agile » pour désigner les idées fondamentales du Manifeste auxquelles je crois toujours. »

Ok, il remet donc tout de suite les choses dans leurs contextes : il parle bien d’abandonner les différentes méthodes agiles qui sont souvent mal utilisées mais il reste convaincu de l’Agilité telle que décrite dans le Manifeste.

En fait beaucoup de personnes parlent de cet article mais il semblerait qu’elles se soient arrêtées au titre…

Bref, Jeffries continue en décrivant ce qu’est devenue l’Agilité aujourd’hui, un business, dû aux très nombreux coachs agiles et méthodes de travail dites agiles qui proposent des certifications, du coaching, du consulting, etc. Il cible en particulier SCRUM qui est aujourd’hui une référence et l’une des méthodes agiles les plus connues dans les entreprises.

Il insiste sur le fait que l’agilité, mal mise en place, ne peut qu’avoir un effet négatif sur le travail des développeurs : beaucoup d’interférences, moins de temps pour développer, forte pression… et c’est ainsi que les bons développeurs préfèrent quitter leurs missions et leurs boites.

C’est sur cette pensée qu’il affirme que les développeurs devraient arrêter « l’agile » puisqu’il les entend trop souvent dire « Agile sucks » (ou plutôt « Scrum sucks ») alors que le Manifeste n’avait pour but que de rendre la vie des développeurs meilleures…

Ainsi plutôt que de se braquer contre l’Agilité, il invite simplement les développeurs à ne pas respecter à la lettre telle ou telle méthode mais d’avoir un état d’esprit agile tel que le définit le manifeste et seulement le manifeste.

 

Être Agile plus que faire du SCRUM

Personnellement, je suis d’accord sur l’idée et je veux aller plus loin que lui.
J’ai appris l’agilité en utilisant Scrum et Kanban (en tant que développeur). J’ai souhaité changer de carrière pour m’y consacrer totalement et passer Scrum Master sur les équipes. J’ai ,dans un premier temps, tenu ce rôle un peu naturellement mais pour aller plus loin et parce que je pense cela nécessaire pour juste bien faire mon travail, j’ai étudié plus précisément SCRUM et ce qui définit l’Agilité dans son ensemble.

Une simple recherche Google m’a renvoyé sur l’Agile Manifesto.

4 Valeurs, 12 principes et c’est tout.
C’est donc ça l’agilité ? C’est assez basique, « normal » en fait. Mais souvent les choses les plus simples…

Par exemple, dans ma société, on nous dit qu’on fait de l’Agile, mais qui dans mon équipe connait ses valeurs et ses principes ? Pas grand monde en fait…

Et SCRUM alors ?

Il existe « le Guide SCRUM » … Incroyable, seulement 19 pages à connaître pour savoir faire du Scrum ? Trop facile !

Alors trop facile (19 pages quand même ce n’est pas rien !), oui, mais j’ai cependant discuté avec pas mal de monde qui font du Scrum ou qui sont Scrum Master et qui n’ont jamais lu ce fameux guide. Comment faire du Scrum sans savoir comment ça marche vraiment ? Sans connaître les rôles ? Sans connaitre ses 3 piliers ? …
C’est en effet la méthode agile la plus connue mais malheureusement surement la plus détournée aussi.

Et puis SCRUM, pourquoi pas, mais surtout : Pourquoi ? Trop de gens associent l’Agilité à SCRUM, comme si être Agile c’était faire du SCRUM…

De plus si on regarde de plus près, en quoi figer un périmètre pendant deux à quatre semaines (sprint) est Agile ? N’y a-t-il pas une des valeurs qui nous dit « L’adaptation au changement plus que le suivi d’un plan » ?

Alors, arrêtons de vendre du SCRUM comme solution à tout !

L’idée serait plutôt de comprendre pour quoi est-ce que SCRUM propose telle ou telle cérémonie ? Pour quoi est-ce que eXtrem Programming propose de travailler en binôme ? etc.
Autrement dit, pour répondre à quels besoins, quelles problématiques est-ce que ces différentes méthodologies ont été créés.
En comprenant cela, il sera alors bien plus facile de trouver des moyens de répondre à ces besoins et à ces problématiques, mais en tenant compte du contexte, et sans appliquer mot pour mot les solutions d’une seule méthodologie.

 

Coach / Consultant / Expert…

Aujourd’hui, on vend aussi beaucoup des prestations de Coach Agile / Scrum master / Consultant Agile, etc.

J’ai un peu de mal avec ces appellations ou du moins avec ce qui se passe réellement :

« Bonjour, alors voilà je vous explique rapidement comment vous aller faire pour faire du Scrum. Je vous propose que l’on se voit 2 semaines à temps plein au début pour un peu tout mettre en place et puis ensuite je passerai 1 fois par sprint pour voir un peu les difficultés que vous rencontrez et pour que l’on en discute »

Mais non ! Ce n’est pas ça pour moi un accompagnement ! Les difficultés se rencontrent tous les jours et être au milieu des équipes est le seul moyen pour avoir le ressenti de chacun et (s’) adapter en conséquence.

Est-ce qu’un coach de sport voit son équipe au début d’un championnat puis par ci par là pour parler des choses qui posent problème ? Non.
Alors oui participer aux rétrospectives de sprint c’est bien, mais c’est loin d’être suffisant.

Je vois vraiment mon travail comme du suivi et de l’accompagnement sur le long terme, étape par étape et en s’adaptant quotidiennement aux équipes. Être simplement Agile en fait…

Donc pour conclure, oui, les développeurs doivent alerter et faire en sorte de travailler dans de meilleures conditions et donc abandonner le « faux Agile » mais le message ne doit pas s’adresser (qu’)à eux !
C’est aux coachs, consultants, Scrum Master, etc de les aider et de faire en sorte d’être Agile comme le dit le Manifeste, d’avoir l’état d’esprit Agile et d’être un leader Agile au service des équipes.
Ce sont eux les experts, c’est à eux de correctement faire leur travail et de faire en sorte d’être de réels facilitateurs, de s’adapter au contexte et ainsi faciliter le travail des développeurs afin de les réconcilier avec l’Agilité.