Juste quelques mots pour revenir sur mes deux jours à Agile France et partager sur les ateliers et présentations auxquels j’ai assisté. Comme d’habitude les conférences proposées sont toutes très attractives et une des difficultés est de choisir. Cette année, j’ai orienté ma préférence sur les ateliers sous forme de jeux et ceux qui traitent du besoin utilisateur. Je vais donc aborder ci-dessous l’atelier-jeu sur « À la découverte de vos clients » animé par Pascal POUSSARD et Grégoire QUENTIN et la présentation « Design Sprint, 18 mois + tard : joies, détresses, bonnes pratiques« par Paul DEPRE.
Commençons par « À la découverte de vos clients« . Le décor est posé! Dans une équipe de 5 personnes, nous devons réaliser un logiciel sur smartphone à la suite d’un e-mail envoyé par un manager et qui s’est récemment mis au tir à l’arc. Cette application sera « la bible de l’archer ». Le jeu va se dérouler sous la forme de plusieurs itérations ou sprints au cours desquels l’équipe va devoir choisir les éléments à développer en déposant les cartes fonctionnalités sur une feuille A3 modélisant un écran d’application mobile (écran unique pour faciliter l’atelier). A la fin de chaque sprint, les animateurs calculent un nombre d’utilisateurs connectés selon la pertinence de l’application développée par rapport au besoin. Le but premier du jeu, est d’avoir à la fin du sprint le maximum d’utilisateurs connectés ou du moins, plus d’utilisateurs que les 4 autres équipes qui participent au challenge.
Voilà donc le début du premier sprint et chaque équipe reçoit :
- La copie papier d’un e-mail de la commanditaire du produit.
- Des fonctionnalités sous forme de cartes recto/verso ayant chacune un coût associé en point de capacité (d’autres fonctionnalités seront distribuées dans les sprints suivants)
- Une carte fonctionnalité libre pour nous laisser exprimer notre créativité.
- Un nombre de jetons représentant la capacité de l’équipe de développement à réaliser les fonctionnalités. Cette capacité distribuée à chaque sprint pourra augmenter simulant ainsi la montée en compétence de l’équipe.
- Une feuille A3 représentant l’écran d’un smartphone sur lequel les équipes vont pouvoir déposer les fonctionnalités à chaque sprint.
Quelques minutes plus tard, l’équipe fait valider son application par l’animateur qui lui indique le nombre d’utilisateurs connectés. Nous avons obtenu 23 utilisateurs pour le premier sprint. On est loin des 1000 utilisateurs possibles de la feuille. Faisons encore quelques sprints pour voir si nous ne pouvons pas nous rapprocher du besoin des utilisateurs et augmenter ainsi le nombre de connectés!
Au fil des itérations, les animateurs dévoilent différentes techniques d’étude du besoin en se basant sur la théorie aussi bien que sur leur expérience. Au premier sprint, Pascal POUSSARD nous explique le concept de « pitch vision » en prenant l’exemple de Ridley Scott qui aurait pitché « Alien » comme étant « Les Dents de la mer dans l’espace »…Nous allons aborder lors des différents sprints, les Personas, l’étude marketing, les interviews utilisateurs, l’AB-testing… jusqu’au concept de pivot comme surprise finale. L’application à développer ne ciblera finalement pas les archers mais devra permettre des rencontres amicales.
Après deux heures bien rythmées et pas mal de bonne humeur, ce jeu m’a permis de revoir plusieurs techniques d’étude du besoin utilisateur et nous prouve encore une fois l’importance de bien connaître les utilisateurs avant de se lancer dans la réalisation. L’application simulée sur feuille A3 peut être considérée comme un MVP, nous permettant de tester la motivation des utilisateurs, comme nous aurions pu le faire lors d’un design sprint…
La transition est toute trouvée pour aborder la présentation de Paul DEPRE sur le
design sprint. Après 18 mois de pratiques du design sprint et plus de 30 sprints pour plusieurs sociétés, Paul nous partage ses recettes et ses déboires en repartant d’abord de la définition théorique et du livre de Jake Knapp « Sprint : how to solve big problems and test new ideas in just five days ». Un Design Sprint, c’est donc :
- un problème ou une idée à tester/valider
- une équipe de 8 personnes maximum
- 5 jours d’ateliers
Premier conseil capital, ne jamais oublier le décideur ou un de ses représentants dans l’équipe qui réunira aussi un designer et un sprint master; personne qui va faciliter le sprint.
Parmi les retours positifs ou les joies, Paul nous indique apprécier la vitesse d’exécution ou le rythme imposé par la méthode, même si le Sprint ne dure pas 5 jours mais plutôt 2 semaines. Le fait d’arriver à un prototype à la fin du Sprint et de pouvoir le faire tester est aussi un facteur de satisfaction. Enfin le format invite les personnes à sortir de leur quotidien dans la bonne humeur, apporte des bénéfices indirects en créant des interactions et des liens entre les personnes dans un terreau propice aux échanges…
Parmi les détresses ou les difficultés rencontrées, le premier est de mal définir le challenge ou le problème auquel le sprint doit répondre, d’avoir envisagé un périmètre trop vaste et donc de ne pas pouvoir fournir un prototype concluant à la fin du sprint. Pour éviter ce problème, Paul nous conseille de faire précéder le sprint par une phase de préparation en amont. De même, afin de faire adhérer rapidement les participants à la méthode pour commencer les ateliers du premier jour sans perdre de temps, il sera astucieux de préparer celles-ci avant le sprint. Le fait d’obtenir peu de retours des personnes qui testent le prototype ou d’avoir un prototype qui ne répond pas à la problématique, sont autant des facteurs qui peuvent entraver le succès de la démarche…
Il n’existe pas de recette miracle pour éviter ces problèmes mais quelques bonnes pratiques et comportements permettent néanmoins de les anticiper ou de diminuer leurs effets. Soyez pédagogue, expliquez la méthode et le déroulement du Sprint avant la première journée; vous gagnerez ainsi un peu de temps pendant le sprint. Soyez agile avec la méthode en adaptant celle-ci au contexte, en choisissant vos ateliers et en préparant une phase amont de design thinking. Formez-vous et devenez un maître dans l’art des tests utilisateurs… Recrutez ces derniers le plus tôt possible, dès la première journée. Préparez un guide pour les tests mais laissez une certaine latitude aux testeurs. Vous pouvez par exemple, les laisser parler en laissant des blancs dans les interviews. Autre conseil, débriefez à chaud afin de ne rien oublier et consignez les résultats des tests dans un tableau de management visuel. Enfin, accompagnez les utilisateurs en fin de sprint, ne les laissez pas sans nouvelle une fois les tests terminés. Vous pouvez même effectuer des recommandations pour terminer…
Si vous souhaitez en savoir davantage, vous pouvez participer à cette présentation à Agile en Seine le 20 septembre prochain, regarder cette vidéo de MIXIT 2017 : « Comment sauver la princesse… et si le Design Sprint m’était conté ? » ou encore lire cet article de blog de Paul DEPRE qui détaille son expérience sur le design sprint.
Liens et Références :
- Site Agile France : http://2017.conf.agile-france.org/
- MVP et Design Sprints : https://agilescrumetnous.org/2016/11/05/mvp-et-design-sprints/
- Blog d’Alexander Cowan sur les Personas : https://www.alexandercowan.com/tutorial-personas-problem-scenarios-user-stories/
- Présentation sur le Design Sprint de Paul DEPRE
- Blog THIGA sur le Design Sprint : http://blog.thiga.fr/innovation-digitale/design-sprint-idee-prototype-5-jours/
- Wikipédia sur le Design Sprint : https://fr.wikipedia.org/wiki/Design_thinking
- Conférence MIXIT sur le Design Sprint : https://mixitconf.org/2017/comment-sauver-la-princesse-et-si-le-design-sprint-m-etait-conte-
- Site Agile en Seine : http://www.agileenseine.com/
Cet outil permet donc de satisfaire le désir de reconnaissance, le désir d’appartenance, le fait de travailler avec des collègues bienveillants et l’engagement sociétal et humain basé sur le bien-être des autres. Comme expliqué dans l’article 
sort parmi les employés. Ceux-ci ont la charge de déterminer la viabilité du projet et la responsabilité de remonter ce dernier à des instances dirigeantes afin d’allouer des fonds et des ressources pour la réalisation de ces derniers. Plusieurs sociétés ont déjà mis en place différentes techniques pour provoquer et soutenir l’innovation; chez Google, du temps est alloué pour l’innovation et plusieurs entreprises favorisent aussi l’intraprenariat. Je n’ai pas défini de solution spécifique ici et laisse la liberté aux employés de choisir une solution au cas par cas. Si plusieurs projets sont susceptibles d’être financés, alors le sponsor ou les équipes dirigeantes peuvent trancher et prioriser les projets. Cet outil permet aux employés de satisfaire leur besoin de challenge et d’innovation.

