toltequeagile.com est un site de Thierry Cros Organisation
Toltèque Agile
10/02/2017
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
Ou bien côté "besoin" des critères tels que
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.