Org Topologies & Stratégie Kanban pour augmenter son agilité business - 5ème et dernier volet

Chapitre 5 : Une bonne idée qui se transforma en dépendance pendant quelques temps

Cet ajout amena une dépendance et malheureusement un ralentissement global du système.

En effet, cette équipe avait, elle aussi, son propre workflow déconnecté de celui de la Scrum Team. Le Product Owner travaillait en amont avec cette équipe UX externe pour comprendre plus précisément les attentes et les problématiques des clients. Ils réalisaient des prototypes, faisaient des tests utilisateurs avec ces prototypes. Cela malheureusement, prenait pas mal de temps.

Paul se souvient bien de cette période, frustré de ne pas mettre à profit ses nouvelles compétences acquises : 

“Ils étaient assez haut niveau dans la macroconception de la solution et nous avions toujours besoin lorsque nous récupérions leurs travaux de faire de l'affinage, de découper les grosses features en plus petits morceaux pour avancer itérativement et incrémentalement comme nous avions pris l’habitude de faire. De plus, il n'était pas rare que les prototypes qu’ils avaient testés avec les utilisateurs, nous posaient problème en termes de faisabilité pour les mettre en œuvre.

Nous étions dans un silo discovery/delivery.”

Cette volonté de mieux cerner les attentes des clients était louable, car il est vrai qu’il est dommage de développer des choses qui ne sont pas attendues, qui ne vont pas être utilisées, qui vont poser des problèmes d’utilisabilité, mais tout cela avait un coût, et finalement le T2M, le temps de cycle pour livrer des évolutions sur le produit était beaucoup plus court avant.

Paul et l’équipe avaient réussi à savoir combien de temps il s’était écoulé avant qu’un sujet ne leur parvienne : 

“Il faut voir que grosso modo avec l'ajout de cette équipe UX/UI externe c'était ~ 2 mois de temps de cycle passé avant que nous récupérions la patate chaude (enfin tiède, voire presque froide, au vu du délai déjà passé).

La véritable connaissance de ce que nous apportions comme valeur était du coup retardée de ~ 2 mois, mais nous avions potentiellement quelque chose avec un plus haut niveau d'utilisabilité et quelques hypothèses à valeur faible écartées.

La principale problématique à mon sens était la déconnexion du discovery et du delivery, accentuée par le fait que ce n'était que des travaux amont et jamais cet UX Team ne s'appuyait sur le concret en production et dans les mains des utilisateurs pour fermer la boucle d'apprentissage amenant à de nouvelles réflexions UX pour faire évoluer le produit.”

Dans ce positionnement finalement uniquement orienté “business”, dans le sens où ce prestataire répondait à la commande de “discovery” initiale du Product Owner mais sans refermer la boucle d'apprentissage avec le véritable produit et le comportement des utilisateurs en situation réelle, l’organisation était loin de tirer bénéfice de l’UX design.

Paul et les autres personnes de l’équipe qui avaient été formés, avaient bien conscience que le prestataire aurait pu ou aurait dû proposer plus. 

Ils avaient perdu une bataille avec l’arrivée de cette équipe UX externe, mais décidèrent de ne pas en rester là. Ils installèrent un outil leur permettant de réaliser de l’analytique produit et ils commencèrent discrètement à analyser les parcours, l’utilisation des fonctionnalités, les points de décrochage, ils mirent des heatmap en place pour voir plus finement dans les pages où circulaient les utilisateurs…

Paul nous raconte : “Toutes ces informations étaient extrêmement précieuses, car source d’apprentissage de l’utilisation réelle de notre produit. Je ne comprends toujours pas pourquoi la société d’expert UX n’a pas proposé cela et s’est contentée de ce “discovery” initial, mais bon cela finit finalement par faire notre bonheur. En effet, un jour, nous décidâmes avec quelques autres membres de l’équipe que nous avions suffisamment de billes via les analytiques produits pour ouvrir des discussions sur des fonctionnalités inutilisées, des parcours à améliorer, etc.

