Face à la popularité de l’agilité, chacun est tenté de penser qu’elle s’oppose aux méthodologies plus traditionnelles comme le cycle en V. Dans une erreur d’interprétation, il est fréquent de croire que l’agilité est mieux que tout ce qui a précédé.

Ce serait tomber dans le buzz, limiter l’analyse et oublier que la popularité de l’agilité se justifie par son adaptation à l’incertitude qui caractérise notre époque. C’est ce que nous avions souhaité mettre en avant précédemment ici.

Les modèles dits classiques d’organisation et de conduite de projet ont évolué pour répondre aux contraintes de « time to market ». Innover en permanence, réduire les coûts, être le plus réactif possible sont autant d’impératifs qui ont porté l’agilité. En impliquant au maximum le demandeur, en cherchant toujours à apporter le plus de valeur, une trajectoire agile n’implique pas seulement des équipes de développement. L’illustration suivante permet de comprendre que le champ d’application de l’agilité s’étend bien au-delà de la gestion de projet ou de la production de solutions logicielles. C’est une évolution organisationnelle qui crée une chaîne de valeur en créant du lien entre tous les métiers.

Scrum est l’outil le plus connu et le plus implémenté, à tel point qu’une confusion existe. Tout se passe comme si Scrum et agile étaient synonymes.

Cet amalgame « l’agilité c’est scrum et scrum c’est l’agilité » semble donc compréhensible mais il n’est pas vrai, car :

• Scrum n’est pas la seule manière de faire, il existe d’autres approches comme extrem programing (XP), Kanban, SAFe…
• L’agilité est une culture, un état d’esprit.

L’origine de Scrum et ses fondements

Scrum signifie « mêlée » en anglais. Celle du rugby plus précisément ! Ce n’est pas un hasard car selon ses créateurs, il partage les mêmes valeurs de l’ovalie : engagement, courage, focus, ouverture et respect.

L’approche Scrum a été créée par Jeff Sutherland et Ken Schwaber au cours des années 90 pour aider les organisations à développer, livrer et maintenir des produits complexes (digitaux mais pas seulement). Ils sont à l’origine du Scrum Guide publié en 2009.

Scrum est une approche empirique, c’est-à-dire que l’équipe travaillant en Scrum va tester, apprendre et s’ajuster au fur et à mesure. Ainsi la connaissance vient de l’expérience, les prises de décisions sont faites à partir de ce qui est connu et non à partir de théories et de suppositions.

C’est aussi pour cela que l’on ne peut pas parler de méthode, car une méthode dit généralement comment faire les choses. Scrum n’est pas comme une recette de cuisine à suivre pour réussir son logiciel, éviter les problèmes, limiter les imprévus… Il peut davantage être vu comme une règle du jeu : il donne un cadre et le rôle de chaque joueur. À l’équipe d’évoluer et de construire sa propre stratégie pour atteindre ses objectifs.

Pour atteindre l’empirisme, Scrum repose sur trois piliers :

• Transparence : toute l’équipe projet doit comprendre et partager les aspects importants du projet, la communication est primordiale !
• Inspection : l’équipe vérifie son travail au fur et à mesure, et non à la fin, une fois le produit terminé. Elle inspecte également sa façon de faire et de fonctionner.
• Adaptation : des ajustements peuvent être faits pour minimiser les risques (prise de retard, décalage avec le besoin utilisateur…).

Les ingrédients de Scrum

Scrum est composé de 3 rôles principaux, 5 événements et 3 “artefacts” que nous allons détailler dans l’article suivant. Attention, ces rôles, événements et artefacts sont obligatoires. Le Scrum Guide est très clair à ce propos : ne pas respecter un de ces rôles/événements/artefacts résulte en la perte de transparence et d’opportunités pour inspecter et adapter le produit.

Après avoir posé les bases et détaillé les fondements de Scrum, attardons-nous davantage sur ses rituels. Scrum est composé de certains éléments indéfectibles de cette approche :

3 rôles principaux

• Le Product Owner
• Le Scrum Master
• La Dev Team

5 événements

• Le Sprint Planning
• Le Sprint
• Les Daily Scrum
• Le Sprint Review (Delivery)
• La Sprint Retrospective

3 “artefacts”:

• Le Product Backlog
• Le Sprint Backlog
• L’Increment

La Scrum Team

• Le Product Owner (PO) Il porte la vision du produit à concevoir. Il apporte sa connaissance du marché et les besoins des utilisateurs. C’est lui qui rédige et maintient à jour le Product Backlog qui recense toutes les fonctionnalités du produit.

