J’aime vraiment bien ce que fait Henrik Kniberg et surtout comment il le fait, car Henrik possède une réelle capacité de vulgarisation qui lui permet de rendre simple et fluide la compréhension d’un problème compliqué. Et si vous ne me faites pas confiance, J’espère que vous ferez confiance à Marie Poppendieck qui dit la même chose dans la préface du dernier livre co-écrit par Henrik sur Scrum & Kanban (disponible au téléchargement sur le site de Claude Aubry).
Mais revenons au sujet de cet article : La Checkliste Scrum Non Officielle (disponible en anglais ici) proposé par Henrik sur le site de Crisp.se
En 2 pages A4 (Henrik aurait-il suivi les recommandations Lean du A3), Henrik nous propose un questionnaire simple et redoutablement efficace pour évaluer l’application de Scrum par une équipe projet.
Tout d’abord 3 questions essentielles qui valent de l’or … ou plutôt la garantie d’utiliser un processus performant :
- Livrer un logiciel opérationnel et testé toutes les 4 semaines ou plus fréquemment
- Livrer ce que le business attend le plus
- Améliorer son processus en permanence
Viennent ensuite 10 thèmes de questions sur l’application réelle de Scrum couvrant les rôles, pratiques et artefacts. Tous ces points sont des pré-requis pour que l’équipe puisse dire : NOUS FAISONS DU SCRUM !
Puis ensuite un ensemble de points qui ne sont que recommandés et non obligatoires dans la pratique de Scrum, et parmi ceux-ci :
- La présence d’un Scrum Master
- Le calcul de la vélocité
- Le Burndown de sprint
- La mêlée quotidienne
Puis 3 questions sur le fonctionnement de Scrum à grande échelle, et 3 les indicateurs positifs comme le FUN et le travailler pas tard 🙂
A titre personnel, je suis surpris que le calcul de la vélocité ne soit pas un pré-requis. Bien que je comprenne la raison, calculer la vélocité n’aide pas à la livraison d’un incrément de produit fini, je sais d’expérience que toutes les organisations demandent une vision à moyen terme de ce qui va se passer et sans la vélocité, il est impossible de donner quelques informations sur la mise à disposition d’une release.
Nous pourrions également discuter sur l’absence de pratique d’ingénierie telle que le TDD, Refactoring, Tests Unitaires, Intégration Continue … mais cela s’explique car Scrum est seulement un cadre (Framework) pour livrer de la valeur métier rapidement … et rien de plus, mais c’est déjà beaucoup !
PS : J’ai proposé à Henrik de la traduire en Français … je vous tiens au courant 🙂