Beyond Sprint 0 : une alternative pour intégrer les équipes

Scrum est la méthodologie de gestion de projet la plus populaire au monde avec plus de 72 % des équipes utilisant Scrum ou un scrum hybride. Il y a de fortes chances que si vous travaillez dans le développement Web, vous utilisiez Scrum sous une forme ou une autre.

Une tendance actuelle dans Scrum est le « Sprint 0 » ou son cousin plus artistique le « Design Sprint ». Beaucoup a été écrit sur la question de savoir si ce sont de vrais sprints (ils ne le sont pas), mais moins sur la raison pour laquelle ils existent en premier lieu, pourquoi ils restent si obstinément et quelles alternatives existent.

Personnellement, j'aime Scrum et je suis toujours à la recherche de moyens d'améliorer progressivement la façon dont je l'implémente. Dans cet article, j'aimerais partager les méthodes que j'ai intégrées à mon flux de travail et celles que je trouve utiles lors de la fusion de l'UX/UI et du développement, ainsi que pour créer des visions de projet plus solides.

Quelques définitions rapides avant de commencer :

• Sprint 0
  L'effort initial d'une équipe pour créer les documents d'orientation requis pour les projets Scrum : une vision, un backlog de produit et des estimations de version de produit.
• Sprint de conception
  L'effort initial d'une équipe pour créer une conception directrice pour le reste de la version.
  

Pourquoi le Sprint 0 et le Design Sprint existent

C'est bien beau de dire : « Sprint 0 n'est pas un vrai sprint, ne le fais pas. Mais ces adaptations sprint-ish existent pour une raison. De nombreuses équipes les adoptent parce que leur projet a un besoin non satisfait au-delà de la portée immédiate de Scrum. Mon observation est que le Sprint 0 et les sprints de conception sont le plus souvent utilisés pour traiter les situations suivantes :

1. Absence d'une vision directrice forte ;
2. Manque d'intégration de la conception dans le flux de travail de développement.

Le processus Scrum suppose qu'une vision claire a été développée et communiquée par le Product Owner. Mais levez la main si vous avez travaillé sur des projets où la vision est faible, erronée ou invisible. Moi aussi! Sprint 0 est une tentative de l'équipe de développement de combler le vide de vision. Ce n'est pas la pire des idées, alors quel est le problème ? D'un point de vue agile, Sprint 0 n'est pas itératif, n'utilise pas les talents de toute l'équipe et fournit des résultats nébuleux. Et avant que vous ne souligniez, "Hé, le vrai problème ici est que les équipes Scrum ne devraient pas avoir à faire le travail du propriétaire du produit", je crois en fait qu'une équipe agile interdisciplinaire est l'un des meilleurs environnements pour développer un solide, réaliste vision et objectifs.

Je propose une méthode plus agile de construction de vision que j'ai utilisée avec succès dans des projets sans transfert. J'explorerai les deux situations où ces adaptations de type sprint sont utilisées et décrirai comment ce premier sprint alternatif prend mieux en charge le flux de travail agile.

Vision et le prototype Sprint

Dans la première situation, où il y a un manque de vision forte, la documentation ou les idées directrices sont trop faibles pour vraiment commencer un projet Scrum. Pour tout processus (Scrum inclus), vous avez besoin de directives avant de commencer le voyage. Agile est idéal pour déterminer la meilleure façon d'atteindre un objectif, mais générer la vision initiale n'entre pas dans son champ d'application. En fait, il manque complètement à Scrum une description de la vision requise pour que le processus de développement commence. Qu'il s'agisse vraiment de Scrum ou non, Sprint 0 n'est qu'une équipe Web en première ligne, utilisant les outils dont elle dispose, essayant de comprendre ce qu'elle doit faire avant de commencer à le faire.

Le véritable inconvénient du Sprint 0 est que construire le document d'orientation du projet au moment où vous avez le moins d'informations apporte peu de valeur au processus de développement qui suit.

Les visions de projet qui ne correspondent pas à la réalité itérative émergente doivent soit passer par le processus coûteux d'un autre Sprint 0, soit plus souvent simplement être ignorées.

Une meilleure alternative est le sprint de prototype : un premier sprint qui engage toute l'équipe tout en construisant le prototype initial lui-même.

Le processus de vision de prototype de sprint