• Le Scrum Master (SM) Il n’est pas toujours présent dans les équipes Scrum, le Product Owner portant parfois cette casquette. Il est garant du framework, veille à ce que les différents évènements de Scrum aient bien lieu dans les temps. Il a également un rôle de facilitateur.

• La Dev team L’équipe de développeurs. Ils sont un groupe de 5 à 10 « faiseurs » qui développe le produit.

Ils interviennent aussi :

• Les stakeholders / les parties-prenantes Il s’agit du client et/ou des usagers du produit qui est développé. Ils interviennent lors de certains événements ou via l’intermédiaire du Product Owner.

• L’UX designer C’est une tendance que l’on observe de plus en plus : l’intégration d’un UX design dans une équipe Scrum fait un bon duo avec le Product Owner et permet de garder l’utilisateur au centre du processus de création.

Dans une Scrum Team il n’y a pas de hiérarchie, chacun est l’égal de l’autre, les décisions sont collégiales. L’équipe est auto-organisée et pluridisciplinaire.

Tout commence au Product Backlog

Tout débute par le premier artefact : le Product Backlog. Il s’agit un document écrit contenant toutes les fonctionnalités, les besoins et améliorations liés au produit. Il est rédigé et mis à jour par le Product Owner.

Les fonctionnalités sont écrites sous forme de parcours utilisateur : des User Stories.

Exemple pour une application de VTC : « En tant que client je souhaite être localisé sur un plan afin de ne pas avoir à renseigner l’adresse de ma position. »

Le 1er rituel : le Sprint Planning pour préparer le sprint

L’équipe se réunie lors du Sprint Planning pour sélectionner les User Stories (US) qui seront développées lors du Sprint. Comme tous les événements de Scrum, le Sprint Planning a une “timebox”, c’est-à-dire une durée maximale. Pour lui, la durée maximale est de 8h (pour un sprint de 4 semaines).

À la fin du Sprint Planning, chaque User Story doit être claire et estimée et les membres de la dev team doivent savoir quel plan d’action mettre en place pour accomplir le Sprint Goal (l’objectif du sprint).

Comment sont estimées les User Stories ?

Pour estimer une User Story, les membres de l’équipe organisent un Planning Poker, il s’agit d’un jeu de cartes qui permet à chacun de voter et d’estimer l’effort à fournir pour la réaliser.

Exemple : une tâche très facile mais qui va être longue à faire n’équivaut pas en points à une tâche très facile et rapide à faire.

Les User Stories sélectionnées pour le sprint forment le Sprint Backlog.

Des User-Stories à l’Incrément : le Sprint

L’objectif d’un Sprint est de développer une pièce fonctionnelle du produit à réaliser : un Incrément. C’est à l’équipe de définir sa durée qui ne doit pas dépasser 4 semaines. Quand un sprint se termine, un nouveau commencera.

Chaque jour du sprint l’équipe se retrouve lors des mêlées quotidiennes : les Daily Scrum. Généralement en début de journée et d’une durée de 15 minutes, l’objectif est de renforcer la transparence et la réactivité de l’équipe. Chacun partage ses actions du jour ainsi que les difficultés qu’il rencontre ou que le projet rencontre. L’équipe peut donc s’ajuster et mettre en place des plans d’action.

Livrer, tester, ajuster : la Sprint Review

À la fin du Sprint, une Sprint Review est organisée, on parle aussi de phase de Delivery. D’une durée de 4 heures maximum, elle réunit l’équipe Scrum et les parties-prenantes (le client) et/ou des usagers.

Une démonstration de l’incrément développé est faite. L’équipe Scrum récupère alors de précieux feedbacks qui seront ajoutés au Product Backlog. C’est aussi souvent l’occasion de déceler des bugs, qui seront corrigés lors d’un prochain Sprint.

C’est un moment important, car c’est la rencontre entre ceux qui font et ceux qui utilisent. L’équipe Scrum comprend pour qui et pourquoi elle travaille et les utilisateurs se sentent écoutés et impliqués dans le processus de création.

S’analyser soi-même : la rétrospective de sprint

Dernier évènement : la Sprint Retrospective

C’est un rendez-vous d’1 heure qui permet à l’équipe Scrum de s’analyser en mettant en lumière ce qui a fonctionné durant le Sprint, ce qui n’a pas fonctionné et de mettre en place un plan d’amélioration continue avec des actions concrètes.

"Le design thinking est une approche collaborative de résolution de problème qui est itérative, centrée sur l’humain, créative et concrète." -Tim Brown – cofondateur d’IDEO

