Que faire lorsque l'Agilité devient trop rigide ?
Auteur : Gil Broza
Source : What to Do When Agile Turns Rigid
Date : 02/03/2016
Traducteur : Guillaume Roucou
Relecteurs : Fabrice Aimetti, Sébastien Solere
Date : 30/04/2016
Traduction :
La promesse faite par l'agilité est de réaliser des produits à moindre coût, de meilleure qualité et plus rapidement. Et pour bien commencer, rien de tel qu'un kit de démarrage avec des processus clairs, un ensemble de pratiques documentées, des outils, voire même des consultants certifiés. Il n'est pas étonnant que l'agilité soit devenue la nouvelle tendance dans les petites et grandes organisations.
Mais voilà le problème : les améliorations tant espérées ne suivent pas toujours et laissent placent parfois même à des effets négatifs non souhaités. En tant que consultant, je suis souvent sollicité pour intervenir lorsque la mise en oeuvre de l'agilité n'apporte pas les bénéfices attendus. Et bien que les équipes tentent différentes approches, leur point commun est d'avoir commencé à utiliser très tôt les outils de gestion de projet agile les plus populaires :
- Dès le début, ils ont commencé à utiliser l'un des outils les plus populaires pour la gestion du cycle de vie agile (ALM).
- Ils utilisent Scrum, faisant de leur mieux pour appliquer à la lettre les rituels, artéfacts et rôles.
- Ils mettent en oeuvre la plupart des bonnes pratiques associées à l'agilité.
- Ils créent des boucles d'amélioration continue à différents niveaux. Ils essayent tant bien que mal, mais leurs process ne s'améliorent que trop peu.
L'Agilité n'est pas une recette miracle. C'est un état d'esprit.
L'Agilité est une approche spécifique du travail. Elle nous aide à décider ce sur quoi il convient de travailler, à planifier les travaux, à faire collaborer les personnes. Elle nous guide également dans la constitution des équipes et nous apprend à travailler efficacement. Cet état d'esprit se retrouve dans la structure de l'équipe, la modélisation des processus, les pratiques, le choix des outils, les rituels et les artéfacts. Si on se représente un axe rigidité - flexibilité, la plupart des équipes que je rencontre ont une approche du travail trop dirigée vers l'extrémité rigidité, en particulier le cycle Scrum et ses bonnes pratiques associées.
La source de cette rigidité est une conviction partagée par tous les membres de l'équipe : "pour être Agile, nous devons nous organiser d'une certaine manière et appliquer les pratiques préconisées". Les équipes pensent qu'en appliquant à la lettre les bonnes pratiques Agile, elles sauront atteindre les bénéfices tant espérés. En réalité, cela amène à une gestion de projet robotisée. Vous serez Agile si vous appliquez son état d'esprit.
L'état d'esprit Agile
Voici quelques exemples de dualités dans l'interprétation des directives Agile, liés notamment à l'usage des termes "doit" et "devrait".
Mêlées quotidiennes : Vous n'êtes pas obligé de vous retrouver debout en cercle tous les jours à la même heure pour répondre aux trois questions récurrentes. Le but recherché est de coordonner de façon régulière les activités de l'équipe, afin de maximiser les chances de terminer et livrer le travail à l'issue de l'itération. On pourrait imaginer n'avoir qu'une seule question ouverte du type : "Quelle meilleure valeur pouvons-nous apporter dans les prochaines 24 heures pour converger vers notre objectif d'itération ?" Cette question amène à la collaboration en évitant de mettre l'accent sur les contributions individuelles.
Rédaction des items du backlog : Vous n'êtes pas obligé de rédiger chaque item du backlog sous le format "En tant que..., je souhaite... afin de..." L'usage de ce modèle de façon exclusive est surtout à préconiser dans une phase de formation. En réalité, il est très fréquent de constater que les exercices du type remplir-les-trous conduisent à des items trop verbeux, maladroitement formulés ou tout simplement redondants. Au lieu de cela, il est possible d'écrire brièvement et de communiquer : Quelle valeur apporte cet item de travail ? A quel problème ou besoin répond-il ? Qui est concerné ? Comment saurons-nous que nous avons terminé ? Utiliser ces questions comme une check-list, en évitant le format systématique, vous permettra de prendre vraiment conscience du besoin réel.
Planification de sprint : Vous n'êtes pas obligé de passer d'interminables heures à planifier le sprint, analyser et estimer chaque micro-tâche. En particulier dans le monde du développement de logiciels où il est difficile de déterminer correctement l'intégralité des tâches. Certaines équipes trouveront cela utile alors que d'autres seront rongées par l'ennui. L'important ici est d'identifier de manière collaborative la quantité suffisante de travail pouvant tenir dans la prochaine itération. Cette planification ne doit pas être réalisée trop tôt, barrant ainsi la route à toute adaptation. Certaines équipes prennent le parti de préparer en permanence une liste des items les plus probables. Ainsi, lorsque vient l'heure de la planification, les membres de l'équipe ont déjà une idée assez claire de la liste des items qui pourront être intégrés dans la prochaine itération.
Propriété d'une tâche : Une story ou une tâche n'appartiennent pas à une seule personne. C'est pourtant ce que l'on pourrait penser en utilisant des logiciels de gestion de projet agile. Toutefois, il s'agit simplement d'une limitation de l'outil plutôt qu'une règle. Cela a pour conséquence de renforcer la responsabilisation individuelle, là où l'agilité promeut la collaboration de l'équipe pour l'atteinte d'un objectif commun dans le but de satisfaire le client. Permettre aux membres d'une équipe de collaborer et se transmettre éventuellement des tâches entre eux favorise la pertinence du livrable. Ne dit-on pas qu'il y en a plus dans plusieurs têtes que dans une seule ?
Choisir un ScrumMaster et un Product Owner : Notamment pour les très petites équipes, vous n'êtes pas obligé de dédier un ScrumMaster et un Product Owner choisis hors de l'équipe de développement. Par contre, ces rôles doivent être obligatoirement représentés. Une personne doit s'occuper de gérer le travail à réaliser d'un point de vue métier, alors qu'une autre s'affaire à aider l'équipe à réussir en tant qu'équipe. Ils ont certainement besoin d'avoir le niveau de connaissance suffisant, d'être compétents, expérimentés et efficaces, mais si vous êtes à court d'options plus appropriées, il peut être envisagé de définir ces rôles parmi les membres de l'équipe de développement, un manager ou un consultant. Restons tout de même pragmatique.
Réunions de démonstration systématiques : Vous ne devez pas absolument réaliser une réunion de démonstration de façon systématique s'il n'y a pas lieu d'en avoir. Un exemple courant est lorsque seul le Product Owner y assiste et qu'il a déjà tout vu dans le courant du sprint. Préférez aller au-delà de l'objectif de l'itération en recueillant du feedback sur les fonctionnalités nouvellement ajoutées auprès des utilisateurs qui en ont fait la demande. Il y a tellement de façon d'obtenir du feed-back.
Alors comment rendre l'Agilité vraiment Agile ?
A votre avis, sur une échelle allant de rigide (à respecter scrupuleusement) à flexible (à adapter), que mettriez-vous au plus proche de l'extrémité rigide ? Les rôles, les artéfacts et les rituels ? Certainement pas. Nous y verrions plutôt les valeurs et les principes. Ces derniers doivent venir souligner, imprégner et renforcer chaque action. Ces principes incluent par exemple de "reporter les décisions au dernier moment responsable", "obtenir du feed-back de façon régulière", "échouer vite et pour pas cher et maximiser les leçons apprises" et "collaborer au sein d'équipes multidisciplinaires, semi-autonomes et auto-organisées". C'est ce qui rend l'Agilité vraiment Agile et génère des bénéfices.
