Concrètement, comment co-construire de façon “Agile” avec SCRUM ?
« itérations », « user story », « Pizza team », « Product owner »… sont des termes qu’il est de plus en plus difficile d’ignorer sur des projets IT, marketing, e-commerce, d’innovation…l’agile n’étant pas synonyme de “bazar désorganisé”, comment s’organise-t-on pour que les promesses de réussite soient au rendez-vous ?
De nombreux retours d’expériences et études mettent en évidence que l’échec des projets informatiques est rarement du à la technique en tant que tel, mais que les raisons des problèmes rencontrés résident plutôt dans la faiblesse du pilotage, l’absence de référentiels et d’objectifs précis pour un projet, des prévisions et estimations initiales irréalistes avec la « vraie vie » d’un projet…(voir les différents rapports Standish Group — Chaos Manifesto par exemple).
Le pilotage et le suivi d’indicateurs permettent de gagner en efficacité et en qualité. En complément, l’approche projet collaborative et itérative avec des cycles courts de conception / mise en œuvre / tests utilisateurs, offre la possibilité de réduire le «gaspillage logiciel». Les agilistes s’appuient pour cela sur des processus continus de validation du potentiel d’adoption ce qui permet de réduire drastiquement le % d’échecs des projets IT, en particulier celui des “longs” projets.
Pour intégrer cette démarche de façon opérationnelle, une bonne pratique consiste à adopter différents principes qui sont précisés au sein d’une « charte » définie à l’étape de « START » d’un projet. Cette charte ne doit bien évidemment pas être figée et évolue avec le projet. C’est un « framework agile » qui propose des principes simples (qui fait quoi, quels sont nos objectifs, quels workflow pour les user story…). Ces principes doivent être applicables et compréhensibles pour accompagner la réussite de tous ! ils est important de les présenter à chaque participant qui rejoint l’équipe en cours de projet.
On y va ?
Tout d’abord, pour définir les contours d’une stratégie digitale globale, il est très utile d’organiser des ateliers d’idéation (voir l’article de Christophe), des entretiens “haut niveau” avec des dirigeants, des workshops qui permettent au moyen d’exercices (lean canvas, vision board) de définir une vision digitale à 6 mois, 1 an, 3 ans pour une entreprise ou organisation.
On considère maintenant que la roadmap digitale existe pour mon entreprise et qu’il faut donc la décliner en produits (site, application, bot, plateforme, dispositif VR, assistants virtuels…). La décision de travailler sur un projet pleinement validée et ça y est, GO, tout le monde sur le pont pour créer la super appli !
La vision
Commençons par le commencement : il va falloir définir concrètement la « vision du produit » avec le « Commanditaire », le « Product owner » et tout autre partie prenante. Cette vision, qui correspond à la “promesse” du produit, doit répondre à une question précise. Elle est définie en groupe lors d’ateliers, d’interviews, de card sorting… Les objectifs pour le produit, qui ressortent de ce travail, doivent être synthétiques et vont concerner des aspects fonctionnels, business, techniques. Ils permettront :
* de définir des facteurs clé de succès, les KPIs pour mesurer l’atteinte des objectifs du projet (ce qui fera que mon appli est une super appli ou pas);
* de définir le produit, les principaux processus métiers qu’il intègre ;
* d’établir un premier backlog « macro » et l’ordonnancement des fonctionnalités du produit à mettre en place. Ce backlog sera alimenté ensuite en continue durant toute la vie du projet.
En parallèle, et avant la finalisation du backlog, des prototypes techniques, des benchmarks, des tests utilisateurs et tout autre type d’expérimentation peuvent être réalisés pour cadrer au mieux les possibilités, les besoins, les réponses à la promesse portée par mon appli (mon produit).
La conception
Le « macro backlog » (liste des fonctionnalités de l’appli) est ventilé en « releases » (versions) et en « sprints » (phases de travail), à partir du travail d’ordonnancement initial. Le travail de définition et de conception détaillée des premiers backlog de sprints (liste détaillée et spécifiée des fonctionnalités à développer durant une phase de travail) débute alors. Le “Product Owner”, assisté de designers / consultants travaille sur la définition de scénarios, wireframes, design, users stories détaillées. Ces travaux s’inspirent de la « vision » précédemment définie et s’appuient sur des ateliers de co-création ou des entretiens avec des usagers.
L’objectif de ces travaux est de produire un backlog le plus détaillé possible, couplé à des conditions qui permettront de valider que la user story rempli bien les fonctions attendues. Ce backlog permet par la suite aux développeurs de produire les développements sur la base d’un document très précis, dans lequel sont consignés les spécifications, la description des difficultés à envisager, les tests….
L’ensemble d’un backlog d’un sprint devra avoir été spécifié en amont du démarrage de celui-ci, afin de garantir l’efficacité des développeurs.
Pour cela, les équipes de design (wireframe, design, spécifications) du produit travaillent avec quelques itérations d’avance par rapport aux sprints réalisés par les devs.
Le développement
hehe :) ça y est, on est dans le dur ! le fameux SPRINT ! l’unité de base du projet SCRUM ! on développe les User stories décrites dans le Backlog de sprint. le sprint débute lorsque le backlog correspondant est intégralement défini, documenté, dispose de l’ensemble des tests d’acceptance (conditions de validation) pour une efficacité complète dans l’exécution des travaux.
Les sprints sont généralement réalisés sur des durées de 2 à 4 semaines par de petites équipes : des « pizza teams ». Des « arctefacts » agiles permettent de réaliser un suivi de l’avancement des opérations.
Le premier jour , il s’agit de préparer du Sprint : revue des user story (tâches à réaliser) avec les devs ; questions & réponses, attribution des travaux et ordonnancement ;
Tous les matins il y a revue et validation des travaux de la veille, revue de ceux travaux à réaliser dans la journée, discussion autour de problèmes éventuels ;
Le dernier jour, les users story développées sont présentées au cours d’une démonstration. Elles sont validées, des améliorations sont identifiées…etc indicateurs de performances ;
Le dernier jour également, la rétrospective de sprint permet d’identifier les axes d’amélioration et les problèmes rencontrés durant le sprint.
La « definition of done » d’un sprint
Convenir d’une « Definition of Done » pour les user stories permet de se fixer des jalons, de disposer d’indicateurs d’avancement et de performance précis et d’anticiper des problèmes difficilement détectables. Il s’agira pour valider qu’une user story est bien développée, de valider les critères de type: intégration avec succès dans la Plateforme d’Intégration Continue, existence de tests automatisés, relecture de code effectuée, conformité vis-à-vis des conditions d’acceptation du backlog…
L’évaluation des travaux par les usagers
A l’issu d’un sprint, en complément de la réunion de « demo » (revue de sprint), un atelier utilisateurs peut être organisé pour que ceux-ci reportent leurs propositions d’adaptations, les éventuelles difficultés et remarques après une série de tests utilisateurs. Les retours sont alors évalués et, pour certains, réintégrées sous la forme de user stories/taches dans la release backlog.
On le sort ce produit ?
Dans la même veine que l’évaluation du produit par les usagers en fin de sprint, rien de mieux que d’obtenir des vrais retours d’utilisation très vite pour les prendre en compte dans la roadmap du produit. Donc, le meilleur conseil est de sortir votre appli, votre site ou tout autre projet en version “beta”, qu’on appelle également MVP (minimum viable product), et de le faire évoluer au cours du temps. Le mieux est d’accompagner cette sortie avec de la com, de s’organiser pour échanger avec les utilisateurs, structurer la communauté, travailler l’intérêt….et comprendre très vite les feed back pour ajuster les orientations et construire une “killer app” :)
Voilà, j’espère que cet article a pu vous permettre d’apprendre quelques petites choses…
Pour avoir pratiqué le fameux “cycle en V” de nombreuses années, je ne peux que conseiller d’essayer l’adoption du SCRUM ou d’une démarche KANBAN. Ça fait du bien, c’est dynamique, c’est encourageant. Je pense même que c’est indispensable — au même titre qu’il est indispensable pour votre entreprise de se transformer et d’adopter une démarche de plateforme largement connectée à son écosystème (clients, partenaires, fournisseurs ou collaborateurs).
Mieux : il est même indispensable pour tous d’adopter une démarche « d’open plateforme » (open data, open innovation, open source, open api…) pour bénéficier de tous les avantages que peuvent représenter la co-construction et la co-innovation dans un processus de transformation digitale agile…vaste sujet qui est aux coeur des problématiques adressées par LinDA…
D’ailleurs, pour en connaître plus sur LinDA (une pro de Linnovation DAgital que je connais bien:)) : le site www.linda.digital ou un petit article de blog : LinDA le service d’accomagement digital de LINAGORA
