DESIGN THINKING ET AGILITÉ À L’ÉCHELLE : UNE BONNE ALLIANCE !

DESIGN THINKING ET AGILITÉ À L’ÉCHELLE : UNE BONNE ALLIANCE !

Des philosophies proches, des logiques collaboratives, des approches itératives, la mise en place d’équipes multidisciplinaires et un souci constant de placer l’utilisateur au cœur de la démarche de conception : sur beaucoup de points, Design Thinking et Agilité partagent de grandes similitudes.

Si le Design Thinking consiste à favoriser l’identification du « vrai » besoin et la solution à y apporter (le « Quoi »), l’agilité se concentre principalement sur la façon de mettre en œuvre cette solution (le « Comment »). Toutes deux complémentaires (le Design Thinking étant une très bonne façon d’amorcer une démarche Agile), ces deux approches permettent de s’assurer le plus tôt possible via des retours utilisateurs que le produit développé répondra réellement aux besoins de ceux-ci, en évitant gaspillages d’argent et efforts inutiles.

Si l’association entre une approche Design Thinking et un accompagnement Agile reste relativement simple à mettre en œuvre au niveau d’une seule équipe, qu’en est-il dans un contexte d’agilité à l’échelle où plusieurs équipes agiles sont amenées à collaborer ? Dans cet article, nous nous baserons sur le modèle d’agilité à l’échelle SAFe afin de voir comment il est possible d’y insérer une approche Design Thinking pour rendre vos efforts de développements encore plus efficaces.

UNE ALLIANCE DU BON SENS

Une image vaut mille mots. Le Design Thinking qui met en avant le prototypage sommaire de solutions (via le sketching ou le wireframing notamment) constitue une démarche extrêmement efficace pour rendre tangibles les périmètres et apparences physiques du produit à développer, faciliter la compréhension entre équipes et aligner la vision de celles-ci. Par définition, un contexte d’agilité à l’échelle induit que plusieurs équipes agiles soient impliquées. Plus le nombre d’équipes va être important, plus l’information sera diffuse entre les équipes, plus il sera crucial que chacune d’entre elle ait une vision claire et partagée du produit à développer. C’est une question de bon sens !

A ce sujet, on peut regretter le nombre encore trop faible d’équipes agiles prenant le réflexe d’afficher sur les murs des plateaux de travail les wireframes et/ou maquettes représentant les interfaces en cours de réalisation. Les bénéfices en termes de compréhension et de qualité d’échanges sont pourtant énormes.

UNE ALLIANCE PERTINENTE POUR GÉRER SON PORTFOLIO BACKLOG

Le Design Thinking a toute sa place dans le modèle SAFe au niveau de la gestion du Portfolio Backlog auquel il est recommandé de faire appel à un tableau de suivi très simple (appelé « Portfolio Kanban ») représentant les étapes principales pour concevoir, développer et déployer un nouvel Epic.

Six étapes composent le Portfolio Kanban : « Funnel » (liste de mes Epics), « Review » (Premier niveau d’analyse sommaire des Epics), « Analysis » (niveau plus poussé d’analyse des Epics avec décision d’investir ou non), « Portfolio Backlog » (Epics validés et priorisés), « Implementation » (développement des Epics), et « Done » (Epics réalisés).

C’est en général à l’étape « Analysis » que les organisations décident d’investir (parfois plusieurs millions d’euros) ou non dans un Epic. Il convient donc de faire un choix éclairé et à ce titre, effectuer une session de Design Thinking pour tester la faisabilité et la désirabilité de l’Epic à un niveau macro constitue une option fiable, rapide et économique afin de s’assurer que ce que nous comptons développer corresponde bien à un réel besoin de la part des utilisateurs. Sur le Portfolio Kanban, les étapes « Review » et « Analysis » seront particulièrement adaptées pour accueillir des sessions de Design Thinking dans l’optique d'optimiser, une fois de plus, vos efforts de développements.

UNE ALLIANCE POUR APPORTER PLUS DE CRÉATIVITÉ DANS VOS FEATURES 

Aucun texte alternatif pour cette image

À un niveau plus micro, le modèle SAFe évoque l'exploration continue (« Continuous Exploration ») qui est le processus consistant à explorer en permanence les besoins du marché et des utilisateurs afin de définir une vision, une feuille de route et un ensemble de fonctionnalités (« Features ») répondant à ces besoins. C'est la première étape du pipeline de livraison continue d’un train Agile (« Agile Release Train ») structuré en quatre parties, et précédant l’intégration continue (« Continous Integration »), le déploiement continu (« Continuous Deployment ») et la « livraison à la demande » (« Release on Demand »).

Lors de cette exploration continue, les équipes sont invitées à émettre des hypothèses de bénéfices (« Outcomes hypothesis »), initier une démarche de conception collaborative (« Collaborative Design »), construire un MMF (« Minimum Marketable Feature ») et à en évaluer le résultat (« Evaluate ») pour savoir si la fonctionnalité répond réellement aux bénéfices que nous nous étions fixés. Plus que jamais à cette étape, l’adoption d’une démarche de Design Thinking sera particulièrement judicieuse. Le modèle SAFe a d’ailleurs bien intégré cette connexion en remplaçant le terme « UX » (utilisé dans la version 4.0) par le terme « Lean UX » dans la version 4.5 (pour rappel, Jeff Gothelf englobe à la fois Lean Startup, Design Thinking et développement agile pour définir la notion de « Lean UX » dans son livre « Lean UX »).

Dans un contexte d’agilité à l’échelle, le Design Thinking semble donc particulièrement adapté. Que ce soit pour aligner la vision de toutes les équipes impliquées, prioriser le Portfolio Backlog ou définir avec plus de précision les Features, il constitue une approche économique, fiable et rassembleuse pour mettre sur le marché dans les meilleures conditions et le plus rapidement possible des livrables à forte valeur ajoutée pour les utilisateurs. Nous ne pouvons donc que nous réjouir que le modèle SAFe ait pleinement pris la mesure de la force de cette alliance en allant jusqu’à réserver spécifiquement une itération (« Innovation and Planning Iteration ») lors de chaque Program Increment (« PI ») pour permettre aux équipes d’innover. Mais au-delà de la théorie, c’est désormais aux grandes organisations de prendre le relais pour implémenter de façon opérationnelle cette association gagnante au sein de leurs équipes : un point qui constituera de plus en plus un impératif stratégique dans les marchés ultra-concurrentiels et disruptifs de demain.

Adrien Hembert

Brice Kieffer

Coach & Directeur d'Expertise "Organisation & Collaboration" - Zenika

7 ans

Super article, Adrien ! J'adhère à 100% ! Dans le cadre de la phase "Analysis" de la gestion du Portfolio Kanaban, je recommande la mise en oeuvre d'un Design Sprint sur 5 jours permettant de traiter un Epic de manière rapide et efficace.

Identifiez-vous pour afficher ou ajouter un commentaire

Autres pages consultées

Explorer les sujets