search mail facebook github rss rss twitter google + cross linkedin

Ils m’entrainent au bout de l’agile

Aujourd’hui, de nombreuses méthodes Agile se côtoient. Laquelle choisir ? Plusieurs éléments sont à prendre en compte : la maturité du produit et de l’équipe, la taille de cette équipe et de l’entreprise, le type d’organisation qui prédomine, etc. Dans tous les cas, l’objectif est toujours le même : réaliser des produits numériques qui répondent au mieux aux besoins des utilisateurs, par nature, évolutifs.

À la Fabrique numérique, nos produits et les équipes qui les développent ont évolué au cours du temps. Nous avons donc dû faire évoluer leur organisation pour rester le plus efficace possible.

En règle générale, les équipes sont composées d’un UX designer, de deux ou trois développeurs, de l’intrapreneur (le référent métier) et, dans la plupart des cas, d’un product manager. Ainsi, de par la taille de l’équipe et le besoin de créer un produit de zéro, nous nous sommes orientés vers une approche plutôt Lean Startup avec une gestion produit par kanban.

Dans les premiers temps, nous avons délibérément fait le choix de ne pas appliquer de méthode scrum parfois trop dogmatique et dans ce cas trop stricte.

Ainsi nous ne faisions pas de cérémonies à proprement parler, pas de daily institués, pas de rétro, pas de grooming, juste une à deux réunions hebdomadaires au cours desquelles nous planifions les priorités dans les tickets, faisions le point sur les développements réalisés, et prévoyons les prochains tests utilisateurs. Ce format fonctionne bien lorsque les équipes sont petites et autonomes et que l’objectif est d’aller vite et d’expérimenter pour trouver la bonne solution. Le présentiel est également un atout pour communiquer rapidement même si les messageries d’entreprise peuvent en partie compensées la distance.

En revanche, et pour en avoir fait l’expérience, cette organisation connaît rapidement ses limites. La situation devient compliquée lorsque qu’il y a :

  • Plus de quatre développeurs.
  • Une différence de niveau importante (juniors vs. senior) autant dans la technique, que dans l’autonomie et la méthode de développement.
  • Un éloignement géographique des équipes.

Dès lors, la communication est moins fluide, des incompréhension apparaissent et des frustrations peuvent s’accumuler. La méthode scrum avec ses cérémonies apporte alors sa valeur ajoutée : offrir un cadre de développement produit permettant une meilleure communication et un meilleur niveau d’échange d’information.

Aujourd’hui, nous avons donc plusieurs organisations en fonction des produits et de leur maturité. Nous n’utilisation pas encore d’estimations (dans le sens scrum) car nos produits et nos équipes n’en ont pas encore éprouvé le besoin mais cela viendra sûrement à un moment.

Quoiqu’il en soit, le choix dans la méthode ou l’organisation de l’équipe produit importe peu tant que celles-ci permettent de s’adapter rapidement aux besoins utilisateurs et marché, en particulier en évitant des procédures trop rigides où innover et pivoter devient complexe.

Que l’on soit lean, scrum, kanban ou un peu tout à la fois, l’organisation n’est que le moyen privilégié qui permettra à l’équipe d’avancer dans la même direction. L’organisation la plus méthodique, la plus agile ou la plus rigoureuse n’atteindra pas son vrai potentiel sans :

  • Une vision claire du produit et de sa cible comprise et partagée par l’ensemble des membres de l’équipe.
  • Des principes produit et des objectifs court et moyen termes compris et partagés par l’ensemble des membres de l’équipe.
  • Une proximité et une fréquence d’interaction importante avec les utilisateurs, non seulement du PM et de l’UX mais également des développeurs.

Dans la même catégorie