Pour les parcours que nous avions détectés à améliorer, nous avions fait quelques maquettes de faible fidélité (peu coûteuses) pour proposer des améliorations et avoir un support de discussion. Des éléments qui paieront, car très appréciés des parties prenantes, de la direction et qui permirent d’asseoir notre expertise également en la matière”.

La mission du prestataire UX se termina quelques semaines après et la direction, le Product Owner décidèrent de s’en remettre à l’expertise que l’équipe avait prouvée avoir acquise, en tout cas suffisamment pour ne plus voir le gain à payer une prestation.

Ceci amena une évolution du workflow de l’équipe sur 2 aspects.

Premièrement, l’équipe (y compris le Product Owner) décida que le point de fin n’était plus le passage en production pour que le client ait le produit dans les mains. Le point de fin serait maintenant au-delà de cela et se situerait lorsque la collecte du feedback de l’utilisation de la fonctionnalité serait jugée suffisante. Soit pour décider de terminer, soit pour décider de terminer, mais en apportant un nouvel élément en entrée du workflow lié au feedback et à l’apprentissage obtenu de l’utilisation du produit.

Deuxième évolution du workflow sur les aspects de “discovery”. Paul avait suivi récemment la formation Professional Scrum With UX (PSU) et avait compris clairement le concept de dual track agile. En résumé ce concept est le mélange délicat et en continu entre ce qui est nécessaire d’apprendre en amont pour éviter de développer des choses qui ne seraient pas utilisées (ou trop peu) et le développement rapide, se basant sur cet apprentissage, de petits incréments, dans un but également d’apprentissage et de réalimentation de la boucle à l’aide de ces nouvelles connaissances.

Ce n’est pas comme beaucoup ont pu le comprendre (et le comprennent peut-être encore), deux processus parallèles, menés par des personnes différentes et qui s’alimentent en discontinuité, en séquentiel (les travaux de discovery des 2 dernières semaines, alimentant le delivery des 2 semaines suivantes), sans tenir compte en continue des apprentissages réalisés au travers de chaque “prisme”.

Avec ces connaissances nouvellement acquises, Paul amena la proposition d’une expérimentation à l’équipe pour visualiser au niveau du workflow ce travail de discovery.

“En product management agile, il est crucial de savoir le plus rapidement possible si on a tort, il était donc hors de question pour moi d’amener l’idée d’avoir des éléments de discovery qui circuleraient à côté des éléments de delivery et à faire avant de pouvoir progresser sur le delivery. La majorité du temps, il fallait que ces travaux soient liés au même élément de valeur, pour que cela soit vu comme un tout, où toute l’équipe restait responsable de faire progresser l’élément le plus rapidement possible vers la fin de notre workflow. 

Mais d’un autre côté, parfois il pouvait s’avérer nécessaire de faire des études plus poussées et plus longues pour s’assurer que l’hypothèse de valeur était à priori “viable”.

J’amenais donc l’expérience suivante à tenter : 

• La création d’un nouveau type d’élément de valeur qui circulerait dans notre workflow que j’appelais “Etude (discovery)” et qui allait correspondre à ces travaux de discovery plus longs à mener.
• Pour le reste, je proposais au reste de l’équipe de considérer l’apport des pratiques UX dans les différentes étapes de notre workflow :
  • En affinage, par exemple en ayant rapidement fait une interview de quelques utilisateurs, ou en ayant prototypé rapidement sur le papier quelque chose pour le confronter également à quelques utilisateurs. Ceci nous permettait de démarrer le développement informatique avec quelques améliorations ou ajustements de la solution qu’on envisageait.
  • Pendant le développement et quand cela faisait sens (notamment quand émergeait des interrogations sur l’utilisabilité), on allait continuer à explorer si la solution était adéquate, par exemple sur la base d’un prototype de plus haute fidélité.
  • Lorsque nous arrivions à l’étape de recette, on allait approcher des utilisateurs finaux pour les faire manipuler la nouvelle fonctionnalité et vérifier notamment des points où nous avions des doutes sur l’utilisabilité.”