Le design thinking a été théorisé début des années 2000 dans la Silicon Valley à la suite des travaux de l’ingénieur David Kelley et du designer Tim Brown de l’agence IDEO. La démarche est souvent résumée à une session de brainstorming en équipe ou d’ateliers de créativité avec Post-It. Mais nous allons le voir, c’est un peu plus que ça…

Il s’agit d’une démarche qui utilise les outils et les méthodes des designers, pour concevoir des solutions qui répondent à des problèmes utilisateurs que l’on aura préalablement constatés sur le terrain.

Le processus du Design Thinking se découpe en deux grandes phases en double diamant ou en sablier, car c’est une succession de phases de travail de divergence (on explore, on voit large) et des phases de convergence (on sélectionne, on priorise).

Compréhension et recherche utilisateur

Le design thinking est une démarche centrée sur l’humain. Tout débute donc par l’observation du terrain, la compréhension des besoins, des habitudes, des problèmes vécus. En adoptant une posture empathique, nous allons à la rencontre des émotions et des raisonnements des usagers.

C’est aussi l’occasion de faire des recherches sur l’écosystème du sujet. Faire de la veille pour connaitre ce qui a déjà été fait, les bonnes et mauvaises pratiques, les technologies existantes… C’est la première phase divergente de la démarche, car elle peut croiser beaucoup de domaines différents selon le sujet que l’on traite !

Quelques méthodes des designers pour la recherche utilisateur

• L’interview utilisateur, les sondages…
• L’observation « point de vue d’une mouche »
• L’immersion « vis ma vie »
• Le reportage photo
• Définir un parti-pris

Ce travail de recherche permet de mettre en avant un vrai problème à traiter qui n’est pas nécessairement celui auquel on aurait pensé a priori derrière son bureau. Il s’agit de clarifier le périmètre et d’adopter un parti-pris : poser le bon problème est le meilleur moyen de trouver la bonne solution !

Quelques outils pour synthétiser la recherche utilisateur

• Empathy Map
• Persona
• Parcours utilisateurs

Idéation et créativité

C’est à partir de ce moment que l’on retrouve le brainstorming et les post-it ! Une fois que l’on a identifié un vrai problème, il est temps d’inventer des solutions créatives pour le résoudre. C’est une phase divergente, car il s’agit d’explorer et de proposer des concepts et des solutions sans se retreindre de leur faisabilité et leur désirabilité. Le but n’est pas de trouver LA bonne solution, mais de générer un maximum de pistes de résolution de problème.

Pour y parvenir, quelques conseils pour un brainstorming efficace :

• Proposer des idées folles, pas de limites !
• Construire des idées à partir de celles des autres, celles des collègues de l’équipe mais aussi celles dans d’autres domaines, dans d’autres cultures…
• Pas de jugement
• Pour ne pas brimer la créativité
• Rester focus sur l’utilisateur et sur le sujet pour être efficace et éviter les sessions brainstorming de 2 heures sans aucune solution pragmatique
• Rechercher la quantité

Prototypage, test et processus itératif

Il est temps de sélectionner parmi toutes les solutions précédemment produites celle ou celles que l’on souhaite tester.

Pour faire tester ces solutions, il faut les matérialiser à l’aide d’un prototype. Les premiers prototypes sont simples, rapides à réaliser, mais ils permettent d’avoir de premiers retours précieux pour valider ou invalider la solution retenue. Comme le design thinking est un processus itératif, il est possible à ce stade de revenir sur la phase d’idéation et de produire ou sélectionner de nouvelles idées à tester. Il est également possible d’affiner son prototype pour le rendre plus complet, plus précis et plus réaliste et de faire tester une nouvelle fois sa proposition de solution.

Quelques suggestions de prototypage

• Les affiches de pub
• Les maquettes de sites ou d’appli interactives
• Les scenarii et les maquettes
• Les packagings de produit

Lors des phases de test, il ne faut pas seulement tester la désirabilité de sa solution : « est-ce que vous aimez ? » mais comprendre pourquoi cette solution est aimée ou non et ainsi analyser si elle répond au problème que l’on a identifié précédemment.

Quelques outils de test :

• A/B testing
• Les interviews et questionnaires
• Les focus groups
• Les grilles de feedback

Si la phase de test est concluante, la solution se transforme en POC – proof of concept qui illustre la faisabilité et la désirabilité de la solution. Il est temps de passer en phase de production et de déploiement !

Design Thinking et agilité

Le Design Thinking n’est pas une méthodologie de gestion de projet, mais une approche pour imaginer et concevoir des solutions. Ainsi il n’entre pas dans la famille des approches agiles (comme Scrum, SAFe, XP…) qui ont pour but la réalisation du produit.

Cependant, dérouler le processus de création du design thinking ne peut s’appliquer sans adopter une posture d’agilité.