[Astuces] Deux outils « visuels » qui peuvent servir

Depuis bientôt 3 mois, j’ai rejoins Pyxis Technologies à Montréal en tant que Scrum Master/Coach d’équipe. Dans le cadre de mon arrivée, j’ai eu l’opportunité d’accompagner plusieurs Coachs Agiles dans leur quotidien et de suivre plusieurs formations  (j’envisage de raconter ce retour d’expérience plus en détail dans un prochain article)

Je souhaite partager ici 2 outils que j’ai découvert et particulièrement apprécié, par leur côté pratique et facilement réutilisable.

1. Organisation : Vers quelle méthodologie Agile s’orienter et pour quel contexte ? 

Agilité_Equipe_Organisation

Lorsqu’on souhaite optimiser le cadre de travail d’un ou plusieurs produits ou projets complexes, les méthodes Agiles peuvent apparaître comme une opportunité. Mais avec Scrum, Kanban, Scrumban, XP, SAFe, LeSs, Nexus… etc., elles regorgent de modèles et d’outils et il est parfois difficile de s’y retrouver ou d’identifier le framework qui se prêterait le plus au contexte et aux besoins.

Ce graphique est un moyen mnémotechnique qui permet de cerner facilement quelle méthodologie pourrait être appropriée, en fonction de l’organisation « Produit(s) »/ »Equipe(s) ».

▪ 1 équipe travaille sur 1 produit : Expérimentez Scrum
▪ 1 équipe travaille sur plusieurs produits : Une approche Kanban pourrait être plus adaptée
▪ Plusieurs équipes travaillent sur 1 même produit : Tournez vous plutôt vers un framework qui permettrait d’adopter une approche Agile à plus grande échelle.
▪ Plusieurs équipes travaillent sur plusieurs produits : Aïe, là ça risque d’être plus compliqué… 😉

.

2. Aide à la priorisation : Le graphique « Valeur vs Risque »

Value_Risk_Chart

Ce deuxième outil m’a paru très utile pour les Product Owners, et à la fois très simple. Il permet de positionner les éléments du carnet de produit (Product Backlog) selon 2 axes : Valeur et Risque.

  • Echelle de Valeur :
    – Quelles sont les fonctionnalités qui pourraient apporter le plus de Satisfaction aux utilisateurs ?
    – Quelles sont celles qui seraient les plus intéressantes d’un point de vue Retour sur Investissement ?
    – […]
  • Echelle de Risque :
    – Quelles sont les fonctionnalités qui impliquent des dépendances avec d’autres équipes/applicatifs ?
    – Quelles sont celles dont la complexité est inconnue ?

En bref, ce graphique permet de visualiser les éléments du backlog selon 2 variables, afin d’avoir une vue globale et relative entre tous les éléments (on pourrait remplacer l’axe « risque » par « effort » si cela fait plus de sens…).

Une fois que tous les éléments du carnet de produit sont positionnés, il est plus aisé de prioriser les éléments. Par exemple :

  1. Commencer par développer les fonctionnalités qui apportent le plus de valeur et qui entraînent le plus de risques (ainsi, l’aspect risque pourrait être écarté rapidement…?).
  2. Ensuite, celles qui apportent encore beaucoup de valeur et moins de risques.
  3. Si le budget et le délai le permettent, terminez par les fonctionnalités qui apportent peu de valeur mais sont sans risques.
  4. Les fonctionnalités qui apportent peu de valeur et entraînent beaucoup de risque n’ont pas lieu d’être développées ( le retour sur investissement serait proche de zéro voire négatif).

 

En conclusion, deux outils simples et visuels, que chacun est libre de s’approprier et d’adapter à son contexte.

Ils n’ont pas pour objectif de dicter une manière de faire, mais plutôt d’apporter un support à la réflexion, sur l’organisation d’une équipe ou la priorisation des fonctionnalités d’un produit.

 

Comments 4

  1. Félicitations Lucy pour ton nouveau poste à Montréal.
    Merci pour ce partage, je n’avais pas pensé à ces 2 matrices qui peuvent être utiliser en atelier.
    Est-ce que tu m’autorises à relayer cet article sur mon blog : oeildecoach.com ?

    1. Post
      Author
  2. Bonjour Lucy,
    Tout d’abord, super ce billet, j’adore le 2e outil visuel qui est top pour prioriser.
    Concernant le 1er outil : pouvez-vous définir une équipe ? Dans le milieu startup, j’ai souvent rencontré une orga de ce type : on a souvent des personnes qui travaillent sur des produits différents mais qui forment une équipe de développement avec pas mal de dépendances/interactions. A titre d’exemple : 5 dévs fullstack, 2 dévs pour le dév des app mobile avec 1 PO pour 2 apps mobile, 1 site web et 1 backoffice.
    Merci d’avance pour votre réponse 🙂
    PS/ J’ai beaucoup de mal avec les fwk pour « agiliser à grande échelle » 🙂

    1. Post
      Author

      Bonjour Amel,
      Par « équipe », j’entends une équipe de développement composée de plusieurs membres qui travaillent sur un ou plusieurs objectifs commun(s) et qui s’entraident pour les atteindre.
      Dans le cas que vous mentionnez, l’équipe de développement travaille sur plusieurs produits (ou un produit qui est décliné sous plusieurs formes : les fonctionnalités sont (sans doute) les mêmes mais le canal pour y accéder change. l’organisation peut donc être fastidieuse et l’utilisation d’une approche Kanban pourrait faciliter les choses. L’avantage dans le cas que vous mentionnez, est que le PO est le point de coordination central et le garant des priorités, qui s’assurera que l’équipe ne fonctionne pas en « girouette »
      Bonne journée !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *