Et pourtant, définir par quoi on va commencer les développements, quelles fonctionnalités, quels thèmes placer en haut de la pile, en 1 mot, PRIORISER, est un des éléments moteurs de la mécanique Agile…Troisième billet orienté Coaching Scrum…
Pour être agile, il faut en effet fixer des priorités (rappellez-vous ce que nous disait Jeff, « un backlog priorisé« …).
L’art de prioriser, c’est le boulot du « Métier », c’est à dire du Product Owner (équivalent Client du mode eXtreme programming), idéalement dans un esprit collaboratif avec l’équipe, car seul on a pas toujours toutes les clés.
Mais prioriser ce n’est pas toujours simple !
Mon challenge:
- Très vite aiguiller vers ces 4 critères déterminants : Development Cost, Risks, Knowledge, et surtout Value (la Valeur de l’élément et aussi le coût de ne pas l’avoir, souvent négligé)
- Insister sur la valeur pour le client, le critère majeur, un principe Lean, encore plus puissant dans une logique de développement agile, incrémentale avec des livraisons fréquentes. En livrant tôt et vite des éléments sources de valeur, on y gagne tous financièrement!
Les autres critères, plus contextuels, vous permettent d’effectuer des arbitrages, et de lever au fur et à mesure les incertitudes. - Faire découvrir un outil simple et efficace d’aide à la décision: le modèle de Kano, et son impact sur les priorités de développement
- Convaincre que la formule gagnante consiste à traiter au plus tôt les fonctionnalités qui vont vous permettre de recueillir le plus de feedback des utilisateurs, en s’appuyant sur un travail ergonomique efficace au niveau de l’interface. En cela, vous jouez sur chaque critère: valeur, coût, connaissance et levez les risques majeurs de tout projet informatique: rejets, non acceptation, non adéquation aux besoins…
L’agilité repose sur le feedback permanent, alors allons jusqu’au bout ! C’est mon point de vue de défenseur de l’expérience Utilisateur, c’est aussi le point de vue de stars du mouvement Agile comme Mike Cohn:
« So, because of the additional learning and risk reduction that can be had, it seems reasonable to move earlier in the schedule those themes that will allow users to provide the most feedback on the usability and functionality of the system. This does not mean that we would work on the user interface in isolation or separate from the functionality that exists beneath the user interface. Rather, this means that it might be appropriate to move forward in the scheduling those features with significant user interface components that would allow us to get the most useful feedback from customers and users » Agile Estimating and Planning
Bon, si tout le monde est d’accord, appelez-moi pour mettre en place une ergonomie Agile !