Le Scrum #NoEstimate est un Scrum où nous décidons de ne plus mettre de notion de temps. C’est facile à dire mais comment faire pour le mettre en place au sein de nos structures ?
Qu’est-ce que le #NoEstimate ?
Le mouvement NoEstimates est un mouvement récent lancé par Woody Zuill et Neil Killick que de nombreux coachs agiles conseillent dès que l’entreprise est dans un contexte qui permet d’avoir cet état d’esprit. Ce mouvement propose de ne plus estimer et d’avancer selon une vision qui s’adapte au fur et à mesure.
Les méthodes de gestion de projets ont régulièrement imposées d’estimer les travaux à réaliser avec pour but de proposer des roadmap voire des cahiers des charges complets. L’estimation permettait de mettre des coûts fixes aux projets lorsqu’on utilisait les méthodes de gestion de projets tels que le Cycle en V.
Faire un Scrum #NoEstimate
Avant même de dire : « on n’estime plus », il faut amener la culture du #NoEstimate au sein de la structure.
Apple et Samsung en #NoEstimate
Prenons deux exemples très connus sur le marché : Apple et Samsung. Ces entreprises font des évolutions de leurs téléphones phares sans s’imposer de timing ; la suppression du timing permet de sortir des estimations.
Apple a une vision de la prochaine version que la firme aimerait proposer à ses clients l’année suivante mais elle s’en impose pas la certitude ; si une fonctionnalité n’est pas prête, elle sera automatiquement remise pour la version ultérieure.
Maintenant, Apple laisse les rumeurs se mettre en place (souvent fondées sur des éléments réels) et voit la réaction du marché par rapport à ses rumeurs. Certes, cela ne peut pas empêcher certains téléphones d’être produit mais ils peuvent adapter leur communication par rapport aux réactions du marché.
Une des réaction les plus probables est la suppression de la prise jack sur les iPhone 7. Le marché n’a semble t’il pas beaucoup apprécié sa suppression lorsque la rumeur est née… Apple a alors ajouté un adaptateur dans son package téléphone afin de limiter la gronde. C’était bien évidement une réaction très intelligente.
Samsung qui a été publiquement sévère envers Apple sur ce sujet a fini par s’y mettre.
Si cet exemple est à l’avantage d’Apple, rassurez vous, Samsung a eu aussi son heure de gloire en imposant les systèmes de notifications d’Android sur les smartphones haut de gamme (depuis, Apple a exactement les mêmes).
A notre niveau ?
Je vous conseille d’amener l’idée dans vos entreprises que les dates ne sont pas si essentielles et qu’il est préférable d’aller vers un produit de qualité. Pour cela, nous baserons toute la stratégie d’évolution du produit sur un axe user-centric (participation active des utilisateurs clés, feedback réguliers…).
L’entreprise acceptera que le produit avancera selon une vision et non selon des estimations précises. Certains me diront, mais c’est ça l’agile, non ? C’est vrai, mais le #NoEstimate pousse cette notion à son extrême.
Fin des Poker Planning et de l’Extreme Quotation
Pour faire un Scrum #NoEstimate, vous devrez arrêter vos séances d’estimation, et accepter d’avancer au fur et à mesure. Certains vont même en profiter pour transformer ce Scrum en Scrumban (scrum sans planification de tâches sur deux semaines pour faire simple).
Article : Changer pour la méthode Scrumban ?
Cependant, ne plus estimer ne veut pas dire ne plus discuter ! Il est essentiel que les développeurs continuent les ateliers de type Product Backlog Refinement afin de discuter de l’ensemble des demandes afin de s’assurer qu’elles sont 100% comprises. On va juste enlever la partie estimation de ces cérémonies.
Articles :
Fin de la Sprint Planning Meeting
Faire la Sprint Planning Meeting n’a plus beaucoup d’intérêt car en #NoEstimate, on part dans l’idée de faire du flux tiré. A chaque fois que les développeurs terminent des tâches, le Product Owner leur propose de nouvelles tâches.
On commencera ainsi notre itération par une Sprint Objectives afin d’énoncer les objectifs qu’on aimerait atteindre en fin d’itération.
Je conseille par contre au Product Owner de créer une logique dans la demande des tâches car le changement systématique de sujet peut vraiment perturber les développeurs.
Les développeurs découperont les demandes en sous-tâches techniques quand ils prendront les nouvelles demandes ; ils pourront sans soucis se faire aider par les autres membres de l’équipe en cas de besoin.
Une roadmap #NoEstimate
La roadmap #NoEstimate est très simple à faire car le but est de proposer un enchaînement de fonctionnalités que l’on désire développer. Celle-ci pourra d’ailleurs changer si les dépendances requises ne sont pas terminées.
Je conseille fortement de partager cette roadmap dans les équipes qui sont en #NoEstimate afin qu’elles sachent vers où elles avancent.
Feedback et Hypothèses en marche
Si cela n’est pas indispensable, je conseille au Product Owner de faire des hypothèses de fonctionnalités qui seront présentées aux utilisateurs clés concernés (voire les stakeholders) ; selon le retour de ceux-ci, il envisagera ou non des modifications.
En cas d’un produit public, n’hésitez pas à tester vos hypothèses avec des outils tels que Twitter ou Facebook.
Même si cela est à mes yeux un pré-requis en Scrum, il sera indispensable de récupérer un maximum de feedback des utilisateurs clés (pourquoi pas lors des reviews).
Conclusion Scrum #NoEstimate
Pensez-vous pouvoir mettre en place ce Scrum #NoEstimate au sein de vos équipes ? C’est une vision très agile mais qui ne s’adapte pas au contexte de toutes les structures.
Soyez le premier à commenter