Scrum : une permissivité nuisible à l'agile

Scrum est une coquille vide : c'est sa force... et sa faiblesse. Entre "Definition of Done" et "produit partiel potentiellement livrable" il est nécessaire de compléter Scrum pour obtenir une pratique véritablement agile.

Scrum est un cadre propice à l'agile. Toutefois, il y a de fortes chances de passer à côté. Un Scrumien a donc tout intérêt à s’intéresser sérieusement à ce qui manque à Scrum pour respecter véritablement les principes agiles.

Prenons deux exemples.

Definition of Done

Selon le Scrum Guide, la Definition of Done (DoD) est présentée ainsi.

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Si le Scrum Guide insiste sur la nécessité de renforcer cette définition, il n'est pas prescriptif, ce qui en fait sa force dans la mesure où cela peut s'adapter à n'importe quel produit finalement. Or, cette DoD est essentielle pour assurer la qualité du code produit. Que va faire une équipe de Développeurs peu sensibilisée à cette question ?

Allons-nous retrouver des critères tels que

• Standards de codage
• revue de code
• présence de tests-développeurs (type tests unitaires...)
• Gestion de configuration.

Ou bien côté "besoin" des critères tels que

• passage des tests d'acceptation
• tests non fonctionnels mutualisés
• tests de non régression.

Il s'agit donc de se poser la question non seulement de la DoD mais de sa pertinence.

La question des livraisons

Vous connaissez probablement la célèbre expression "produit partiel potentiellement livrable" qui décrit l'incrément obtenu à la fin d'un sprint. Le Scrum Guide est plutôt flou sur le sujet : le PO peut décider de mettre en prod... ou pas. Or dans bien des cas, les dates de livraison ne se définissent pas ainsi. Ce sont des rendez-vous fixés parfois longtemps en avance pour répondre à des nécessités "métier", techniques, réglementaires... De façon générale, un PO se doit donc de maintenir un plan de versions fréquentes.

Sprint !

Enfin, que dire de ce terme parfaitement anti-agile : sprint... Il ne s'agit pas de sprinter mais de s'inscrire dans un rythme soutenable (c'était la pratique "40 h / semaine" dans l'Extreme Programming, devenue d'ailleurs "Energized work" en 2004). Parlons plutôt d'itérations, tout simplement.

Les processus Agiles encouragent un rythme de développement
soutenable. Ensemble, les commanditaires, les développeurs
et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.