Équipe Scrum : comment s’organise-t-elle ? Part. I

Après avoir décortiqué la composition d’une équipe Scrum dans l’article « Équipe Scrum : comment est-elle composée ? », on fait le point sur l’organisation de cette team Agile et sur l’articulation de son framework à toute épreuve.

Avis à celles et ceux qui évoquent une méthode pour dépeindre Scrum, le terme consacré correspondrait plutôt à framework (cadre de travail). La différence ? Tandis que la méthode fige quelque peu le scénario de la gestion de projet, le framework laisse libre cours à l’improvisation. À l’instar d’une équipe de rugby, Scrum (mêlée en anglais) puise ses ressources directement sur le terrain en privilégiant l’apprentissage par l’expérience.

Framework Scrum : les éléments clefs

Agile et empirique, Scrum n’en est pas moins bordé de repères. Parmi ces jalons, trois piliers confortent la puissance de ce cadre de gestion de projet :

🔸 Les rôles : ils sont scrupuleusement répartis au sein de l’équipe entre le Scrum Master, le Product Owner et l’équipe de développement.
🔸 Les événements : Sprint, Sprint planning, Daily Scrum, Sprint review et Sprint retrospective sont tous time boxés (limités dans le temps) pour plus d’efficacité.
🔸 Les artefacts* : un framework Scrum se ventile en quatre artefacts (product backlog, sprint backlog, incrément, definition of done). Il s’agit de listes collaboratives permettant le partage d’informations de base entre les différents acteurs qui interviennent dans le cadre du projet.

*Issu du latin artis facta (effets de l’art), un artefact est un « phénomène d’origine humaine, artificielle, intervenant dans l’étude de faits naturels » – Définition issue du dictionnaire Le Robert.

Le socle de valeurs de l’édifice Scrum

A l’opposé d’une recette toute faite, Scrum joue la chorégraphie des petits pas et de l’itération. Si le framework pose des principes qui guident la team, nulle formule prédéterminée ne permet d’atteindre l’objectif. C’est là que le rôle du Scrum Master s’avère crucial dans la prise de décision et de réorientation du projet au fil de l’eau. Ce pro de l’impro redistribue les cartes à chaque étape avec en ligne de mire une logique d’amélioration continue. En soutien du framework, on retrouve les trois piliers phares que sont la transparence, l’inspection et l’adaptation :

🔸 La transparence : qui dit Scrum dit limpidité de l’information partagée entre chaque acteur engagé dans le projet. C’est là la condition sine qua non de l’inspection.

🔸 L’inspection : elle vise l’analyse des résultats des travaux de la team et s’appuie largement sur la transparence des échanges autour du projet. Sans inspection, pas d’adaptation.

🔸 L’adaptation : faisant suite à l’analyse, ce volet en exploite les résultats pour améliorer tous
les pans de la collaboration autour du projet.

Code développeurs SCRUM

Scrum : les 5 valeurs à respecter

Pour garantir un fonctionnement harmonieux au sein d’une équipe composée – ne l’oublions pas – d’humains, cinq valeurs évitent certains écueils liés à l’organisation de la production :

🔸 Focus : on retrouve ici la notion d’efficacité portée par la capacité à aller à l’essentiel,

🔸 Ouverture (Openess) : l’ouverture au changement fait partie de l’état d’esprit de chacun, à l’instar de l’ouverture aux idées alternatives que l’on sait accueillir avec bienveillance,

🔸 Respect : ingrédient incontournable pour un fonctionnement harmonieux en équipe, le respect porte aussi bien sur autrui que sur les engagements pris et les attentes des utilisateurs,

🔸 Courage : revenir sur ce qui a été fait et s’adapter en permanence demande du courage, tout comme faire preuve de transparence,

🔸 Engagement (Commitment) : quoi qu’il arrive, Scrum engage à faire de son mieux et ce, quels que soient les aléas du projet.

Les 5 événements clés d’une équipe Scrum

Au programme de cette trame Agile, cinq événements-clés scandent chaque projet mené en mode Scrum. Leur credo : produire plus, vite et mieux grâce à des durées optimisées et à des successions de phases prédéfinies.

Sprint : le tempo du projet

Entre 1 à 4 semaines

Il bat le rythme à la façon d’un cœur qui impulserait la cadence souhaitée. Un sprint Agile renvoie à une phase séquentielle de développement d’un produit. Véritable itération de courte durée (un sprint dure entre une et quatre semaines), il décompose un processus de développement pour le simplifier et le customiser en fonction des résultats obtenus à chaque étape. Dans le cadre d’un projet, les sprints s’enchaînent sans temps de pause entre chaque et se ventilent selon le schéma suivant :

