Le Manifeste Agile existe depuis 2001, et les approches agiles existaient depuis déjà bien avant ça. Alors, quelle est cette chose qui s’appelle Modern Agile ? Le manifeste est-il dépassé et doit-il être remplacé ? Ce sont de bonnes questions, mais commençons d’abord par regarder qu’est-ce que Modern Agile.

Modern Agile est constitué de quatre principes directeurs - Rendre les gens fantastiques, Faire de la sécurité un pré-requis, Expérimenter et apprendre rapidement, Apporter de la valeur en continu. Et c’est tout. Quatre principes qui, lorsqu’ils sont suivis, peuvent vous apporter un gain en terme de rapidité de mise à disposition de ce qui est voulu par vos clients tout en prenant du plaisir au travail ! Regardons donc en détails chacun d’entre eux.

Faire de la sécurité un pré-requis

Pour moi tout commence par la sécurité. Une fois, j’étais chez un client pour “corriger” l’agilité dans certaines équipes. L’encadrement avait dans l’idée que ma mission serait de redresser certaines choses, d’écrire quelques bonnes pratiques et de faire en sorte que tout le monde les suivent.

Lorsque j’ai discuté avec les équipes, elles m’ont raconté une toute autre histoire. Elles essayaient d’être agiles depuis un an, mais l’encadrement les avaient stoppées dans leur élan en changeant constamment les priorités, en faisant courir les équipes dans tous les sens et en leur disant quoi faire à chaque instant. Mais les choses en cours qui étaient déjà en cours devaient également être terminées. Une phrase régulièrement entendue était la suivante “Faites-moi juste ce petit truc, cela ne devrait pas prendre beaucoup de temps”. En conséquence, les équipes ne se sentaient pas en sécurité pour mettre en place une nouvelle manière de travailler parce que l’encadrement ne respectait jamais le processus, même s’il disait qu’il le ferait.

La première chose à faire dans ma liste de courses devint alors de régler ce problème avec l’encadrement et de les faire s’engager sur quelques idées fondamentales et de leur montrer qu’il pouvait faire confiance aux équipes pour accomplir des choses. Si j’avais commencé avec n’importe quel autre principe, nous aurions été incapables de faire le moindre progrès à cause de la crainte que l’encadrement ne change pas sa manière de travailler.

La sécurité vient sous différentes formes. Dans la précédente anecdote, il s’agissait de sécurité psychologique. Et il y a aussi la sécurité physique, la sécurité des données de l’utilisateur, l’argent, etc. La liste est longue, et l’ensemble des éléments la composant sont importants.

Expérimenter et apprendre rapidement

Il y a environ 10 ans, je travaillais en tant que directeur technique dans une start-up. L’idée du produit que nous avions était de laisser les patients enregistrer leur état de santé quotidien sur leur téléphone portable (c’était l’époque d’avant les iPhone, je tiens à vous le dire). Avez-vous bien pris votre médicament ? Avez-vous bien fait vos exercices ? Quel est le niveau de douleur que vous ressentez ? etc, étaient le type de questions qui pouvait être demandé au patient et le patient alors enregistrait ce qu’il avait fait et ce qu’il ressentait. La théorie derrière cela étant le syndrome de la salle d’attente. Le syndrome de la salle d’attente est le terme utilisé occasionnellement en recherche clinique pour décrire l’action du patient de remplir des dossiers et des questionnaires juste avant une visite médicale dans une salle d’attente avant le rendez-vous avec le médecin. Est-il facile de se rappeler de ce qu’il en est de son état de santé il y a 6 mois ? 1 mois ? 1 semaine ? Un jour ?

Donc à quelle fréquence vous arrêtez-vous, réfléchissez-vous et apprenez-vous ? Faites-vous des post-mortem de vos projets (Trouvez-vous cela facile de vous souvenir des choses qui se sont passées il y a plusieurs mois) ? Des rétrospectives en fin de sprint (Trouvez-vous facile de vous souvenir de ce qu’il s’est passé il y a plusieurs semaines) ?

Je suis un grand amateur de l’amélioration continue, et j’attache une grande importance à ce que le système de production Toyota (connu également sous le nom de Lean) dit à ce propos, cela signifie que dès que quelque chose va mal, vous devez vous en occupez ici et maintenant. Vous n’attendez pas la fin du sprint. Et si vous trouvez quelque chose qui fonctionne bien, reconnaissez-le donc et capitalisez-dessus.

L’expérience est la décision que vous prenez sur la base de ce que vous faites. Mettez donc une date butoir à une expérience, et assurez-vous de savoir comment l’évaluer à cette date butoir. Ne soyez pas effrayé d’avoir à déclarer le fruit d’une expérience comme étant un échec mais célébrez donc ce que vous avez appris.

Apporter de la valeur en continu

