Vis ma vie de Scrum Master : les enseignements à tirer d’une expérience sur le terrain

La phase de cadrage du projet : un incontournable 

Avant le commencement du projet, la phase de cadrage a permis aux 7 participants, dont le client qui était néophyte, de mieux comprendre l’agilité et surtout de cadrer le budget et les délais.  En amont des 8 sprints prévus, ont été menés : 

• Une formation de 2 jours à l’agilité pour l’ensemble des intervenants. Elle a permis au Product Owner, aux membres de la DSI et aux utilisateurs clés de comprendre l’état d’esprit agile et le mode de collaboration que nous allions mettre en place avec le rôle de chacun. 

• Plusieurs jours d’ateliers de vision, personas et story mapping afin d’aligner tout le monde sur les objectifs du produit et de commencer à construire le Backlog Produit. A ces ateliers étaient présents la Product Owner, la Proxy Product Owner, les utilisateurs clés, l’interlocutrice DSI, un UX designer et un développeur. La présence de ces deux derniers leur a permis de capter beaucoup d’informations, de construire une UX Map (ou carte d’expérience) et d’échanger sur des questions ou problématiques techniques qui pouvaient déjà se présenter. 

 

Le Sprint 0 ou la préparation du projet : l’étape primordiale 

L’agilité nécessite de faire une bonne préparation, ou sprint 0, en amont des sprints. Au-delà de la liste des actions à mener, ce sprint a révélé certains points positifs qui ont par la suite permis de mener à bien ce projet.   

Réalisation de plusieurs POC

Le projet comprenait plusieurs points techniques à risque : 

• Serveur HDS (Hébergement de données de santé) : les données de santé étant des données sensibles, nous avons dû travailler avec des serveurs ayant des contraintes particulières (accès limités, encryptage des données, séparation des données, etc.) 
• Connexion de notre application à l’agenda Outlook de notre société avec un besoin fort d’écriture dans les agendas demandés par les métiers 
• Refaire tout le site vitrine de notre client 

Pour essayer de limiter les risques, et surtout ne pas s’engager sans savoir vraiment de quoi il retournait, nous avons réalisé des POC pour les deux premiers points. Ces POC nous ont permis : 

• De faire en amont le code source de base pour le projet 
• De vérifier le fonctionnement avec la DSI 
• De monter en compétence pour l’équipe de développement 

Pour le site vitrine, il se trouve que le site corporate du client venait d’être entièrement refait par SQLI. Nous avons donc étudié le fait de réutiliser son socle technique et de l’adapter à nos besoins : cette opération a permis de gagner du temps et du budget pour la partie « application » du projet.   

Mise en place des environnements 

La gestion des environnements techniques est toujours très consommatrice de temps et d’argent, aussi bien à la mise en place qu’à la maintenance sur le long cours. Nous avons donc décidé de monter en premier un environnement de développement et d’intégration entièrement opérationnel et disponible dès le premier sprint, ce qui nous a offert une visibilité sur le déploiement des suivants.   

Réalisation d’une première user story

L’importance de la première US (user story) à faire pendant le sprint 0 s’est confirmée pour ce projet. A partir d’une US très simple, nous nous sommes rendu compte de certains problèmes de déploiement que nous avions sur nos environnements (droits d’accès aux serveurs et packaging du produit notamment). Sans cette première US, nous n’aurions jamais pu livrer une seule US en sprint 1 ; n’hésitez pas à la faire !   

 

Une organisation d’équipe dans l’esprit de SCRUM

L’équipe a su trouver une organisation dans l’esprit de SCRUM. Elle était composée comme suit (avec le temps alloué au projet pour chacun car cela a joué un rôle crucial dans la réussite du projet) : 

• Un Product Owner (PO) côté client avec 25% de son temps alloué au projet 
• Un Proxy Product Owner (PPO) avec 100% de son temps alloué au projet 
• Un UX Designer avec un nombre de jours fixes alloués au projet 
• Trois développeurs dont deux à temps plein et un à 80% 
• Un SCRUM Master/Coach agile à mi-temps 

 

Une DSI facilitatrice du projet

Nous avons eu la chance d’avoir une DSI qui a compris l’importance du travail «sans intermédiaire» dans les projets agiles, ce qui nous a permis de travailler directement avec les acteurs des métiers. En effet, nous voyons souvent notre interlocuteur (PO) «métier» être une personne de l’informatique qui fait le «?passe plat?» entre l’équipe et les acteurs des métiers. La DSI nous a donc fourni un soutien sur les sujets techniques lorsque nous en avions besoin, et le PO du projet était une personne directement du métier.   

Le rôle du PO : impliqué et à temps plein ! 