Ces propositions furent jugées intéressantes et l’équipe s’embarqua dans cette expérimentation.

Pour le nouveau type d’élément “Etude discovery”, l’équipe se challengea avec un SLE associé. Ils ne voulaient pas eux même ramener la mauvaise expérience vécue avec le cabinet d’expertise UX externe et décidèrent que cela devait être réalisé la majorité du temps (80%) dans un laps de temps ne dépassant pas les 15 jours.

Le workflow* pouvait se représenter de cette façon :

L’expérience fut très concluante et renforça encore les liens et la pluridisciplinarité de l’équipe. En effet, des membres qui ne s’étaient pas formés à l’UX Design découvrirent et montèrent en compétence en travaillant de concert avec leurs collègues, l’expertise n’était pas au même niveau, mais cela permettait de réaliser des travaux d’UX ne demandant pas une très grande expertise (récolter des impressions, des feedback sur les maquettes, les proto, par exemple) par quasiment n’importe qui de l’équipe.

Toutes ces évolutions, rapprocha l’équipe de plus en plus des utilisateurs finaux, la confiance de la direction dans l’équipe était excellente, son efficacité s’était accrue drastiquement et sa prédictibilité également. Le Product Owner (et une bonne partie de l’équipe) avait été formé sur l’utilisation de leurs données de débit (factuel) pour réaliser des prédictions probabilistes via une simulation de Monte Carlo, qui donnait des résultats beaucoup plus justes et pertinents.

La confiance du marketing et des commerciaux s’en trouvait également largement améliorée et les tensions qui pouvaient exister dans le passé, avaient disparu totalement. 

Le Product Owner était de plus en plus intégré également à l’équipe, fort de cette expérience et des résultats obtenus, il se vit offrir une opportunité très intéressante dans une autre entreprise qu’il saisissa. 

La direction savait qu’elle pouvait compter sur Paul pour le remplacer et lui offrir cette opportunité, qu’il ne se fit pas prier pour accepter.

A ce moment là, l’organisation pouvait se décrire de cette manière : 

Paul, depuis ce jour, soutenu par le reste de l’équipe tente de résoudre une difficulté freinant encore assez amplement l’efficience de l’équipe à délivrer de la valeur : l'existence de cette unité de gestion de la production et de l’infrastructure technique.

En effet, l’équipe Scrum est toujours dépendante de cette unité pour pouvoir voir les développements réalisés disponibles en production, ce qui leur fait perdre quelques jours avant que les nouveautés ne soient disponibles et qu’ils puissent en tirer des apprentissages.

Lorsqu’ils auront réussi à avoir le pouvoir, les droits, les habilitations pour eux même livrer leurs produits, ils seront réellement devenus une Scrum team autonome et pouvant délivrer en flux continu et rapide des nouveautés et améliorations sur leurs produits.

Il est à espérer pour eux qu’ils y arriveront et lorsque cela sera le cas l’organisation dans cette business unit pourra se cartographier de la façon suivante : 

THE END… ou pas, ça dépendra de votre réaction à vous les lecteurs ;-)

Un grand remerciement à Alexey Krivitsky et Roland Flemm pour avoir créé Org Topologies et leur incroyable classe que j’ai eu la chance de suivre sur Paris en Mars 2024, ainsi qu’à leurs différents feedbacks, précisions et éclaircissements à apporter à cette histoire avant que je ne la publie. 

N’hésitez pas à vous intéresser à leur travail ici : https://www.orgtopologies.com/

et à aller en apprendre plus sur Org Topologies avec eux dans l’une de leur formation.

L'histoire complète en un seul bloc est disponible ici au format pdf.

Consultez mes classes certifiantes à mon catalogue sur la stratégie Kanban, je peux aussi enseigner les classes ASPK et APV du catalogue de ProKanban. Contactez-moi pour arranger une classe privée inter-entreprise, ou si vous voulez suivre une classe publique mais n'avez pas les moyens de vous l'offrir.