De quel type de valeur parlons-nous ? Dans le cas présent, l’interprétation qui s’impose est celle de la valeur métier, comme par exemple, améliorer le produit afin que les utilisateurs en tirent plus de valeur. Et si nous voulons livrer ce type de valeur en continu, ben on fonce, on implémente la livraison continue et ça y est c’est terminé, n’est-ce pas ? Eh bien d’une certaine manière c’est vrai, mais ce n’est seulement qu’une petite partie et c’est plutôt plus facile à dire qu’à faire.

Nous pouvons envisager ce principe sous d’autres angles. Comment pouvons-nous en tant qu’équipes apporter de la valeur au reste de l’organisation ? Comment est-ce que je peux en tant qu’individu apporter de la valeur à mon équipe ? Comment puis-je faire de mon mieux pour apporter de la valeur à mon équipe lors du stand-up ?

Leanpub est un parfait exemple de comment vous pouvez apporter de la valeur en continu lors de l’écriture d’un livre. En tant qu’auteur, vous pouvez choisir quand bon vous semble de publier afin de savoir si le livre a une quelconque valeur aux yeux de votre lectorat. Vous pouvez, bien sûr, publier plusieurs versions, choisir le prix, etc.

Un autre exemple, pourrait être que chez Crisp nous faisons des conférences de type forum ouvert 1, et que l’une des règles du forum ouvert est que si lors d’une session, vous ne contribuez pas ou si vous n’apprenez rien, vous utilisez vos deux deux pieds (et allez à une autre session). J’essaye d’appliquer cette règle dans les réunions auxquelles je vais. Si je contribue pas ou si je n’apprends rien, j’essaye de partir. C’est une manière d’apporter de la valeur aux autres en réunion.

Et cela ne concerne pas uniquement du produit final. Essayez d’envisager ce principe de manière plus large.

Rendre les gens fantastiques

Lors d’une mission, je travaillais au sein d’une équipe construisant un système qui devaient permettre à des enseignants de créer leurs sujets d’examen que leurs étudiants pourraient ensuite passer sur leurs ordinateurs. Cela devait permettre aux enseignants de gagner beaucoup de temps, parce que entre autres choses ils n’auraient pas à imprimer des centaines de feuilles d’examen sur papier et à les apporter en classe. Le système pouvait aussi auto-corriger certains types de questions, permettant là aussi de gagner beaucoup de temps pour les enseignants. Nous avons rendu les enseignants encore plus fantastique en leur permettant de gagner du temps (et du papier).

Rendre les gens fantastiques est aussi quelque chose qui peut être vue de différentes façons. Une exemple possible pourrait être comment un Scrum Master coachant une équipe peut aider l’équipe à prendre conscience à être plus fantastique. D’une manière plus globale, ce principe pourrait être interprété comme en utilisant notre produit nos utilisateurs sont devenus plus fantastiques.

En aparté, le principe “rendre les gens fantastiques” a créé un petit émoi sur Twitter il y a quelques mois (pour plus d’informations voir notamment le tweet suivant https://twitter.com/johannarothman/status/983347074430328833). Il est facile d’interpréter ce principe de la manière suivante “quelqu’un devrait rendre certaines personnes fantastiques” dans le sens de forcer les gens à devenir quelque chose qu’ils veulent ou non.

Ce n’est pas bien sûr ni l’intention ni la signification de ce principe; Le verbe “rendre” devrait être interprété comme “créer”. Voici le lien vers l’explication de Joshua 2 au sujet de ce principe https://www.linkedin.com/pulse/anatomy-modern-agiles-first-principle-joshua-kerievsky/

Est-ce que Modern Agile remplace le Manifeste Agile ?

J’ai donné beaucoup de formations sur l’agile à des personnes novices sur le sujet, et je fais faire des exercices pratiques autour du Manifeste Agile et de Modern Agile. Assez régulièrement, la simplicité des quatre principes de Modern Agile résonne davantage aux oreilles des personnes débutantes.

À mon avis, le Manifeste Agile reste valable. Un des problèmes aujourd’hui avec le manifeste est qu’il se focalise sur le développement logiciel. Aujourd’hui, les approches agiles se sont répandues dans différents domaines métiers. Cela arrive souvent lors de mes formations (d’avoir des personnes de différents domaines métiers - NdT), cela amène quelques fois les personnes à aboutir à la (mauvaise) conclusion qu’agile fonctionne seulement dans des produits orientés logiciels. Modern Agile n’a pas ce problème. Donc oui d’une certaine manière, Modern Agile est une modernisation du manifeste, mais cela ne signifie pas pour autant que le manifeste soit mort.


Auteur : Mikael Brodd
Source : Modern Agile
Date de parution originale : 27 juin 2018


Traducteur : Nicolas Mereaux
Date de traduction : 19/09/2018


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. Pour plus d’informations sur le forum ouvert, vous pouvez consulter cet article sur wikipedia 

  2. NdT, il s’agit de Joshua Kerievsky, créateur de l’approche Modern Agile