« Encore un daily de 30 minutes… »

« C’est quoi ce nouveau template de User Story ? »

« Quoi ? Il y a une Rétrospective après la Sprint Review ? Donc j’aurai passé mon après-midi en réunion… »

« Ce n’est pas le Scrum le problème, c’est qu’il est mal appliqué »

On vous épargne le reste des plaintes qu’on entend régulièrement dans les projets menés en suivant des pratiques dites « Agile ».

 

D’ailleurs, qu’est-ce que l’Agile ?

Des sprints ? Des User Stories ? Des cérémonies ? C’est ce qu’on vous a appris en formation ? On vous a menti.

L’Agile c’est un ensemble de principes. Ca tient sur une page web. Vous ne nous croyez pas ? Voilà le lien, c’est toujours en ligne : manifesteagile.fr

Quand on relit le manifeste et qu’on le confronte à la réalité des pratiques, l’écart est souvent … étonnant.

Dans cet article, on a décidé de vous partager les réflexions engagées par VIGGO depuis maintenant 5 ans. On a tellement réfléchi qu’on en a construit une méthode et un outil pour aider à la mettre en application.

Ici on ne vous parlera que de la méthode mais si vous voulez en savoir plus sur l’outil, n’hésitez pas à consulter notre site (noaxp.com) et notre page Linkedin.

 

Repenser le rôle de Product Owner

Selon le Scrum, le cadre de travail Agile le plus utilisé aujourd’hui (et non ce n’est pas du tout le seul), un bon Product Owner c’est quoi :

• Une personne disposant d’une bonne connaissance des utilisateurs et de leurs métier
• Une personne disposant d’un pouvoir de décision suffisant pour prioriser le travail d’une équipe de développement
• Une personne capable de dédier la quasi-totalité de son temps pour gérer un backlog d’US (c’est-à-dire les rédiger, les expliquer, les tester et en faire la démo une fois développée).
• Une personne capable de dialoguer tant avec des équipes techniques qu’avec des équipes métiers.
• Une personne capable de défendre et d’assumer ses choix auprès des sponsors et des utilisateurs.

Vous le voyez le mouton à 5 pattes ? C’est souvent pour cette raison qu’un Proxy-Product Owner est recruté et fini par se substituer au Product Owner, notamment dans le dialogue avec l’équipe technique.

Dans notre méthode, nous revenons à la base de ce que doit être le Product Owner : le représentant des utilisateurs. Sa responsabilité : porter la voix des utilisateurs.

Concrètement, on lui fournit des outils digitaux et méthodologiques pour collecter et rendre compte efficacement les besoins des utilisateurs. Grâce à cet accompagnement, même un Product Owner débutant peut être en mesure de collecter et de traduire les besoins utilisateurs efficacement.

Le Product Owner dialogue ensuite avec une Squad qui sera responsable de l’implémentation du produit. Comment fonctionne la Squad ? On vous l’explique juste après !

 

Adieu la pizza team, bonjour la Squad Delivery

Une Squad, c’est une équipe de 4 personnes, ni plus, ni moins. Pourquoi pas plus ? Car nous avons observé qu’au-delà, la productivité globale des équipes était réduite. Et pour une raison simple : plus le nombre de membres d’équipe est important, plus on passe du temps à transmettre des informations.

La Squad doit disposer des compétences suivantes :

• être en mesure de concevoir des solutions aux problèmes exprimés par le PO et être en mesure de les implémenter ;
• savoir documenter et tester les développements réalisés ;
• savoir animer et piloter un chantier de développement.

Maintenant comment priorise-t-on le travail d’une Squad ?

 

Priorité aux parcours utilisateurs

La Squad doit délivrer rapidement de la valeur aux utilisateurs. Pour ce faire on décide de décomposer le travail en parcours utilisateurs.

Un parcours, c’est un process que doit pouvoir suivre un utilisateur de bout en bout. Par exemple, dans le cas d’une application de gestion de projet, on peut avoir les parcours utilisateurs suivants :

• Initier un projet
• Définir le planning d’un projet
• Préparer le prochain comité projet

Chaque parcours est décomposé en étape. Pour chaque étape on définit la liste des fonctionnalités à développer pour l’implémenter.

La Squad est chargée d’implémenter les parcours utilisateurs les uns après les autres. Une fois toutes les fonctionnalités nécessaires à un parcours développées on les met à disposition des utilisateurs.

Un des points importants de la démarche, c’est la nécessité de ne pas attendre l’implémentation parfaite pour mettre en exploitation. L’important est de pouvoir dérouler le parcours de bout en bout. Les utilisateurs peuvent ensuite indiquer les optimisations souhaitées.

Cette approche a plusieurs bénéfices : on apporte très régulièrement de la valeur visible aux utilisateurs et ces derniers se sentent plus impliqués dans le processus de création.

Comment on organise le delivery de ces parcours ?

 

Une proximité renforcée de la Squad avec les utilisateurs

Le développement d’un parcours utilisateurs est jalonné d’ateliers d’implémentation qui rassemblent la Squad et des Key Users. Au cours de ces ateliers on peut réaliser les activités suivantes :

• Conception des réponses aux besoins exprimés
• Prototypage et test en direct des solutions proposées
• Test en commun des développements réalisés

On réalise a minima 1 atelier par semaine. Cela permet de garantir une proximité et une réactivité très forte aux besoins des utilisateurs.

Et ça marche vraiment cette méthode ?

 

Les verbatims de nos clients

Voici ce que les premiers témoins de cette méthode ont pu nous partager après l’expérimentation de notre démarche :

• « Les outils et méthodes utilisés par VIGGO nous ont permis de facilement exprimer et formaliser nos besoins. Grâce à cela, les porteurs de projets qui n’étaient pas complétement familiers de la conception d’application ou du métier de Product Owner en mode agile ont pu produire des entrants de qualités pour les équipes de delivery. »
• « La démarche proposée par VIGGO a également permis d’optimiser le temps des équipes projets. Contrairement aux approches traditionnelles, le cérémonial simplifié a permis à nos équipes métier de concentrer leurs efforts sur les tâches pour lesquelles elles avaient une forte valeur ajoutée, sans perte de qualité et d’information avec un très bon niveau d’interaction et de réactivité. »
•  « Les ateliers de prototypages qui ont cadencé le projet ont également permis d’adapter en continu les priorités. Ces ateliers nous permettaient de tester plusieurs réponses aux besoins, de se projeter plus facilement et de valider plus rapidement sur des bases concrètes les solutions retenues. »
• « La proximité physique des acteurs projets et la taille limitée de l’équipe (2 développeurs, 1 concepteur, 1 PO et 1 PM) ont permis de fluidifier les échanges. Le niveau de confiance et de motivation  de l’équipe sont restés élevés durant toute la durée du projet. »
• « Globalement, nous avons considérablement augmenté notre rythme de delivery, tout en délivrant une application robuste et alignée avec les besoins utilisateurs. »

 

Évidemment, on ne vous a pas tout révélé dans cet article, on garde aussi quelques secrets pour nous 😊

Si vous voulez en savoir plus sur notre méthode et la tester dans votre organisation, n’hésitez pas à contacter Nicolas Declerck ou Pascal Zimmermann