• T’as finis ton US ?
• Ouais, ça y est, c’est bon !
• Donc, t’es done ?
• Oui, elle est “done” !
• On peut la mettre en prod ce soir ?
• Ah ben non, y’a encore des trucs à faire …
• Donc, elle est pas “done” ?
• Ben si, le dev est terminé. Mais il reste des trucs à faire, mais c’est pas moi. Elle est pas “done-done"…

Le concept de "definition of done” de Scrum est souvent interprêté comme une licence à ne pas aller jusqu’au bout de l’action (la mise en production, même seulement “potentielle”) mais comme un niveau d’accomplissement:

• Developpement terminé.
• Acceptance tests terminés.
• End user tests / beta testing terminé.
• Qualification opérationelle terminée.

Ce n’est pas le cas. Ce n’est pas de cela dont Scrum Parle quand on parle de “definition of done”. Le “done” de Scrum signifie toujours que mon développement peut être déployé en production sans autre forme de procès, que je le fasse effectivement ou pas !

Cela signifie simplement qu’en fonction de l’organisation, le paquet-cadeau pourra contenir différentes choses :

• Une documentation utilisateur.
• Un audit de conformité au plan d’urbanisation.
• Une formation utilisateur.
• Un outillage de monitoring pour les équipes de production
• etc…

Votre imagination peut être sans limite, mais il en ira alors de même du coût de votre “definition of done” !

Mais on voit les équipes abdiquer par rapport à ce critère et inventer des niveaux de “done” intermédiaires ! Pourquoi ?

le plus souvent parce que les organisations font peser sur elles des contraintes de fonctionnements qui ne leur permettent pas d’avoir le contrôle sur toute la chaine jusqu’à la mise en production.

• Ce peuvent être des cellules de test séparées, avec des plannings indépendants du projet et générant ainsi du délais.
• Très souvent, sont concernées les équipes de productions, avec leurs propres plannings de mise en production transverses à de nombreuses équipes.
• De manière générale tout ce qui créé des silos dans l’entreprise est un frein à avoir un véritable “done” !

Impuissants face à ces choix d’organisation, les équipes Scrum préfèrent s’adapter et aligner leur définition de terminé à ce qu’ils peuvent réellement contrôler, donc le périmètre de leur équipe. Mais cela ne corresponds pas à un réel accomplissement. Ce “terminé” va juste prendre la poussière sur une étagère avant d’être testé / qualifié, etc… et ensuite seulement être réellement utilisé !

Cette définition de terminé est un leurre. Il nous donne (peut-être) bonne conscience. Mais surtout il dissimule les lacunes du système !

Ne faites pas cela ! Conservez, augmentez même la visibilité des lacunes du système ! N’abdiquez pas sur la définition de terminé : ce doit toujours être un produit qui peut être passé en production, là tout de suite, maintenant !

N’oubliez pas que d’autres vont plus loin encore dans l’appréhension du done : en Lean Startup, même si cela n’est pas explicitement exprimé ainsi, on est “done” quand on a eu le feedback des utilisateurs et qu’on en a tiré les leçons !

Le constat mis en évidence est souvent douloureux, peut paraitre insurmontable, mais c’est le véritable chemin qui vous reste à parcourir pour arriver à un réel processus agile.