Les idées de brainstorming sont traduites en un prototype de faible fidélité visuelle, fonctionnant le plus rapidement possible. Le prototype est écrit dans un framework HTML et CSS front-end fonctionnel, c'est-à-dire le langage partagé de l'équipe. Tout le monde ne peut pas comprendre une fiche technique ou un énoncé de vision. Tout le monde peut comprendre un site Web et la communication est plus facile et intègre un plus large éventail de disciplines.

À la fin du premier sprint, le prototype est prêt pour les tests initiaux sur plusieurs fronts, notamment la convivialité générale, l'accessibilité et la réactivité mobile. Dans mes équipes, il s'agit d'un incrément de fait valable et important. Le sprint de prototype produit également un backlog de produit initial. Au fur et à mesure que les éléments du backlog sont terminés dans les sprints futurs, le prototype gagne en fidélité. Le prototype n'est pas un code jetable, il est fondamental.

Dans certains projets, une vision écrite est générée au fur et à mesure que le prototype est produit. Mais dans de nombreux projets, le prototype est la vision. Il parle le langage commun de l'équipe et n'est bien sûr jamais en décalage avec le produit.

Exemple

L'exemple ci-dessous est un prototype de travail pour une application de commerce électronique, complété à partir des grandes lignes de l'appel d'offres initial. Aussi rude soit-il, il a contribué à concentrer les énergies de l'équipe dans une direction productive, en évitant de nombreuses distractions et pièges potentiels pour se concentrer sur des critères fonctionnels.

Un prototype initial entraînera souvent des modifications des exigences, qui ne sont que des hypothèses jusqu'à ce qu'elles soient prises en compte à la lumière de l'expérience de l'utilisateur. Par exemple, l'une des informations que nous avons tirées du prototype de sprint présenté ci-dessus est que le prix et le bouton "acheter" étaient à l'origine beaucoup trop bas sur la page. La demande initiale était de les placer en dessous des infos produits et au dessus des recommandations, mais un prototype fonctionnel a rapidement montré que la hiérarchie n'était pas très fonctionnelle.

Une autre fonctionnalité qui a été révélée était que les images de la galerie devaient à l'origine être grandes et s'étendre sur toute la largeur de la page. Plutôt que d'exposer aux parties prenantes des raisons hypothétiques pour lesquelles cela ne fonctionnerait pas, le prototype a pu démontrer les problèmes dans un langage partagé que toute l'équipe comprend. Lors d'une session de pouvoir avec les parties prenantes, nous avons rapidement réorganisé cette page en une hiérarchie universellement acceptée.

