samedi 2 novembre 2013

SCRUM, méthode ou façon de faire ?

Ahhhh, les méthodes agiles... un sujet qui fait fureur en ce moment dans la plus part des entreprises en France, dans les écoles informatiques d'ailleurs. C'est carrément un débat car il suffit d'en parler autour du café ou avec un collègue développeur (ou autre) pour se rendre compte que tout le monde sait ou pense savoir des choses dessus... D'ailleurs, je me rends compte que les gens savent beaucoup de chose dessus et pourtant, plus de la moitié d'entre eux ne l'ont jamais pratiqué sur le terrain... En tout cas, quasiment très peu ont réussi à le mettre en place de la façon dont ils comprennent la méthode : Moi en premier. 

D'où cette question que je me pose : est ce que SCRUM est une méthode ? on dit bien couramment "la méthode SCRUM " => et pourtant je me rappelle qu'il y a à peine 3 ou 4 ans, Ceux qui en parlait le plus (les scrumMasters que j'avais rencontré) disait que ce n'était pas une méthode mais plutôt un ensemble de bonnes pratiques qui pouvaient s'appliquer afin de palier aux problèmes récurrents qu'on rencontre souvent dans les projets informatiques. 
Aujourd'hui, où SCRUM est encore bien plus ancrée en entreprise, on pourrait se poser les questions suivantes : 
- Fait-on du SCRUM si on ne fait pas de dailyScrum ? 
- Fait-on du SCRUM si on ne fait pas de rétrospective à la fin de chaque Sprint ? 
- Le simple fait de réussir à impliquer le Product Owner suffit-il dire qu'on fait du SCRUM ? 
- La documentation doit-elle vraiment baisser (voir disparaître) de priorité dans un projet en SCRUM ?
- Au final, fait-on tous du SCRUMBUT ?
Il est clair d'après moi qu'il faut impérativement mettre en évidence les zones d'ombres ainsi que les points positives constatés à la fin d'un Sprint, tout comme le dailyScrum  qui est fortement conseillé. Je pense que la "méthode" ou la "façon de faire" SCRUM met beaucoup de choses en évidence dans un projet informatique et propose un ensemble de bonnes pratiques qui sont bien adaptées aux besoins changeants et récurrents des clients. Cependant, SCRUM proposes une approche qui ne semble pas emballer beaucoup de personnes qui ont du mal à adhérer au "dynamisme" de la méthode, à abandonner leur façon habituelle de travailler (surtout chez les clients finaux) ou  à s'impliquer lors des projets comme le propose SCRUM qui font foirer ces projets : en exemple, je citerai un PO qui ne s'implique pas, des développeurs qui jugent le Daily inutile, le chef de projet qui se prend pour le ScrumMaster et qui force à suivre à la lettre des pratiques qu'il a lu dans le manifeste Agile ou à une formation Scrum d'un jour tout en mettant la pression au développeurs, le ScrumMaster qui ne comprend pas que son rôle c'est juste de s'assurer de la mise en pratique de la méthode et non de donner des ordres...

Au final, ce que je constate le plus c'est qu'on est de plus en plus nombreux à adhérer à SCRUM et à reconnaître ses avantages (surtout en France), même si en retour d'expérience, certains ScrumMaster remontent tout de même des problèmes d'adhésion à la méthodologie ou au non respect de règles de bases que propose SCRUM (ce qui tend à disparaître et c'est plutôt bon signe)...

Est-ce là le véritable problème de SCRUM ? l’interprétation des "règles" de la méthodologie si différentes selon l'équipe ? Ne pourrait-on pas y voir un avantage justement ? une méthode qui nous fourni un cadre auquel on peut adjoindre nos contraintes projets de façon  souple ?
A méditer...

Aucun commentaire:

Enregistrer un commentaire