que vous pouvez tenir dans vos main et les récompenses virtuelles comme les badges que vous pouvez obtenir quand vous suivez un cours en ligne par exemple. La seconde distinction de récompenses est entre celles qui sont attendues et celles qui sont inattendues. Nous savons quelques fois qu’une récompense va nous être distribuée si nous accomplissons certaines actions mais pour d’autres, c’est une surprise totale et notre esprit aime les surprises. La troisième distinction différencie les actions à effectuer pour gagner une récompense :
ceux qui touchent le plus ne sont pas forcément les plus motivés et les plus performants. Dans son livre
Si j’ai bien tout compris et pour simplifier au maximum, Angular2 est une offre packagée qu’il vaut mieux utiliser si on a des affinités avec AngularJS bien que la deuxième version ne ressemble que peu à la première et donc pas ou peu de réutilisation du code existant. ReactJS et Vue.js sont des offres un peu plus modulaires de plusieurs librairies javascript. Les 3 outils (lorsqu’ils sont utilisés avec des librairies tierces pour ReactJS et Vue.js) ne se différencient pas en terme de capacité technique. Mais côté communautés, alors que AngularJS est soutenu par Google et ReactJS par Facebook, Vue.js ne possède qu’une faible renommée et donc une communauté peu développée mais qui s’agrandit peu à peu.
du produit ou de la fonctionnalité
Avec l’évolution des nouvelles technologies mais aussi la manière de communiquer, notre relation avec le travail a considérablement évolué. Et nulle ne doute que cela va continuer sur cette voie. Jacob Morgan nous dresse un état des lieux réaliste de la révolution que nous sommes en train de vivre, en décrivant tour à tour l’employé de maintenant et du futur, le manager actuel et le futur manager ainsi que les futures organisations dans lesquelles ces derniers travailleront. Jacob décrypte pour nous les évolutions futures en nous éclairant sur les différents facteurs de changement. J’ai construit une
la promotion de ce dernier. A contrario, il ne peut y avoir des outils pour les managers et d’autres pour les employés.
structures globalement distribuées en petites équipes interconnectées entre elles par des outils de communication adaptés. Ces entreprises devront supporter et faire la promotion de l’intreprenariat; leurs employés créeront ainsi de nouveaux produits, développeront de nouvelles idées qui pourront constituer un avantage compétitif. De nombreuses entreprises comme Google, LinkedIn, DreamWorks… ont déjà utilisé cette stratégie. Les entreprises du futur devront opérer comme de petites organisations afin de garder une certaine capacité à s’adapter au changement et proposer une innovation constante, basée sur ses employés, ses partenaires, ses clients ou même ses concurrents. Ces entreprises utiliseront le Cloud, supprimeront les niveaux hiérarchiques intermédiaires et compteront davantage de femmes dans leurs dirigeants…
Quelques aventures et minutes plus tard Jurgen nous demande si un employé heureux obtient des performances plus élevées ou si c’est les succès qui rendent les employés heureux ? A l’image de la poule et de l’œuf… La réponse; les deux en fait mais des employés heureux sont beaucoup plus performants et achèvent beaucoup plus de travail. Il nous dévoile alors 12 éléments qui selon lui, sont des
Une fois la tour de vélocité construire et le PO positionné sous la forme d’un animal au sommet de celle-ci afin de signifier par la symbolique que la tour appartient au PO, Daniel a construit des tours plus petites, de différentes tailles; 1 à n DUPLO afin de modéliser les différents coûts d’une story; XS, S, M, L, XL. Il a ensuite créé une liste de stories et nous avons pu commencer à les évaluer. Il a intentionnellement créé une story de grande taille avec de nombreuses contraintes fonctionnelles afin que nous l’évaluions à la taille XL et que nous puissions nous rendre compte que celle-ci était visuellement plus grande que la moitié de notre tour de vélocité. Nous avons donc découpé cette story en stories plus petites. Les développeurs ne connaissent pas le rapport entre la taille de la tour et la vélocité réelle. ceci permet donc à ceux-ci de pouvoir estimer librement sans être tenté d’effectuer une conversion en jours/homme. Le jeu permet aussi de donner un rythme différent et d’apporter un peu de nouveauté à ce rituel qui peut parfois être long et fastidieux. Daniel nous l’a affirmé : « si un développeur commence à estimer le rapport de conversion entre la tour DUPLO et la vélocité, alors il le changera aussitôt ». Mais alors me direz-vous , comment savoir si on suit la release planifiée. Daniel possède un fichier Excel qui lui permet de convertir les DUPLO en vélocité réelle pour détecter toute variation par rapport à la planification! Il envoie la vélocité réelle au Product Owner…