Parce que le prototype est né accessible et réactif, nous pouvons commencer immédiatement les tests sur plusieurs appareils et technologies. Bien que la conception (si on peut même l'appeler ainsi à ce stade précoce) soit intentionnellement maintenue à une faible fidélité, il est immédiatement apparu que la messagerie du commutateur d'année sur le bureau était trop importante sur le mobile et interférait avec la convivialité (à gauche). Nous avons rapidement mis à jour le prototype pour utiliser un sélecteur plus petit dans l'en-tête (à droite).

Quelques autres problèmes sont rapidement apparus lors de ce sprint de prototype :

• Le client, après avoir cliqué sur la navigation fonctionnelle, s'est immédiatement rendu compte qu'il avait manqué un élément fonctionnel majeur dans sa spécification : un blog. Cela a affecté l'estimation et le calendrier, mais nous avons pu nous adapter rapidement.
• Il était évident pour l'équipe de l'interface utilisateur que l'affichage des prix était trop complexe et déroutant. Nous avons exploré d'autres possibilités avec le client et avons pu rapidement prototyper et tester plusieurs solutions au cours du sprint de prototype.

Au lieu que la vision soit potentiellement un obstacle ou devienne obsolète dès le début du développement, dans un sprint de prototype, la vision et les critères fonctionnels sont développés ensemble et se soutiennent mutuellement. Et parce que la vision est générée par l'équipe, il n'y a pas de transfert à l'équipe et évite facilement cette période risquée dans le processus de développement.

Conception et sprint de prototype

Dans la deuxième situation - un manque d'intégration de la conception au développement - c'est souvent lorsque vous verrez un "design sprint" utilisé. Je trouve cette direction encore plus contre-productive qu'un Sprint 0. Les défis d'intégrer le design dans un processus de développement complexe sont réels mais un design sprint est une approche autodestructrice. Le sprint de conception est un pansement pour le symptôme - le défi de constituer des équipes intégrées - mais ne résout pas le problème sous-jacent - le défi de comprendre et de répondre aux besoins des utilisateurs. La conception à chargement frontal dans un sprint évite le défi de l'intégration, mais les avantages d'un processus de conception intégré et incrémentiel et la fenêtre qu'il ouvre pour comprendre et atteindre les utilisateurs sont entièrement perdus.

Le sprint prototype que j'utilise dans les projets sans transfert est une alternative productive et entièrement agile au sprint de conception. Il est collaboratif et fusionne à la fois l'UI/UX et le développement dès les premières étapes du projet. Même l'équipe de conception la plus expérimentée peut bénéficier de l'implication d'autres disciplines et, surtout, elle garantit que les objectifs de code et de conception ne sont pas contradictoires.

Souvent, le sprint de conception est également censé étoffer la vision. Il s'agit d'une décision désespérée basée sur une compréhension vague mais perspicace que le processus de conception est mieux équipé pour générer une vision que le développement. Cependant, une vision générée par la conception est un piètre substitut à un effort réel, collaboratif et à l'échelle de l'équipe.

Les pauvres concepteurs sont chargés de générer un produit final pour lancer le développement sans les informations interdisciplinaires nécessaires pour rendre cet effort vraiment précieux. Bien qu'un concepteur ayant des connaissances techniques et plus d'expérience ait de meilleures chances de réussir, cela reste très risqué. En l'absence de produit potentiellement livrable à la fin de la phase à tester, les conjectures se poursuivent dans le développement. Si la conception n'a pas atteint la marque, ou si les spécifications changent, cela peut entraîner de longs retards lors du retour à l'équipe de conception. Agile est à la base un processus de gestion des risques, et nous pouvons faire mieux que de commencer nos projets agiles avec un sprint de conception intrinsèquement risqué.

Le processus de conception de prototype de sprint

Le changement le plus important par rapport à un sprint de conception plus traditionnel est que pendant le sprint de prototype, l'équipe passe directement du papier au prototype et ignore l'utilisation de Sketch, InVision, Photoshop ou d'autres programmes de mise en page numérique. Ils agissent comme une béquille visuelle à ce stade, semblant introduire de la valeur très rapidement (parce que les bons designers font de belles choses), mais la valeur réelle d'une maquette haute fidélité si tôt est très faible, alors que le danger potentiel qu'elle introduit - parties prenantes du mariage aux mauvaises solutions — est élevé.

Ces outils sont les meilleurs pour les maquettes plates haute fidélité, mais le prototype initial n'est ni haute fidélité ni plat. Le tableau blanc, le crayon et le papier permettent à l'équipe de travailler rapidement sur des idées sans y être attachées. Transformez ensuite cette réflexion en un prototype fonctionnel dès que possible.

Chaque membre de l'équipe, y compris les concepteurs, doit se familiariser et pouvoir travailler directement sur le prototype pendant les phases de lo-fi. Mais si ce n'est pas possible (ou s'il s'agit d'un objectif à plus long terme et que vous devez aller de l'avant maintenant), alors une approche jumelée où un concepteur et un développeur travaillent côte à côte est bonne. Les croquis peuvent être décrits par le concepteur et interprétés ensemble par le développeur, élargissant leur compréhension commune de chaque point de vue.

Exemple

L'exemple ci-dessous montre notre processus distillant une analyse approfondie d'un site Web existant directement dans un prototype fonctionnel. Cela a permis d'évaluer les conclusions du rapport dans un environnement Web natif, une expérience très différente de l'analyse intellectuelle des recommandations dans un document imprimé :

De plus, contrairement au document d'analyse approfondie (aussi utile soit-il), le prototype fonctionnel est exempt de jargon et utilise un langage verbal et visuel partagé que tout le monde peut comprendre. Il ouvre la conversation sur l'affichage visuel à tous les membres de l'équipe et à toutes les disciplines.

Lors de la création de ce modèle, notre principale question était de savoir combien de détails de conception inclure. Comme nous disposions d'un document riche en analyses, nous aurions pu pousser le prototype plus loin. Mais, en gardant à l'esprit que les visuels peuvent rapidement (et involontairement) passer du domaine de l'idée au domaine des faits, nous avons gardé la mise en page sans engagement et distillé le document à ses éléments essentiels et à sa signification.

Les tests internes nous ont amenés dans le stade d'une solution plus axée sur l'utilisateur, dépassant de nombreux problèmes potentiels, mais nous avons consciemment évité de prendre des décisions de conception raffinées aussi tôt dans le processus. Il est important de peser continuellement toutes les idées et suggestions, y compris celles du client, par rapport aux données connues et de se rappeler que notre bassin de connaissances est plus petit à ce stade qu'il ne le sera à toute autre étape du projet.

Une autre raison pour laquelle il est essentiel de garder le prototype initial lo-fi et de ne pas inclure d'éléments de "conception" est que l'adhésion de l'équipe peut être déraillée par des éléments visuels non pertinents qui suscitent des réactions viscérales involontaires. Nous restons à l'écart de la couleur et n'incluons même pas le logo du client (utilisez plutôt un espace vide ou une boîte gris clair comme espace réservé). La conversation doit être continuellement guidée vers des critères fonctionnels tels que la hiérarchie du contenu, l'accessibilité, la convivialité, la langue et le sens. Rassurez l'équipe que les "choses amusantes" viendront, mais pas à ce stade précoce.

En fait, un objectif important d'un sprint de prototype réussi est de prendre le moins de décisions de conception initiales possible. Une conception réussie est alimentée par l'expérience utilisateur. Prévoyez donc du temps pour que les connaissances émergentes du projet informent l'interface utilisateur.

Quand le sprint prototype est-il terminé

Le sprint est terminé lorsque le prototype et les artefacts qui l'accompagnent sont approuvés par toute l'équipe (y compris le client) et que le prototype est jugé prêt pour les tests initiaux d'utilisabilité et d'accessibilité.

Un premier prototype fonctionnel donne vie à la vision du projet à travers l'échelle (nombre de pages, portée de la navigation et autres principaux éléments de l'interface utilisateur), la complexité future (contenu d'espace réservé avec des descripteurs utiles, éventuellement certaines fonctionnalités précoces codées) et l'identification des besoins (technologies spécifiques nécessaires , où ils seront déployés, toutes les dépendances). Les décisions concernant les outils, l'environnement de travail et la pile de code seront prises avec la contribution de toute l'équipe.

Atteindre cet incrément terminé peut prendre aussi peu qu'une journée pour une équipe chevronnée avec un client réactif, mais dure généralement environ une semaine et pas plus de deux semaines. Les sprints prototypes devraient se dérouler à un rythme rapide et dépasser le délai de deux semaines peut être un drapeau rouge. Cela peut signifier qu'il y a d'autres problèmes en jeu.

Quelques problèmes courants à surveiller lors d'un sprint de prototype

Voici quelques problèmes courants à surveiller lors de la mise en œuvre du sprint prototype :

• Embrassez la valeur de la basse fidélité et évitez de mettre l'accent sur les visuels. Soyez vigilant sur ce point car les équipes qui découvrent cette approche pourraient avoir besoin d'aide et de réconfort lorsqu'elles vont au-delà de « où est le logo » et se concentrent sur des questions plus profondes de fonctionnalité et de hiérarchie.
• Une autre facette de ce qui précède, veillez également à ne pas vous attacher à vos propres idées de conception/mise en page. Il est utile de se rappeler lors des sprints de prototypes que rien de précieux n'est généré et de rester détaché des résultats finaux. En outre, c'est encore une autre raison de garder les prototypes minimes et, franchement, plutôt laids. Il a pour but de garder les utilisateurs détachés.
• L'adhésion précoce au processus de la part de la direction est essentielle . Parce que toute l'équipe est impliquée, votre client, votre patron et les développeurs doivent tous soutenir et nourrir le processus avec leur engagement, leur créativité et leur temps. Ne soyez pas une pom-pom girl solitaire, toute votre équipe doit agiter ses pompons !
• Une mauvaise communication est le talon d'Achille de tout travail d'équipe . Le prototype de sprint ne résoudra pas les problèmes de communication persistants, mais il les mettra au premier plan plus tôt, car toute l'équipe plongera presque immédiatement dans un flux de travail collaboratif. Tous les problèmes de communication déjà existants surviendront tôt et souvent dans un sprint de prototype alors que vous travaillez vers un consensus et votre premier incrément fait. Saisissez l'opportunité d'améliorer la communication et engagez toute l'équipe dans la recherche de solutions.
• Choisissez le bon framework frontal . Si vous n'en avez pas déjà, vous devrez peut-être essayer divers frameworks frontaux avant d'en trouver un qui s'adapte au flux de travail de votre équipe. Je recommande de regarder dans des cadres minimaux comme Fomantic ou Bulma et de ne pas s'enliser dans les cloches et les sifflets. Cependant, le bon cadre est toujours celui qui convient à votre équipe.
• L'équipe UI/UX doit développer un niveau de confort et d'accès au framework frontal. Idéalement, ils travailleront directement sur le prototype, évitant les transferts inutiles et le besoin de traduction d'un support à un autre (c'est-à-dire de Sketch au prototype). Si votre équipe frontale n'est pas familiarisée avec CSS et HTML, une approche jumelée (avec un concepteur et un programmeur travaillant ensemble sur le framework) fonctionne également bien.
• Enfin, rappelez-vous que vous progresserez plus vite et mieux en équipe ! Exécuter un sprint de prototype productif est une compétence qui se développe avec la pratique.

