Prioriser en toute confiance en organisation agile dual-track APERÇU

Tous les problèmes ne méritent pas d’être résolus et pour presque tous les problèmes, il existe une variété de solution. Prioriser permet de recentrer ces efforts sur là ou il ya de la valeur.

La priorisation des activités de Product Discovery (opportunités à analyser et solutions à trouver) et de Product Delivery (fonctionnalités à développer) est un défi permanent des Équipes Produits et de Développement. Il est tentant de se concentrer sur des fonctionnalités dites intelligentes plutôt que sur celles qui ont un impact direct sur vos objectifs. Il est facile de minimiser l’effort de développement qu’une fonctionnalité exigera par rapport à une autre.

A great product isn’t just a collection of features. It’s how it all works together.

Tim Cook

Dès lors comment décider des priorités pour les prochains cycles de « discovery » et de « delivery » ?

Si vous vous êtes efforcé de réfléchir à de nouvelles idées en prenant le temps de l’analyse du problème, vous avez peut-être trouvé des opportunités d’amélioration et recueilli suffisamment de commentaires par rapports à vos hypothèses de travail pour conclure à une ou plusieurs opportunités (Use Cases). Vous disposez à ce moment là d’une feuille de route solide, remplie de bonnes idées, opportunités pour lesquelles vous êtes prêt à analyser les solutions.

Mais l’ordre dans lequel vous abordez ces idées mérite tout autant de réflexion. Vous devez prendre le temps de bien définir les priorités.

Prioriser les opportunités

L’utilisation d’un système de notation peut aider à considérer chaque facteur d’une opportunité avec une discipline lucide et à combiner ces facteurs de manière rigoureuse et cohérente.

L’utilisation d’un système de notation pour aider à créer une hiérarchie n’est certainement pas une nouveauté. Les systèmes conçus pour équilibrer les coûts et les avantages abondent. Mais vous pouvez avoir du mal à en trouver un qui vous permette de comparer utilement différentes opportunités de manière cohérente.

En réponse, nous utilisons traditionnellement sur nos projets quatre facteurs et une méthode pour les combiner. RICE est un acronyme pour les quatre facteurs que nous utilisons pour évaluer chaque opportunité en matière de Portée (Reach), d’Impact (Impact), de Confiance (Confidence) et d’Effort (Effort).

• Reach : Consiste à estimer le nombre de personnes que chaque produit, composants ou fonctionnalités affectera au cours d’une période donnée. Sur combien de personnes cela aura-t-il un impact ? (Estimation dans une période de temps définie, ce nombre peut être exprimé en valeur absolue ou en % de la population totale.)
• Impact : Consiste à estimer quel sera l’impact pour chaque personne ? (Massif = 3x, Haut = 2x, Moyen = 1x, Faible = 0,5x, Minimal = 0,25x.).
• Confidence : La confiance est un pourcentage qui utilise une échelle à choix multiples pour éviter la paralysie décisionnelle et freiner l’enthousiasme des idées passionnantes mais mal définies. Dans quelle mesure êtes-vous confiant dans vos estimations ? (Élevé = 100%, Moyen = 80%, Faible = 50%.)
• Effort : Consiste à estimer le temps total qu’un projet exigera de tous les membres de votre équipe – combien de «personnes-mois» cela prendra-t-il ? (Utilisez des nombres entiers et au moins un demi-mois)

Une fois que vous avez estimé ces facteurs, combinez-les en un seul score afin de pouvoir comparer les projets en un coup d’œil.

Voici la formule simple :

RICE Score : (Reach x Impact x Confidence) / Efforts

Le score qui en résulte mesure « l’impact total par temps travaillé » – exactement ce que nous souhaitons maximiser. Une fois la notation initiale effectuée, triez votre liste et réévaluez-la.

Y a-t-il des opportunités où le score semble trop élevé ou trop faible ? Si tel est le cas, reconsidérez vos estimations et apportez des modifications, ou acceptez que votre instinct puisse être erroné.

Prioriser les solutions

Pour presque tous les problèmes, il existe une variété de solutions. Il est important de recentrer les connaissances et les preuves recueillies à partir des travaux de compréhension du problème en particulier celles qui ont aidé à déterminer si une hypothèse de risque a été validée ou non, pour recentrer l’équipe.

Bien que nous ayons volontairement restreint la liste des opportunités sur lesquelles recentrer nos efforts de design de la ou des solutions, trouver la solution nous oblige à aller plus loin. À ce stade, nous n’essayons pas de concevoir le produit dans son intégralité, mais plutôt de générer de nombreuses solutions possibles qui adressent le problème prioritaire unique.

Les exercices d’esquisses collaboratifs, au sein d’un Design Sprint, sont un moyen d’utiliser la créativité collective de l’équipe pour générer rapidement de nombreuses options pour des fonctionnalités clés en réponse aux opportunités identifiées.

Notons qu’à ce stade, une solution ne s’exprime pas forcément uniquement à travers un parcours utilisateur composé d’une suite d’écrans. L’adaptation des processus internes back-office qu’ils soient commerciaux, support, ou de gestion, une meilleure intégration avec votre écosystème applicatif ou encore une adaptation de votre architecture technique peuvent fournir de meilleures solutions ou faire partie de la solution et doivent aussi être explorées.

Une fois ces travaux de génération de solutions effectués en collaboration avec les équipes d’ingénieurs (développeurs), il s’agit une nouvelle fois de les prioriser avant de décider de leur lancement en développement.

La « matrice de priorisation » ci-dessous, est utilisée dans la communauté du design thinking pour désigner une variété de techniques et de représentations de priorisation qui, techniquement, ne sont pas toutes qualifiées de matrices au sens mathématique.

Nous l’utilisons sur nos projets pour effectuer la priorisation des fonctionnalités à développer. Comme évoqué, ce travail est collaboratif entre les Product Managers, les ingénieurs et/ou développeurs. Il consiste à évaluer en équipe les solutions et à les prioriser au regard de l’impact sur l’utilisateur final et l’effort de développement ou faisabilité technique.

• Définissez les solutions que vous souhaitez prioriser et écrivez-les sur des notes autocollantes individuelles.
• Ensuite, définissez les critères en fonction desquels vous effectuerez la hiérarchisation.
• Échangez avec les équipes, priorisez les différentes solutions sur la base des critères d’impact sur l’utilisateur et de faisabilité technique.

A l’issu de cet exercice vous disposez d’un backlog de fonctionnalités estimées et priorisées prêtes à être développées au cours des sprints de développement agile.

Deciding what not to do is as important as deciding what to do

Steeve Jobs

Lorsque plusieurs équipes de livraison travaillent sur le produit et ses différentes couches, avec différents objectifs techniques et niveaux de complexité (équipe d’application frontale, équipe back-office, équipe API, équipe d’ingénieurs de données et équipe d’architecture informatique), l’exercice de synchronisation peut devenir un cauchemar dû aux nombreuses dépendances entre équipes.

Dès lors comment synchroniser de larges équipes de développement, gérer les dépendances inter-équipes ?

Le Release Planning Days (RPD) vise à compresser les exercices de priorisation, de synchronisation et de gestion des dépendances entre les équipes, en concentrant le maximum d’interactions sur 1 ou 2 journées pour établir de façon concertée entre les équipes, les bases d’un plan de livraison global d’entreprise cohérent et réalisable au cours de la prochaine release de développement (traditionnellement release trimestrielle mais peut également s’échelonner sur des temps plus court).

Vous trouverez ci-dessous une représentation type de l’organisation d’une journée de Release Planning Days entre plusieurs équipes de développement.