Que faire lorsque l’Agilité devient trop rigide ?

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 devenu 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 par 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 :

• 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’Agile 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 agiles, 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 guidelines agiles, liés notamment à l’usage des termes anglais have to et should.

Daily Meeting – 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 Product Backlog – Vous n’êtes pas obligé de rédiger chaque User Story sous le format « En tant que…, je peux… 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 User Stories trop verbeuses, maladroitement formulées ou tout simplement redondantes. Au lieu de celà il est possible d’écrire brièvement et de communiquer : Quelle valeur apporte cette brique 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 modèle 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 maintenir en permanence un matelas de User Stories prêtes. 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 User Stories qui pourront être intégrées dans la prochaine itération.

Propriété d’une tâche – Une User Story ou une tâche n’appartient 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 d’amener de la redevabilité 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 Product Backlog d’un point de vue métier, alors qu’une autre s’affaire à soutenir le travail en é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.

Démonstration systématique en fin de sprint – 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 feed-back sur les fonctionnalités nouvellement ajoutées auprès des utilisateurs qui en ont fait la demande. Il y a tellement de façon de 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 », « 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’agile vraiment agile et procure les bénéfices promis.