De bien belles perspectives pour les consultants en méthodes agiles

Ce n'est pas moi qui le dit, c'est James Shore dans son dernier billet. "Rescuing Scrum teams keeps me in business" avance même un de ses collègues.

La raison ? L'engouement pour Scrum a fait que nombre d'équipes insuffisamment préparées se retrouvent dans des situation inextricables de dette technique. Ils ont naïvement cru que l'on pouvait tirer bénéfice d'une gestion de projet agile sans en payer le prix.

La plus grosse erreur que peut commettre une équipe qui passe à Scrum est de croire que Scrum "seul" suffit à organiser efficacement un développement logiciel. Faire des itérations, construire un produit de manière incrémentale, améliorer la communication entre les intervenants, s'adapter aux besoins changeant. Tout ça c'est très bien mais on ne peut pas s'en contenter.

La clef d'un bon fonctionnement agile c'est d'être en permanence en situation de pouvoir faire toutes les modifications désirées sur un logiciel existant sans se retrouver dans des impasses. Pour cela, il n'y a qu'une solution : maîtriser techniquement le logiciel. Ceux qui espèrent tirer des bénéfices de Scrum en modifiant leur gestion de projet mais sans être prêt à assumer les conséquences techniques seraient bien avisés de revoir leur copie.

Développement agile ou pas, il est toujours souhaitable que les développeurs aient un minimum de cette maîtrise technique. Mais là où un développement en V ou en cascade réduit le risque de non-maîtrise par une réflexion accrue en amont (avec comme conséquence de ne pas être adaptable), le développement agile ne peut s'en sortir qu'avec une réflexion permanente. Etre agile, et donc assumer tous les changements incrémentaux, ça commence par une maîtrise de tous les instants. Cela demande bien plus d'efforts qu'une simple définition d'architecture en amont.

Dernièrement, j'ai assisté à une formation sur la conception d'applications web en java et le formateur a, à mon grand plaisir, introduit son sujet par ces mots "la seule chose qui m'intéresse, c'est la maintenabilité du code".
Au bout du compte qu'est ce que la maintenabilité si ce n'est "d'être en permanence en situation de pouvoir faire toutes les modifications désirées sur un logiciel existant sans se retrouver dans des impasses" ? Développer de manière agile, ce n'est jamais que baigner dans une situation extrême de "maintenance" où la plupart des fonctionnalités du logiciel ne sont pas encore parfaitement connues et où l'on veut pouvoir assurer une maintenance évolutive pendant un temps illimité.

Il y a, parmi les principes agiles, une phrase qui est bien trop souvent laissée de côté au profit de toute la mécanique itérative et incrémentale : "Continuous attention to technical excellence and good design enhances agility".
Il sera toujours temps de le rappeler aux équipes qui ont adopté les méthodes agiles en ne modifiant que leurs pratiques de gestion de projet.

oaz

Je me rends compte que le sujet des échecs de Scrum est plutôt à la mode.

Surtout sur les blogs anglophones :
http://blog.robbowley.net/2008/11/15/lean-scrum/
http://www.kohl.ca/blog/archives/000201.html
http://www.agileadvice.com/2008/11/16/scrumxplean/the-decline-and-fall-of-agile-and-how-scrum-makes-it-hurt-more/

Et aussi chez les francophones :
http://www.aubryconseil.com/dotclear/index.php/2008/11/17/496-controverses

Le mot de la fin (peut être ?) pour un commentateur du billet initial : "Blaming Scrum for project failures is like blaming democracy for the Bush administration".

oaz 17 novembre 2008 - 23:51
JM.D

On ne peut s'empêcher de "blâmer la démocratie" en tant que système qui a _permis_ l'élection de l'administration Bush. Donner la possibilité à une majorité "mal informée" de l'emporter sur une minorité (à quelques voix près...), voilà le risque.

Il faut donc continuer à informer, éduquer, enseigner, prévenir; en particulier dans les séminaires organisés, partout en France, sur le sujet de l'Agilité.

Le prochain sur Toulouse (12 déc.) : http://www.sigmat.fr
Le prochain sur Grenoble (16 déc.) : http://agilegrenoble.sogilis.com/bi...
/liste non exhaustive/

JM.D 4 décembre 2008 - 10:23

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.