Press "Enter" to skip to content

L’Agilité c’est facile. Si c’est dur, c’est parce que vous vous compliquez la vie.

L’Agilité c’est facile. Si c’est dur, c’est parce que vous vous compliquez la vie.

TK Titres alternatifs :

L’Agilité c’est facile en théorie. En pratique, on se complique la vie.

L’Agilité c’est facile. Arrêtez de vous compliquer la vie !

TK Propositions de sous-titre :

La différence entre théorie et pratique : nous sommes des êtres humains

Vous trouvez le titre provocateur ? Pourtant, c’est souvent ce que je constate dans les équipes : on se complique la vie plutôt que de faire simple et d’aller à l’essentiel — plutôt que de se concentrer sur ce qui apporte réellement de la valeur ! Et après on se dit que c’est super dur d’être Agile.

Dans cet article je ne compte pas me focaliser sur les cas plus extrêmes des entreprises qui ne pratiquent l’Agilité ou Scrum que dans le nom de la méthode : j’ai déjà fait ça dans un précédent article.

Non, aujourd’hui je vais citer, en vrac, des situations où des équipes rencontrent des difficultés à mettre en place l’Agilité… Et où systématiquement, la réponse qui me vient à l’esprit c’est :

Mais, pourquoi vous vous compliquez la vie ??? Faites simple !

Ma définition de l’Agilité : le bon sens

L’année dernière j’ai participé à un petit atelier avec ma société Wemanity, où le but était de représenter notre définition de l’Agilité. Voici la mienne :

L’Agilité, c’est le bon sens !

Pour moi, l’Agilité c’est le bon sens — un bon sens qu’on a trop tendance à oublier dans le monde de l’entreprise.

Qu’en dit le Manifeste Agile ? Le 10e principe parle de la simplicité :

Simplicity — the art of maximizing the amount of work not done — is essential.

Voici la définition de l’Agilité que donne Alistair Cockburn :

Agile is early delivery of business value and less bureaucracy.

Moins de bureaucratie = simplicité dans les process, dans les interactions, dans les outils…

Pour résumer : l’Agilité c’est avant tout simplifier et garder simple les choses.

Des exemples de choses simples qu’on a rendu compliqué

Les Feature Teams

Le problème : le projet a été positionné dans un silo technique, nous sommes de facto une component team pour le reste de l’organisation. Impossible pour nous de s’organiser en feature team !

J’ai plusieurs fois eu l’occasion de travailler dans des projets que l’organisation a placés, de facto, en Component Teams. Par exemple le projet Player à la Direction du Numérique de France Télévisions, est un projet transverse fournissant le Player à tous les autres projets. Dans ce genre de contexte, la mise en place de Feature Teams au sein du projet est assez compliquée, du moins pas naturelle. On passe son temps à assurer un support aux autres équipes, à implanter des fonctionnalités pour un peu tout le monde plutôt qu’à construire et concrétiser une vision produit.

La solution : avoir une vision claire ! Oui, tout simplement. Dès lors qu’un besoin fonctionnel est bien identifié, il est simple de mettre en place une feature team qui va le prendre en charge, de bout en bout. C’est le fameux purpose, le but, la raison d’être, qui guide tout à chacun. Ayez un but et une raison d’être clairs et vous verrez que tout en découle.

Pour le reste, c’est très simple :

Le plus dur c’est d’essayer.

Avoir une vision claire, une mission

Le problème : l’équipe se plaint de ne pas avoir de visibilité sur le backlog à venir. Nous n’avons pas assez d’itérations d’avance de prêt ?

Ce genre de constat peut notamment être mis en lumière via un Squad Health Check mené par l’équipe. Je pense en particulier au thème Mission/Produit :

L’Agilité, c’est le bon sens !

Notre projet a justement remonté le soucis lors de nos rétrospectives qui font un Squad Health Check tous les quelques mois.

Pour essayer d’améliorer ce point, les actions nous avaient semblé évidentes :

  • Construire une roadmap, la tenir à jour et la communiquer à l’équipe lors de chaque revue d’itération
  • Donner de la visibilité à l’équipe sur le contenu des itérations à venir, nous pas sur la ou les deux prochaines itérations, mais sur au moins trois

Ces tentatives n’ont pas porté leurs fruits… Alors qu’elles étaient pourtant très contraignantes pour le PO !

La solution est beaucoup plus simple, mais surtout beaucoup plus holistique. Ne pas se focaliser sur les choses à faire mais réellement donner une vision. Se focaliser sur les objectifs macro que l’ont se donne, sur ce qui sera différent d’ici un an, deux ans… Et expliciter nos missions. Par contre, le détail du quoi et du quand, n’aidera nullement l’équipe à connaître sa mission et à s’en sentir investi.

Voilà le genre de chose que notre PO a fait et qui a réellement aidé en ce sens :

L’Agilité, c’est le bon sens !
L’Agilité, c’est le bon sens !

TK objectif au mur

TK Equipe sans visibilité sur le travail à venir/roadmap → vision produit, missions, objectifs macro, KPI

TK Estimations → ne pas se prendre la tête, se rappeler pourquoi on fait ça, et y’a des techniques TK extract de mon doc ??? YOOOOO

TK Gestion des bugs

TK XXX → DoD à bien respecter ! Vidéo de Jimmy Janlén ?

TK Être binaire dans l’exécution…

TK Tracking individuel plutôt que par équipe

TK ou Tracking par activité/rôle

TK Tracking à l’heure

TK JIRA

TK on manque de vision — cf. Squad Health Check

Top