Scrum en bouc émissaire

La rançon du succès

La diffusion de Scrum a connu une croissance très forte ces dernières années. Fatalement ce mouvement amène son lot de personnes mal formées, d’opportunistes qui vendent des compétences au rabais… puis de projets en difficulté. Rien d’étonnant : la transition à Scrum (et à l’agilité en général) demande beaucoup d’efforts et du savoir-faire pour conduire le changement culturel.

En tous cas, c’est le buzz du moment : tous les projets de développement de logiciel ne réussissent pas, même avec Scrum. Ah bon ? Et Scrum serait en cause parce qu’il n’impose pas de pratiques d’ingénierie. Ça fait blablater dans les blogs.

Pourtant, personne de sensé ne dira qu’il faut arrêter de faire des tests quand on passe à Scrum ou ne plus faire d’intégration continue. Au contraire, Scrum pousse à renforcer l’usage de pratiques d’ingénierie de développement.

Comme tous les promoteurs de Scrum et de l’agilité, et peut-être encore plus en tant qu’enseignant en génie logiciel, c’est ce que je défends auprès de mes étudiants et de mes clients : l’excellence technique. Pour y parvenir et éviter le ScrumMou, Emmanuel Chenu fournit une liste de principes et de pratiques utiles. Au passage, je remercie chaleureusement ManU qui participe au côté rock’n roll de mon blog en me dédicaçant Police, après les Clash.

Au-delà du buzz sur “la faute à Scrum”, un débat qui me semble bien plus intéressant, c’est celui sur le contexte : impérialisme du contexte ou pilotage par le contexte ?

Voir aussi