Transformation agile agile : Les besoins et la valeur

Deuxième post d’une série sur la question : “la transformation agile de l’entreprise est-elle elle-même agile ?“

Je contribue à la transformation agile d’un grand compte industriel, au sein d’une équipe de 5 coaches. Cette série de post est un retour d’expérience visant à visiter mon retour d’expérience à l’aune des principes agiles. Un trait récurrent est de remettre en question l’applicabilité au pied de la lettre d’une analogie entre l’activité de transformation agile elle même et un projet gérable par Scrum (méthode agile la plus classique), tout en redécouvrant  les principes du manifeste agile.

La définition du produit : “Business people and developers must work together daily throughout the project“

Dans scrum, la définition du produit est assumée par le product owner, qui sait obtenir de ses interlocuteurs côté utilisateurs une compréhension du besoin et sait définir une vision. Ici en revanche la responsable au sein de l’entreprise de la transformation n’est pas forcément à même de se forger une vision. Elle a besoin de contributions de conseil que nous, prestataires consultants, fournissons. S’il fallait appliquer l’analogie, nous serions dans une situation où l’équipe est parfois plus compétente que le product owner sur la nature des actions à entreprendre. Du coup, que fait-on ? Lors d’atelier et d’échanges, la connaissance des rouages de l’entreprise va à la rencontre du savoir faire agile, et des propositions en sortent. En revanche, elle a la décision finale.

Le périmètre des sprints : “Welcome changing requirements, even late in development“

Nous nous astreignons à tenir des itérations de un mois, validées par des démos.Or, il apparaît que de nouveau besoins apparaissent souvent en cours d’itération, des opportunités de prêcher la bonne parole en adressant tel ou tel aspect non couvert jusque là. La décision est souvent d’accepter ces besoins.

Sil fallait appliquer l’analogie, nous serions en infraction avec le principe de protection du périmètre de l’itération, qui ne doit pas changer en cours.

Pour nous c’est différent : ok pour accepter ces nouvelles actions, après tout elles seront démontrées à la fin et illustrerons bien l’avancement, quitte à ne pas faire tout ce qui était prévu si ce n’est pas urgent.

Du coup nous passons à un mode un peu plus Kanban, en observant tout particulièrement la durée entre le début et la fin d’une action, et en limitant le nombre d’actions entamées à un moment donné.

Mesure de la valeur acquise : “Working software is the primary measure of progress.“

La démo, auprès d’un certain nombre d’acteurs côté DSI sanctionne l’effort, l’existence des livrables produits, pas vraiment le déploiement de l’agilité (comme “software” à installer dans les esprits).

Une vision qualitative nous vient de nos ateliers communautaires ou conférences de types “Open Space Technology”.

Pour être vraiment rigoureux, il faudra disposer de PKI (Indicateurs cléfs de performance) sur les projets agiles et sur les autres, et comparer l’apport de l’agilité. Nous ne mesurerions pas notre action de transformation isolément, son impact étant confondu avec celui de l’agilité.

Une autre approche, que nous allons mettre en oeuvre, est de systématiser des revues de l’agilité des projets, et d’en agréger les résultats pour voir leur évolution dans le temps par exemple. Cet outil nous permettra plus précisément de voir l’impact de notre action. En revanche, il s’agira plus d’une évaluation de l’adoption (rendre les projets agiles) que de la transformation (rendre l’entreprise agile dans son ensemble, y compris le business, l’infrastructure, …)