Que se passe-t-il ensuite

L'incrément terminé du premier sprint - le prototype fonctionnel et peu fidèle - prépare le terrain pour tous les sprints qui suivent. Avec un prototype fonctionnel, les tests utilisateur pour la convivialité, l'accessibilité et la réactivité peuvent commencer immédiatement, garantissant que les futurs sprints sont informés par UX.

Le sprint de prototype est un bon début pour tout processus Scrum, mais dans mes projets, notre prochaine étape consiste à passer à un flux de travail à double voie où l'interface utilisateur/UX fonctionne un demi-sprint ou un sprint entier avant le développement en faisant la découverte et en mettant à jour visuellement le prototype pour reflètent de nouvelles idées.

Le prototype se développe organiquement et devient de plus en plus raffiné, nourri par la recherche UX et des besoins fonctionnels réalistes. Ces informations, non disponibles pendant le sprint du prototype, n'apparaissent que progressivement au fur et à mesure que le projet progresse. L'UI/UX et le développement s'alimentent mutuellement dans les flux de travail via le processus agile à double voie.

Il n'y a pas de transfert de la conception au développement à construire, ni d'application développée à concevoir pour peau. Au lieu de cela, le prototype de sprint engage l'ensemble du groupe dès le départ et constitue une base solide pour un flux de travail collaboratif agile tout au long du projet.