Pour moi, le rôle du PO est souvent sous-estimé en Agile. C’est pourtant lui qui porte le produit et qui définit ce à quoi il va ressembler. Nous avons eu l’occasion d’avoir ce que j’appelle un « vrai » PO ; une personne côté métier qui va utiliser l’application développée, qui connait les métiers et sait où chercher les informations sur les métiers. Notre PO a fait un travail colossal en amont pour définir avec les utilisateurs leur besoin, cadrer vis-à-vis à de la vision (et parfois dire non) et avoir 90% des informations de la user story lorsque nous l’abordions en séance d’affinage. Nous avons gagné beaucoup de temps en allers-retours inutiles et en discussions stériles.    

L’UX designer : comment l’intégrer ?

Vous avez sûrement dû vous poser la question «Comment intégrer les profils «spécifiques» dans un projet agile comme les architectes, les experts ou encore les UX Designer» Le facteur primordial pour le rôle d’UX Designer est de l’impliquer le plus en amont possible dans le projet et tout le long. Dans notre cas, il a été présent dès le cadrage du projet (avant le sprint 0) ce qui a permis : 

• À notre client de se projeter plus facilement dans le projet grâce à des maquettes en fils de fer. Le client a également pu plus facilement exprimer son besoin grâce à ce travail. 
• À notre UX Designer de connaitre les besoins et contraintes du client pour proposer le meilleur design et parcours client.   

Pendant le sprint 0, il a travaillé avec nous sur l’affinage des premières US pour qu’il puisse fournir les maquettes dès le sprint 1. Il a aussi défini la charte graphique et les éléments principaux de navigation. Son activité n’est pas constante tout au long du projet : au début, il doit fournir tout le socle de l’UX dans lequel les développeurs n’ont qu’à piocher pour le design des nouvelles fonctionnalités, sauf si un nouveau comportement est attendu. Dans ce cas, une intervention sur ce sujet sera nécessaire. En revanche, je trouve important qu’il soit présent jusqu’à la fin pour garantir la cohérence jusqu’à la livraison du produit final et éviter toute dérive.    

Accepter le changement 

Les trois développeurs de l’équipe étaient expérimentés sur les technologies utilisées. Un point qu’il a fallu gérer a été l’acceptation des changements, à la suite des retours utilisateurs ou suite aux découpages des US. Le fait d’itérer sur un écran et/ou une fonctionnalité, de faire une solution simple avant la solution définitive n’était pas bien compris. Il fut crucial de leur expliquer que le but était que les utilisateurs puissent se projeter sur la fonctionnalité future. Cette partie de mon job m’a demandé beaucoup d’écoute active, de compréhension des peurs sous-jacentes à ces réactions pour les aider à trouver la meilleure solution. J’ai essayé de ne jamais leur souffler une solution mais de faire en sorte qu’ils trouvent la solution adaptée à leur projet. Ils ont rapidement vu l’intérêt de montrer les fonctionnalités et d’avoir des retours.   

 

La phase projet : au cœur du sujet 

Périmètre / Coût / Délais 

La première chose à souligner est que nous avons respecté le budget et le délai ! Le périmètre s’est quant à lui ajusté au fil du projet. Au début, le client a choisi uniquement les besoins «MUST» que nous avons alors affinés sur notre story mapping. A la clôture du projet, en partant du story mapping initial, nous avons réalisé 99% des «MUST», 79% des «SHOULD», 65% des «COULD» et 50% des «WOULD» (méthode MoSCoW) avec le même budget. Comment est-ce possible me direz-vous ?  Voici les facteurs de réussite : 

• Une équipe stable et à temps plein pendant tout le projet 
• L’expérience des développeurs pour proposer toujours la solution la plus adaptée au besoin (et souvent la plus simple) 
• La réutilisation du socle technique d’un autre site du client qui nous a permis d’utiliser les ressources de ce socle pour des besoins métiers 
• Le PO à temps plein, impliqué, avec du pouvoir de décision et qui sait dire «Non» 
• Le travail en amont du PO avec les utilisateurs 
• Une vision claire et partagée avec tous, y compris avec les sponsors 
• L’utilisation de Drupal qui a permis une gestion facilitée des droits d’accès aux différents profils 

Si nous regardons le périmètre décrit initialement et le périmètre implémenté, nous nous rendons compte que certaines fonctionnalités n’ont pas été réalisées car elles sont devenues inutiles à la suite des retours utilisateurs. A l’inverse, et pour l’exemple, une démonstration nous a mis en lumière que le collaborateur à l’accueil du centre avait besoin tous les jours du planning des RDV pour faciliter l’accueil des volontaires, besoin