Introduction à l’agile SCRUM

L’agilité et le Scrum, Kézaco ?

L’agilité se présente comme une « méthodologie » (nous pourrions même dire une idéologie !) de gestion de projet.

Il n’existe pas une seule et unique façon d’être agile dans son travail (les concepts ont été théorisés dans le Manifeste Agile), mais plusieurs approches. Ces approches sont basées sur quatre valeurs fondamentales.

Ces dernières valorisent :

• Les individus et leurs interactions plus que les processus et les outils,
• Des logiciels opérationnels plus qu’une documentation exhaustive,
• La collaboration avec les clients plus que la négociation contractuelle,
• L’adaptation au changement plus que le suivi d’un plan.

L’Agile se base également sur 12 principes qui sont les suivants :

1. Satisfaire le client est la priorité
2. Accueillir les demandes de changement « à bras ouverts »
3. Livrer le plus souvent possible des versions opérationnelles de l’application
4. Privilégier la conversation en face à face
5. Construire des projets autour d’individus motivés
6. Responsabiliser les équipes
7. Faire avancer le projet à un rythme soutenable et constant
8. Porter une attention continue à l’excellence technique
9. Favoriser la simplicité
10. Mesurer l’avancement opérationnel du projet
11. Les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées.
12. Ajuster, à intervalles réguliers, ses pratiques et processus pour être plus efficace

L’une des approches Agile les plus répandues est l’approche SCRUM, je vous invite d’ailleurs à consulter le Guide du Scrum qui est téléchargeable sur scrum.org.

« Scrum » est un cadre de travail fondé sur l’empirisme : la connaissance provient de l’expérience et la prise de décision doit être basée sur des faits connus.

Ça, c’est dit !! Et là vous vous dites « Moué, mais concrètement on fait comment ? »

Concrètement ? on maximise les feedbacks et les itérations ; en Agile SCRUM on y va “step by step” (ou sprint par sprint plutôt 😊) : on développe d’abord un « MVP » (Most Viable Product) qui proposera les fonctionnalités les plus basiques du produit et ensuite on y ajoute d’autres fonctionnalités une à une – ou on en supprime si nécessaire, oui oui !

Les cycles de développement sont courts (« sprints ») afin de pouvoir rectifier le tir régulièrement si les besoins ou le marché évolue – d’où une certaine « agilité ». On diminue le « time to market » et on pense amélioration continue.

STOP aux cahiers des charges de 247 pages et au produit qui sort (ou pas) après deux ans de dev. !

Mettre en place une approche Agile SCRUM bouscule complètement nos habitudes de gestion de projet classique et nécessite d’abord d’accepter plusieurs éléments que je vais citer dans les prochaines parties.

Le “mindset” de l’approche Agile Scrum

La traduction littérale de Scrum en français est « mêlée », comprenez ici que la notion de « hiérarchie » est remplacée par celle de « rôle » au sein d’une équipe. Une équipe devra d’abord adhérer aux mêmes valeurs fondamentales de l’Agile Scrum : l’engagement, le courage, le focus, l’ouverture et le respect.

Les membres de l’équipe s’engagent personnellement à atteindre les objectifs communs, et ont le courage de prendre les bonnes décisions. Chacun se focalise sur les taches à réaliser et accepte d’être ouvert sur le travail nécessaire et les défis à relever. Les membres de l’équipe se respectent mutuellement.

La relation hiérarchique et la distribution des responsabilités en agile sont horizontalisées au maximum. Il n’y a donc pas un responsable mais des responsables.

Aussi, trois piliers vont permettre l’implémentation du contrôle « empirique » voulu par l’approche Scrum :

• La transparence : tous les aspects importants d’un projet doivent être connus de tous ceux potentiellement responsables des résultats. Pour ce faire il faut parler un langage commun et définir des standards partagés (définition commune de « fini », « prêt », etc). Un mot d’ordre : communication !
• L’inspection : les utilisateurs de l’approche Scrum doivent régulièrement inspecter leur niveau d’avancement et les potentiels freins à l’atteinte de leur objectif commun (« sprint goal »). Il est de la responsabilité de l’équipe de s’auto-évaluer, c’est un des principes fondamentaux de l’approche Agile Scrum. Vive l’introspection (en essayant de rester objectif évidemment) !
• L’adaptation : qui dit « introspection » dit « action ». Dès qu’un élément ou un aspect du process dérive ou introduit un risque pour le projet : on ajuste !

Un planning aux petits oignons

Pour avoir la capacité d’inspecter et de s’adapter régulièrement, Scrum prescrit 4 événements indispensables (aussi appelés « cérémonies ») qui vont rythmer la vie du projet et de l’équipe.

• La Planification du sprint (« Sprint Planning ») : c’est lors du sprint planning que l’équipe défini le scope des travaux qui seront à réaliser au prochain sprint (Sprint Backlog). La durée du sprint est décidée par l’équipe et peut être conditionnée par le marché, le type de produit, la technologie, les interdépendances etc. Le sprint backlog est créé de manière collaborative par tous les membres de l’équipe Scrum.
• La mêlée quotidienne (« Daily Scrum Meeting ») : événement de 15 minutes maximum, tenu tous les jours. Cette mêlée permet à l’équipe de développement d’inspecter le travail réalisé, le process utilisé, d’identifier les bloqueurs potentiels et d’envisager le travail restant au sein du sprint. Cela optimise la collaboration et la performance de l’équipe.
• La revue de sprint (« Sprint Review ») : cet événement se tient en fin de sprint et permet à l’équipe d’inspecter les développements réalisés (« sprint increment ») et d’identifier les problématiques liées  au prochain sprint.
• La rétrospective de sprint (« Sprint Retrospective ») : cet événement se tient également en fin de sprint, mais avant le « Sprint Planning ». C’est l’opportunité pour l’équipe Scrum de s’auto-inspecter. Le but est de réfléchir à des axes d’amélioration qui seront à adopter au cours du prochain Sprint.

