Rituels agiles : rôles et structure dans le Scrum
On parle beaucoup de méthodes et rituels agiles, de leur efficacité et de leur souplesse. Cependant, l’agilité n’est pas sans cadre. En effet, il existe plusieurs méthodes agiles, ainsi que plusieurs spécificités dans la manière d’implémenter le manifeste agile. Bien qu’il n’existe pas de méthode universelle, Scrum est celle qui s’y prête le plus, dans le contexte de l’IT. C’est, de fait, la plus implémenté aujourd’hui dans l’IT.
Attention, c’est une méthode qui demande beaucoup de rigueur, en particulier concernant le respect des rituels.
En effet, tout le fonctionnement de Scrum repose sur un cadre bien précis :
- des rôles bien définis avec un périmètre clair et borné
- des rituels cadrés et limités dans le temps(time-boxés)
- les principes et valeurs de l’agilité
Dans cette première partie nous présentons les rôles et la structure de nos équipes et rituels.
Cérémonies et rituels agiles : l’agilité n’est pas une religion, ni un sport, mais elle en emprunte quelques codes
On reconnait souvent la pratique de Scrum, dans certaines entreprises, par la présence des notes de couleur, disposées sur les murs des espaces de travail. Dans la pratique, il existe d’autres éléments, comme les outils informatiques, les jeux pour réaliser le produit, ainsi que nombre de cérémonies rythmant la vie d’une équipe agile.
Nous allons évoquer ici le déroulement des rituels mis en place au sein du Centre de service (CDS) de Blue Soft. Mais tout d’abord, il est important de présenter succinctement les acteurs, les types de story ainsi que la vie du Backlog.
Dans nos équipes agiles, vous trouverez les rôles suivants :
- Le Product Owner (différent du chef de projet)
- Le ScrumMaster
- Le Développeur (pour ce rôle, nous pouvons avoir jusqu’à cinq développeurs au maximum)
Nous estimons que la bonne taille d’une équipe agile est de sept à neuf personnes maximum.
Chez Blue Soft, notre particularité tient au fait que l’équipe peut être suivie par un architecte à hauteur de trois jours par sprint, dans le cas notamment des offres de services agiles (Agilité As a Service) de notre CDS.
Au cours d’un sprint, nos équipes peuvent embarquer quatre types de stories, que l’on peut classer en deux catégories :
Les stories permettant de rajouter de la valeur au produit :
- Story fonctionnelle
- Story technique
Les stories permettant de rétablir la valeur :
- Remboursement de la dette technique
- Correction de bug
L’ensemble des stories constituent le Backlog, qui représente la vie du produit.
Dans Scrum, nous avons en général plusieurs « bacs » qui constituent la vie du Backlog :
- le bac à sable
- le bac à glace
- le bac de culture
- le bac de départ
Chez Blue Soft nous ne considérons pas le bac à glace du Backlog.
Nous partons du Bac à sable pour déverser directement vers le Bac de culture, sans passer par le Bac à glace. Le processus continue du Bac de culture vers le Bac de départ, afin de de constituer le sprint Backlog. Ce passage entre les bacs s’effectue pendant les ateliers de Refinement du Backlog.
Le contexte Scrum chez Blue Soft étant posé, nous pouvons évoquer le déroulement des rituels.
La première valeur de l’agilité est de privilégier les interactions entre les individus, plus que les outils et les processus. Concrètement, cela se traduit par une recherche d’équilibre au quotidien entre les interactions des individus et les processus.
Le déroulement de tous les événements est borné par la notion du time-boxing.
Les rituels agiles : Le Product Backlog Refinement type chez Blue Soft
La réunion du Product Backlog Refinement est très souvent négligée et méconnue de certains. Pourtant, elle est d’une grande utilité dans la pratique de Scrum au quotidien.
Objectif :
Elle sert, dans un premier temps, à préparer le Backlog du produit. Chez Blue Soft, elle peut être planifiée plusieurs fois dans un sprint :
- afin d’affiner le Backlog, avant le sprint Backlog,
- en fin de première semaine pour un sprint de deux semaines et en fin de deuxième semaine pour un sprint de trois semaines. Le but est d’apporter des réajustements dans le sprint en cours,
- si l’équipe en exprime le besoin, afin de monter des ateliers et des points nécessaires au bon déroulement du sprint.
Prérequis :
- Le bac de départ doit être à jour, pour une préparation du sprint Backlog
- Le Backlog doit contenir des items déjà amorcés, afin de faire du réajustement au cours du sprint
- Les participants doivent avoir été préalablement informés avant l’atelier.
Les participants sont soit l’équipe seule, soit l’équipe avec les experts métiers et l’architecte ou encore nos UX-Experts, qui interviennent lors de certaines phases de développement de nos produits.
Les rituels agiles : le Standup Meeting type Chez Blue Soft
Cette réunion quotidienne est désignée officiellement par le terme Daily Scrum Meeting (DSM). Son but, au quotidien, est d’optimiser les chances, pour l’équipe, d’atteindre ses objectifs et de tenir ses engagements sur le sprint.
Pour le déroulement d’une DSM, nous nous appuyons, chez Blue Soft, sur l’inspection et l’adaptation en :
- identifiant rapidement les obstacles nuisant à l’avancement de l’équipe,
- améliorant et en mesurant, quotidiennement, l’avancement du travail de l’équipe sur le sprint,
- préparant les travaux nécessaires pour finir les stories.
Prérequis :
Afin de s’assurer de l’efficacité de la reunion, une préparation préalable de chaque membre de l’équipe, pour le respect du formalisme nécessaire au ceremonial, est necessaire. Toute l’équipe participe : le Product Owner, les développeurs et le ScrumMaster.
Cette réunion doit durer quinze minutes maximum et est animée par le Scrum Master. C’est un cérémonial qui appartient à l’équipe.
Il est recommandé de se retrouver devant le tableau « Scrum board ». Chaque membre de l’équipe s’exprime à tour de rôle afin de répondre aux questions suivantes :
- Qu’est-ce qui a été fait la veille ?
- Qu’est-ce qui a été fait le jour même ?
- Quelles sont les taches à faire ?
- Existent-ils des blocages ?
NB : ce n’est pas une « revue des troupes », mais la possibilité d’offrir une visibilité globale sur les taches et la transparence sur la vie de l’équipe.
Le résultat en sortie consiste en :
- Un Backlog actualisé avec des taches qui collent au plus près de la réalité.
- Une visibilité sur le produit, sur ce qu’il reste à faire et sur les points de blocage.
- La mise en place d’un plan d’action en cas de retard ou de contrainte forte
- Une projection sur la tendance du produit et un aperçu sur la vie de l’équipe.
Les rituels agiles : Le Sprint planning type Chez Blue Soft
C’est le plus connu des rituels Scrum.
Objectif :
Mettre l’équipe dans les situations idéales pour réussir le sprint. En clair, c’est mettre le cadre et les moyens qui favorisent les engagements de tous, dans une étroite collaboration.
Prérequis :
- Le bac de départ étant indispensable à cette réunion, un Backlog doit être prêt. Des stories priorisées par le Product Owner et le Scrum ou avec l’équipe sont à préparer lors d’une session préalable de Backlog de Refinement.
- La définition de Story prête comprise par tous les membres de l’équipe
- Un Backlog prêt et dimensionné pour le sprint avec des stories respectant les conditions.
Toute l’équipe participe, soit : le Product Owner, les développeurs et le Scrum Master.
Durée :
Entre deux et quatre heures
Déroulement :
Pendant quelques années, cette réunion était réalisée en deux phase, dont une première pour l’identification des stories à embarquer dans le sprint et une deuxième phase pour le découpage des story en taches.
Cependant, si ce format long perdure chez certains, d’autres comme Blue Soft ont fait le choix de le scinder en deux. La première phase, classique qui permet de dimensionner le sprint et d’assurer la compréhension des stories par l’équipe. La seconde phase comporte le poker planning et le découpage des taches ( posant ainsi le poker planning comme rituel à part entière).
En résumé, Le Product Owner annonce les stories, par ordre de priorité. Il présente chaque story à l’équipe. Cette dernière s’assure alors qu’elle est prête, compréhensive et suffisamment petite pour être réalisée.
A chaque story, l’équipe doit s’assurer :
- de la compréhension du besoin exprimé, le contexte et les règles métiers,
- que la story réponde aux critères de réalisation, de finition et aux conditions d’acceptations,
- que la story remplisse bien les conditions définies, pour la considérer prête.
Une fois que l’équipe a validé l’ensemble des éléments d’éligibilités de la story, elle effectue une estimation grossière de sa réalisation.
NB : Il est possible de sortir les estimations des taches dans un autre cérémonial lorsque, en réalisant un Poker planning ou Magic Estimation (Ces deux rituels ne sont pas traité dans cet article)
Le résultat en sortie consiste en :
- Des items estimés, chiffrés avec des engagements de l’équipe.
- Des stories détaillées, discutées et découpées en tâches pour le sprint.
- Un engagement de l’équipe sur la réalisation des tâches estimées.
- Un plan.