La vision directrice qui résulte d'un sprint prototype ne sera pas parfaite et changera probablement au fur et à mesure que l'on en apprendra davantage, mais la reconnaissance que nous en savons moins au début qu'à toute autre phase d'un projet est au cœur du flux de travail agile. Lorsque nous appliquons cette même philosophie à l'émergence de la vision et de la conception du projet par le biais d'un sprint de prototype, ce qui en résulte est un incrément réalisable, des artefacts véritablement utiles, une adhésion partagée et un modèle de travail d'équipe et de collaboration qui peut être maintenu tout au long du projet. .

Une note sur les paramètres de l'agence

Si vous travaillez dans une agence, vous pensez peut-être que cette approche sera difficile à vendre. Malheureusement, vous avez probablement raison. De nombreuses agences sont par nature peu agiles et s'efforcent activement d'obtenir un transfert total du projet, souvent avec une approbation officielle et des répercussions soigneusement documentées sur les changements à venir. Plaider pour un prototype de sprint dans une organisation non agile est un non-démarrage : ce n'est tout simplement pas dans leur ADN. Une fois qu'une organisation adopte des équipes agiles et interdisciplinaires, elle peut facilement déterminer si le sprint de prototype sans transfert améliorera son processus.

Conclusion

Le Sprint 0 et les sprints de conception répondent à de véritables défis auxquels de nombreuses équipes Scrum sont confrontées : manque de vision, manque de conception intégrée, ou les deux. Ce sont des réponses compréhensibles et logiques, mais elles n'apportent pas une grande valeur ou ne contribuent pas à des équipes agiles fortes.

Les remplacer par un prototype de sprint est un moyen pratique de remédier aux inconvénients du Sprint 0 et des sprints de conception tout en jetant les bases d'une collaboration agile plus forte lors des futurs sprints.

Un sprint prototype utilise les talents de toute l'équipe, génère la vision nécessaire, aboutit au premier incrément réalisé par l'équipe et évite le transfert de projet. Grâce à ce processus, les équipes construisent une appropriation partagée de la vision du projet et une base plus solide pour une coopération interdisciplinaire dans l'esprit agile.

Lectures complémentaires sur SmashingMag :

• Devenir un meilleur facilitateur
• Adapter Agile aux équipes à temps partiel
• L'importance des rétrospectives de projet
• Apporter un meilleur processus de conception à votre organisation