Ça y est vous êtes incollable sur l’approche Agile Scrum et les événements indispensables à sa mise en place… Mais tout cela ne serait pas réalisable sans la Scrum team !

Le refinement : Le refinement n’est pas un événement obligatoire dans l’approche Scrum. Néanmoins dans les faits, cette cérémonie se rend vite indispensable. C’est lors du refinement que l’équipe va pouvoir échanger sur les futurs items qui seront à développer : UX / UI, techniques, fonctionnalités, etc. C’est une plage d’échange primordiale afin de construire intelligemment le backlog produit et d’anticiper les potentielles difficultés.

A chacun son rôle !

Le mise en place de l’Agilité en approche Scrum va nécessiter l’organisation d’équipes ou chaque membre aura un rôle bien défini.

Il y a 3 rôles majeurs dans une Equipe Scrum : “Product Owner”, “Scrum Master” et “Membre de l’Équipe de Réalisation” (development Team).

Toutes les personnes qui ne font pas partie de l’équipe Scrum listées ci-dessus sont désignées comme les « Parties prenantes » (« Stakeholders »).

Tour d’horizon sur les fonctions de chacun

Le Product Owner : Le fameux ! Le Product Owner est celui qui détient la vision produit, il a la charge de maximiser la valeur du produit et s’assure :

• Qu’il existe une liste claire de ce qu’il y a développer : le « Product Backlog ».
• Que cette liste soit ordonnée par priorité, afin de maximiser la valeur fabriquée.
• Que chaque élément de la liste soit d’assez petite taille, pour que l’équipe délivre de la valeur rapidement et fréquemment (découpage des items en « User Stories »).

Il est le seul responsable du « Product Backlog » et est le décideur final sur toute modification de ce dernier. Dans ce contexte, le Product Owner doit être ouvert au changement et avoir une aptitude à négocier. Il doit prendre des décisions objectives rapidement.

Le Product Owner fait aussi le lien entre l’équipe Scrum et toutes les parties prenantes. Il communique auprès des parties prenantes en amont (identification des besoins) et en aval des développements (recette, validation, suivi des délais et budgets, pertinence des développements réalisés, …).

Dans le cadre de gros projets, si les membres de l’équipe de réalisation sont nombreux, le Product Owner va pouvoir s’appuyer et déléguer à un « Proxy Product Owner ». Le PPO va aider le PO dans ses taches comme la rédaction des US par exemple. Néanmoins le PO reste le garant de la valeur produit et du backlog.

Le Scrum Master : C’est un facilitateur ! Il s’assure que les conditions sont réunies pour permettre à l’équipe d’atteindre son objectif :

• Organiser et animer les cérémonies et s’assurer sur respect du process Agile Scrum.
• Aider l’équipe à prendre en maturité.
• Mettre en place les outils de management visuel.
• Identifier, prioriser et résoudre les points bloquants et obstacles.

Le Scrum master aide l’équipe à s’auto évaluer et à identifier les axes d’amélioration, dans un esprit constructif et positif. Il est garant de l’ambiance au sein de l’équipe. Le Scrum Master n’est pas « chef de projet » ni « manager », il sait animer sans notion d’autorité ou de hiérarchie. Il est au service de l’équipe.

L’équipe de réalisation : Tous les profils permettant la réalisation du projet sont associés à l’équipe de réalisation : développeur, UX UI designers, testeurs, etc…  Vous vous souvenez du fameux « Mindset » ? on y est :  l’équipe de réalisation doit être auto-organisée ! Evidemment, cela n’est pas toujours simple, et va nécessiter un certain niveau de maturité de l’équipe.
Les membres définissent les tâches à réaliser pour fabriquer chaque élément du backlog et les estiment (en temps et difficulté). Ils se répartissent les tâches entre eux, au jour le jour, au moment de la fabrication, en respectant l’ordre des priorités.

Quand Agilité rime avec adaptabilité !

Oui, oui, je sais. Il est rare de rencontrer des projets ou toutes les exigences Agile Scrum sont scrupuleusement respectées. Souvent certains bouts restent manquants : une équipe sans Scrum Master, un PO avec plusieurs équipes, pas le temps de faire toutes les cérémonies, etc.
Que celui qui a déjà vu un projet Agile Scrum suivant toutes les règles se fasse connaitre !

La mise en place d’un projet Agile Scrum au sein d’une organisation est forcément « sur mesure », l’important étant de garder les bons réflexes : user centric, empirisme, itérations, inspection, amélioration continue. Il faut toujours s’adapter au contexte ! C’est aussi ça l’agilité.

Pour aller plus loin

Chez Cellenza nous sommes convaincus de la puissance que l’agilité a sur la gestion des projets informatiques. Nous avons donc crée le Studio Cellenza pour donner à nos clients une solution clé en main pour développer des projets web et mobiles avec nos experts. A ce sujet, découvrez le retour d’expérience de notre client Edenred qui a choisi de travailler avec le Studio pour son projet mobile.

Si ce sujet vous intéresse, laissez-nous un commentaire !