En quelques années, le mouvement agile et les technologies ont chamboulé les façons d’organiser le travail d’équipe dans le domaine du développement logiciel et même au-delà. Pourtant, même si l’on voit de plus en plus de Scrum Masters, de Product Owners dans les annonces des recruteurs, une fois à l’intérieur de l’équipe, on constate des différences d’interprétation dans la mise en œuvre, en comparaison des rôles définis dans le Scrum Guide. En tant que Coach Agile, je vous propose une grille de lecture d’une organisation s’appuyant sur le cadre de référence Scrum, un cheminement de pensée pour déceler les potentiels dysfonctionnements et aider à faire progresser votre équipe.
Organisation agile vs Rôles et Outils
Certaines questions sont utiles pour évaluer le bon fonctionnement d’une équipe. Attention, les réponses que vous pouvez obtenir à ces questions ne sont que des indicateurs partiels, instantanés. Ce que je peux parfois interpréter comme un problème a priori pour une équipe, n’en est peut-être pas un. Cela peut-être même une réponse à un autre problème plus profond, ou à des habitudes culturelles pas forcément conscientes ni inadaptées au contexte.
Voici donc quelques questions que je me pose pour appréhender l’organisation d’une équipe :
- Quelle est la mission de l’équipe ? Quels sont ses objectifs à court et moyen terme ?
- À quelle fréquence livre-t-elle des produits ou services à ses utilisateurs ?
- Quels sont les derniers résultats obtenus, les dernières réussites de l’équipe ?
- Quelle est sa place dans l’organisation et ses dépendances pour décider ou pour faire ?
Ensuite, à l’intérieur de celle-ci, on repère les postures et comportements, puis on vérifie s’ils sont bien ceux attendus dans la définition de chacun des rôles :
- Qui sont les porte-voix des utilisateurs et ceux des intérêts de l’organisation dans l’équipe ?
- Comment sont définies les priorités ?
- Comment les membres de l’équipe travaillent quotidiennement ? Sont-ils très autonomes et indépendants ou bien travaillent-ils en permanence les uns avec les autres ?
- Quelles sont les règles et standards applicables ? Sont-ils appliqués ? Challengés ? Si oui, Comment ?
Indépendamment de toute référence à une méthode ou cadre agile, ces questions révèlent déjà beaucoup de choses sur une organisation, sur ses points forts et ses points faibles et son adaptation au contexte, son agilité en somme.
Et ensuite ? Avant de proposer tout changement, il s’agit de respecter l’existant, ainsi que le passé qui a conduit « naturellement » à la situation présente. Cette acceptation collective permet de s’engager à changer plus facilement. Le premier levier n’est pas “vers quoi changer”, et encore moins quel outil mettre en place. Le changement commence par l’intérêt des personnes. Par le fait d’accepter l’idée du changement. Ce qui va se traduire ensuite en mouvement..
Tout changement dans une organisation s’inscrit dans une continuité.
Aussi, la définition des rôles sera un premier travail bénéfique, en inscrivant clairement comment chaque membre de l’équipe fait pour faire avancer l’organisation vers sa mission.
Product Owner, un rôle pivot dans l’organisation
Lorsqu’il s’agit de développer des produits, la première préoccupation est d’aligner ceux qui utilisent le produit et ceux qui le fabriquent. Scrum définit le rôle de Product Owner par la responsabilité d’une seule personne de représenter les utilisateurs auprès de l’équipe, et de donner à faire à l’équipe ce qui a potentiellement le plus de valeur pour les utilisateurs finaux. Une personne c’est peu, diront certains et cela représente beaucoup dans la culture d’une organisation. Par expérience, c’est juste ce qu’il faut pour prendre des décisions efficaces au nom des utilisateurs et de leurs multiples représentants, au moment où l’équipe en a besoin. En tant que Coach ou Scrum Master, une des premières actions est de rendre légitime le rôle du Product Owner dans l’organisation et de m’assurer que la personne qui occupe ce rôle est suffisamment à l’aise dans le costume, en lui proposant mon soutien.
Cela passe par une clarification du rôle de Product Owner et des changements de pratiques vis-à-vis des parties prenantes lesquelles doivent percevoir puis apprécier les bénéfices avant que l’on puisse s’autoriser à penser qu’un changement a bien eu lieu. Creusons un peu les pratiques…
Décomposer la valeur
Au-delà de partager ce qu’il faut faire avec les utilisateurs et les développeurs, l’alignement est également une question de valeur. Ce qui a de la valeur pour les utilisateurs selon le Product Owner, devrait aussi avoir de la valeur pour les développeurs (et vice-versa). Sauf que tant que les utilisateurs ou clients ne peuvent apprécier concrètement le résultat, il ne s’agit que d’hypothèses. Et le Product Owner peut parfois se tromper, sur l’intérêt d’une fonctionnalité, comme les utilisateurs peuvent se tromper sur l’idée du produit tout entier. Les développeurs peuvent aussi se tromper sur une solution technique, sous-estimer les difficultés dans sa mise au point ou son exploitation par exemple.
Aussi, plutôt que de parier gros en engageant une importante quantité de travail et de se rendre compte des écarts trop tardivement, il convient de procéder par petits pas, de manière itérative et incrémentale. Cela offre la possibilité de s’adapter et de s’aligner fréquemment. En tant que Scrum Master, je rends ce “doute” visible, je formule la possibilité de se tromper, que l’on soit Product Owner, Développeur ou Coach. Cela motive pour avancer petit à petit, pas uniquement pour construire, mais aussi pour apprendre et éventuellement changer. Même si l’on aurait souhaité tout savoir avant de se lancer…
Avancer au bon rythme. A un rythme soutenable.
Avec Scrum, la coordination des activités des différentes parties prenantes s’effectue à un rythme constant. La durée de sprint est fixée au départ entre 2 et 4 semaines. Ce cycle de développement doit être suffisamment rapide (mais pas trop non plus) pour limiter les gaspillages (temps d’attente, manque de feedback, spécifications inutiles…). Il en va de même des réunions : courtes, mais pas trop. Le rôle de Scrum Master est de présenter les règles de gestion du temps à l’équipe, aux parties prenantes, puis de les faire respecter. C’est en ce sens qu’on qualifie le Scrum Master de chef d’orchestre, même s’il n’est le chef de personne. Il donne le tempo et harmonise l’ensemble des partitions en accord avec les valeurs communes. Cela se traduit par l’enchaînement de sprints au cours desquels les parties prenantes, le PO et l’équipe réalisent les activités de définition et de partage des hypothèses avant de démarrer, de construction, d’intégration des éléments du produit et de livraison d’un résultat (de préférence dans un même sprint), puis de vérification de l’impact escompté dans la vie des utilisateurs. Ceci afin d’adapter le contenu des sprints suivants. Ce cadencement court demande à réduire la taille des éléments à réaliser pour qu’ils conviennent aux utilisateurs et aux développeurs.
Le Scrum Master clarifie les rôles : le sien, celui du Product Owner, celui de l’équipe de développement, ceux de chacun de ses membres, jusqu’aux rôles des parties prenantes. Son objectif global est de faciliter les interactions entre tous, pour maximiser la création de valeur par l’équipe Scrum. On peut qualifier le Scrum Master de Chien de berger (Sheep Dog), dans l’idée qu’il protège l’équipe des perturbations et diminue le risque de ne pas atteindre ses objectifs.
L’ancrage des rôles et attributions
Les organisations et les individus s’approprient rapidement les rôles de Product Owner et Scrum Master. Mais rapidement ne signifie malheureusement pas « facilement » et encore moins « convenablement ». Ce qui est souvent constaté dans les équipes est le besoin de définition et d’attribution définitive des rôles à chacun de ces membres. Cela intervient souvent dès le début, pour des équipes en formation, ou dès que l’équipe rencontre des difficultés à travailler ensemble. Si cela aide à la réalisation des objectifs, OK, mais si cela cloisonne, limite et ralentit le travail ensemble, attention ! Cette thématique du travailler ensemble et de l’auto-organisation est au coeur de l’agilité. Elle est devenue essentielle pour bon nombre d’organisations et mérite au moins un nouvel article dédié…
Les rôles dans le flux
Une façon de penser est que pour qu’une certaine tâche soit bien faite, à moindre coût et dans les meilleurs délais, il faut qu’elle soit attribuée à la personne spécialiste de ce type de tâche. On peut nommer cette pratique le mode « push ». Pour que cela fonctionne, cela suppose plusieurs choses. Il existe au moins une personne spécialiste avec les moyens, compétences et disponibilité suffisante pour réaliser la tâche. La personne chargée de répartir les tâches possède toutes ces informations afin de solliciter la personne la mieux placée selon lui. Enfin et surtout, cette personne en connait suffisamment sur comment réaliser la tâche au mieux pour l’attribuer au meilleur sachant-faire. Ce rôle correspond bien souvent à un idéal d’optimisation locale imaginaire avec des effets indésirables sur la dynamique d’ensemble et la motivation des individus.
Un autre mode de fonctionnement est que chaque membre de l’équipe prenne les tâches qui sont proposées dans une file d’attente. Ce qui est assez répandu pour les flux d’activité de Support, pour répondre rapidement aux appels/demandes utilisateurs, est moins fréquent dans les équipes de développement. Peut-être que cela laisserait sur le côté les tâches trop difficiles ou trop peu intéressantes ou diminuerait la qualité directement liée aux compétences de chacun. Ce mode « pull individualisé » ne facilite pas non plus la prise de recul collective. Le flux de travail que l’on souhaite continu, peut devenir variable, tendu et les blocages fréquents.
Enfin, un autre mode de fonctionnement, préconisé par Scrum, définit que c’est l’équipe entière qui se prononce sur l’ensemble des éléments prioritaires à réaliser et réalisables pendant une courte période de temps, c’est à dire le prochain sprint. Cela provoque un flux de création de valeur en palier, qui reflète l’intérêt de faire évoluer le système progressivement entre deux états stables pour mieux maîtriser les changements en équipe. Le cycle de développement en sprint se veut ainsi soutenable pour l’équipe et entrainer l’ensemble de l’organisation. La principale mesure d’avancement est d’avoir un produit ou un logiciel qui fonctionne, avec une valeur croissante pour les utilisateurs.
Une évolution possible de ce dernier mode est d’aligner les livraisons de petits éléments de valeur à la demande du client et potentiellement plusieurs fois par sprint. OK, tant que l’on maîtrise le flux et que le rythme est soutenable.
Au delà de l’explication initiale, l’enjeu de l’évolution vers tel ou tel mode est que tous les rôles dans l’organisation en tirent un certain bénéfice individuel et que les pratiques fassent sens pour l’atteinte des objectifs communs.
Ce n’est que le début
Voici quelques bases à avoir en tête et à partager au niveau de l’équipe pour ajuster son organisation. Restez connectés à notre blog car un prochain article va suivre sur le rôle du Développeur dans Scrum et sur l’organisation multi-équipes.
Nos consultants sont des experts de l’agilité avec Jira. Si vous avez des questions ou défis que vous souhaiteriez partager avec nous, nous serons ravis de vous aider.
Contactez Nous