🔸 Le Product Owner définit le travail à réaliser,

🔸 Les développeurs réalisent ce travail,

🔸 Le Scrum Master s’assure du fonctionnement optimal de la team.

Cas particulier : en cas d’obsolescence du produit en cours de développement pour cause de lancement d’une solution concurrente, le Product Owner peut annuler le sprint et en lancer un nouveau. Sa mission : mettre sur les rails une variante à valeur ajoutée (la plus en phase avec les attentes du marché) et ce, le plus rapidement possible.

Sprint planning : la ventilation des tâches

8h ou moins – Pour un sprint d’un mois, on est sur 8h. Pour un sprint de 2 semaine, plutôt 4h.

Ce travail de planification vise à organiser la mission qui se déroulera durant chaque sprintTandis qu’un sprint d’un mois nécessite en moyenne un sprint planning de huit heures réunissant toute l’équipe, quatre heures suffisent à planifier un sprint de deux semaines. Un sprint planning tourne autour de trois sujets :

🔸 Le pourquoi : autrement dit le sprint goal, la mission,

🔸 Le quoi faire : quels items seront planifiés dans le sprint,

🔸 Le comment faire : quelles tâches techniques les éléments précédents impliquent-ils ?

Contrairement aux tâches techniques dont l’évolutivité s’avère nécessaire tout au long du développement, le sprint goal ne change jamais.

📌 À noter : la definition of done renseigne les développeurs quant à la charge de travail que chacun est en mesure de s’attribuer dans le cadre d’un sprint.

sprint planning

Daily Scrum : développeurs only

⏰ 15 minutes maximum

Même heure, même endroit, tel est le leitmotiv des développeurs qui se réunissent une fois par jour pour quinze minutes au maximum. L’objet du Daily Scrum ? Établir un point d’avancement sur le travail réalisé et le travail restant à effectuer. Plus visuelle, l’utilisation d’un tableau aide à présenter la progression des items et des tâches. Chaque développeur s’exprime alors au sujet de ses actions à venir, en cours et des éventuels obstacles rencontrés dans l’atteinte du sprint goal. Côté formalité, c’est la libre expression qui est de mise avec l’inexistence de préconisations Scrum sur les prises de paroles.

Sprint review : en conclusion de chaque sprint

⏰ 4h ou moins

Comme son nom l’indique, le sprint review passe en revue les éléments marquants à chaque fin de sprint. Testing des nouvelles fonctionnalités par les utilisateurs et présentation des incréments apportés au produit en cours d’élaboration font ainsi l’objet d’un point réunissant l’équipe ainsi que les parties prenantes au sens large. En quatre heures maximum, on aborde les sujets suivants afin de déterminer si le produit est toujours en phase avec les besoins et si des adaptations s’imposent pour les prochains sprints :

🔸 Le Product Owner rappelle la nature du product goal (objectif à long terme) et du sprint goal (à court terme),

🔸 Les incréments réalisés lors du dernier sprint et conformes à 100% à la definition of donefont l’objet d’une démonstration animée par les développeurs sous la houlette du Product Owner. Les interactions et autres feedbacks émanant des utilisateurs finaux sont collectés et intégrés au product backlog.

Bon à savoir : parmi les missions du Product Owner figure la nécessité de dénicher les key users les plus proches des utilisateurs finaux afin de tester les fonctionnalités en conditions presque réelles.

🔸 Le sprint review comporte aussi une phase d’adaptation du travail restant à effectuer au sein du product backlog et de la feuille de route associée. Ce bilan permet de lister les étapes validées, de se projeter dans celles à venir et de penser à l’organisation et au contenu du prochain sprint.

Sprint retrospective : l’analyse du mode de fonctionnement

3h ou moins

La méthodologie et l’humain figurent en ligne de mire de cette étape de trois heures au maximum. Assurée par l’intégralité de la team Scrum, elle vise l’analyse et l’adaptation des points suivants : 

🔸 Les interactions au sein de l’équipe : communication entre les collaborateurs, détection d’éventuelles tensions,

🔸 Les façons de travailler et les outils utilisés,

🔸 La definition of done.

Pour en savoir plus au sujet des rituels agiles, téléchargez le livre blanc « Adapter les rituels agiles à distance »  ⤵️ 

Kanban ou Scrum : quel tableau Jira choisir ?

Tableau Kanban ou tableau Scrum pour votre projet Jira ? Découvrez dans cet article ce que proposent ces 2 modèles et leurs différences. Trouvez enfin le tableau adapté à votre équipe !

Contactez-nous

Share This