Transition, évaluation et innovation

Le Club de lecture Agile Toulouse d'hier soir portait sur Agile Transition de Andrea Tomasini & Martin Kearns.

Le livre ne nous pas appris grand chose. Il est plutôt destiné à faire découvrir l'état d'esprit de l'Agilité à ceux qui ne connaissent pas. Il ne parle pas vraiment de transition.

Cependant, il nous a permis de bien discuter sur la transition, les cinq que nous étions pour ce sixième[1] rendez-vous du Club de lecture.

En particulier, nous avons débattu sur la façon de mener la transition (ce que n'aborde pas du tout le livre) et d'évaluer sa réussite.

L'approche la plus naturelle d'évaluation de l'Agilité consiste à examiner la façon dont les pratiques[2] ont été mises en place depuis le début de la transition.

Mais on sait que faire de l'agile ne suffit pas, qu'il faut être agile. On peut pour cela évaluer le respect des valeurs et principes.

Tout cela peut donner une bonne idée de la profondeur d'application de l'agilité sur l'équipe ou l'organisation, permettre de voir le chemin parcouru et identifier ce qui peut continuer à être amélioré.

On peut aussi se dire que l'Agilité n'est qu'un moyen. Ce qui compte, c'est le résultat.

Plutôt que de se dire "est-ce que j'applique bien la rétrospective, l'intégration continue…", ne faudrait-il pas mieux se demander "est-ce que la transition à l'Agilité a amélioré mes résultats ? Est-ce que c'est mieux qu'avant ? Est-ce que nous produisons plus de valeur ?"

Pas facile à évaluer. On peut faire des enquêtes d'opinion qui permettront de capter le ressenti. Mais c'est très subjectif.

Il serait plus significatif de s'appuyer sur des résultats concrets. Il y a des pistes pour cela. On en parlera au ScrumDay.

A ce sujet de l'angle d'attaque, j'ai lu ce matin un article de Internet Actu "innovation, innovation, innovation, innovation, innovation, innovation…".

Il apparaît que l'innovation se définit plus sur le processus suivi qu'avec le résultat obtenu. Comme l'Agilité finalement.

Notes

[1] Les 5 précédents étaient sur : Impact Mapping, le procrastination structurée, Kanban pour l'IT, Specification by example et Running Lean.

[2] Attention la mise en œuvre des pratiques dépend du contexte.