Parler d’Agilité à l’échelle en 30 minutes

Dans le cadre de ma mission actuelle, j’effectue un accompagnement autour de la mise en oeuvre d’une Agilité à l’échelle. Ce concept restant assez flou pour les personnes hors de la démarche, on m’a mandaté pour présenter l’organisation actuelle à un groupe susceptible de nous rejoindre dans un avenir proche. Pour cela, j’avais 30 minutes à structurer, questions-réponses comprises.

Je vous partage dans cet article la manière dont j’ai abordé le sujet !

Bonne lecture 🙂

Contexte de la demande

Dans le cadre de ma mission actuelle, on m’a demandé de faire une présentation autour de l’organisation d’Agilité à l’échelle actuelle à un groupe de personnes susceptibles de nous rejoindre.

Voici les informations à ma disposition ainsi que mes réflexions associées :

• Le groupe est d’environ 20 personnes
  • une activité ou un échange pourrait être possible avec ce nombre de personnes plutôt que de faire une présentation descendante

• Cette présentation est la 4 ème et dernière d’une série de présentations qui auront lieu pendant cette session
  • le format doit être suffisamment interactif pour garder le reste d’énergie du groupe
  • le scribing live me semble être une bonne manière de faire passer les idées tout en maintenant l’attention des participant(e)s

• La durée que l’on m’accorde est donc de 30 minutes et le format suggéré est de 10 minutes de présentation + 20 minutes d’échanges
  • soit je tente de rentrer dans ce cadre
  • soit je change la donne tout en respectant la timebox globale de 30 minutes

• Le niveau de connaissance de l’Agilité des participant(e)s n’est pas très clair
  • Quitte à ce que cela soit de la redîte pour certains, il me paraît inévitable de ne pas parler un peu d’Agilité pour aligner tout le monde sur les intentions et surtout le vocabulaire associé

• L’objectif est de rendre la présentation la plus concrète possible afin de pouvoir embarquer les personnes
  • Difficile pour moi d’imaginer parler « concrètement » de l’organisation actuelle en l’espace de 10 minutes. Tout dépend de ce que l’on met derrière ce terme vous me direz
  • Il me faut donc trouver un fil conducteur suffisamment clair pour expliquer aux personnes ce qui nous a amené à l’organisation telle qu’elle est aujourd’hui, avec ses qualités et ses défauts

Voyons finalement la manière dont j’ai décidé de structurer mon message.

Structuration du message

En prenant compte des différents éléments cités précédemment, j’ai finalement décidé de construire mon message de la manière suivante :

Partie 1 : Agile 

Mon intention dans cette partie est d’introduire l’Agilité sous un angle afin d’expliciter les intentions que l’on cherche à atteindre. Pour ne pas rester trop flou, je vais prendre le premier principe Agile et le décortiquer pour en extraire les messages principaux. Je m’en servirais par la suite pour introduire la seconde partie.

Cette première partie fera l’objet d’une slide car il y avait un peu trop de texte à mon goût dans le premier principe à réécrire ! 😛

Partie 2 : Scrum

Dans cette deuxième partie, mon intention est est d’expliquer le mode de fonctionnement d’une équipe qui cherche à atteindre les objectifs précisés juste avant. On abordera ici le vocabulaire lié au rôles Scrum et on introduit les événements qui rythment la vie des différentes équipes.

J’ai décidé de commencer à faire du scribing à partir de cette partie pour rendre le discours plus vivant et pour générer les échanges au fur et à mesure.

Partie 3 : Agilité à l’échelle

Dans cette dernière partie, mon intention sera d’expliquer le choix de l’organisation actuelle qui d’un bloc peut être un peu difficile à digérer. Je partirais donc des problématiques potentielles d’alignement et de synchronisation qui relèvent de plusieurs équipes Agile fonctionnant indépendamment l’une de l’autre. Cela me permettra d’introduire le terme de « Tribu » dans le même temps.

Cette partie sera également scribée afin de donner une image générale de l’organisation Agile mise en oeuvre actuellement et qui me permettra de projeter la slide officielle d’organisation par la suite qui devrait mapper avec mon discours ! 🙂

Je clôturerais avec quelques photos du PI Planning auquel nous avons participé il y a de cela quelques semaines pour donner une touche de concret avant de se quitter !

Voyons ce à quoi le discours a pu ressembler ! 😉

Description du discours

Partie 1 : Agile

Pour parler d’organisation Agile, il me paraît important de rappeler rapidement ce que l’on entend par Agile ou Agilité. Pour cela, je me suis permis de prendre le premier principe sous-jacent au Manifeste Agile qui s’intitule :

Satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Découpons le principe en plusieurs parties :

Satisfaire le client

On parle ici avant tout de satisfaction du besoin client (et non de la spécification). On accepte de plus qu’un besoin n’est pas toujours clair et surtout qu’il évolue dans le temps. Il est donc nécessaire de développer une organisation qui aura la capacité à s’adapter à l’imprévu et à ces changements continuels.

Livrer rapidement et régulièrement

On évoque ici une échelle de l’ordre de quelques semaines plutôt que quelques mois. En effet, on va chercher à itérer sur la solution afin de voir si l’on va bien dans la bonne direction. Dans le cas contraire, il nous sera plus facile de nous adapter et surtout l’impact de l’erreur sera moindre. On se laisse donc l’opportunité d’apprendre en continu.

En effet, c’est cette première livraison qui va nous permettre de voir si nos hypothèses de départ étaient les bonnes et si l’on va bien dans la bonne direction.

Des fonctionnalités à grande valeur ajoutée

En utilisant le terme « grande valeur ajoutée », on implique que d’autres en ont une moindre. En effet, si tout est urgent et important, cela n’a plus beaucoup de sens. On cherche alors à prioriser en continu et à ordonner l’ensemble des éléments constitutifs du besoin : chacun ne pouvant pas être au même niveau qu’un autre.

Le mode de fonctionnement que l’on cherche mise alors sur une plus grande autonomie des équipes (en terme de prise de décision notamment), une plus grande responsabilité et surtout plus d’interactions.

Partie 2 : Scrum

Après avoir parlé des intentions de l’Agilité, voyons voir comment cela se passe aujourd’hui au sein même d’une équipe.

Chaque équipe comporte aujourd’hui 3 rôles distincts permettant de répondre aux 3 objectifs évoqués précédemment :

• Product Owner : en charge du partage d’une vision claire et de la priorisation continue des éléments constitutifs du besoin
• Scrum Master : en charge de la livraison efficace et régulière d’éléments de valeur
• Équipe de Réalisation : en charge de la solution permettant de répondre au mieux au besoin exprimé et par conséquent de la satisfaction client

C’est ce que l’on appelle aujourd’hui une « Squad ».

La vie de cette Squad s’articule autour de 4 grands événements, qui vont se répéter par boites de temps successives :

• Un événement de Planning : pendant lequel l’équipe dans sa globalité va se mettre d’accord sur ce qu’elle se sent capable de réaliser pendant la période de temps donnée
• Un Daily : pendant lequel l’équipe va décider ensemble sur ce qu’elle compte réaliser dans la journée – c’est un planning à l’échelle de la journée si l’on veut
• Une Revue : où l’on va analyser avec les parties prenantes ce que la Squad a réussit à produire pour définir ce qui serait le plus pertinent de faire par la suite
• Une Rétrospective : permettant à la Squad d’améliorer son mode de fonctionnement

Maintenant, supposons plusieurs Squads fonctionnant de manière indépendante alors qu’elles contribuent au même domaine fonctionnel. L’une pourrait avoir un rythme de 2 semaines, l’autre de 3 semaines etc…

Il se pourrait alors que des problématiques d’alignement fonctionnel et de synchronisation apparaissent.

C’est de là que l’on va parler d’Agilité à l’échelle.

Partie 3 : Agilité à l’échelle

Pour répondre aux problématiques d’alignement et de synchronisation, on va tout simplement :

• Alignement : avoir une cohérence fonctionnelle et un arbitrage global
• Synchronisation : faire partir et arriver les Squads en même temps

La décision a été d’opter pour des boites de temps de 2 semaines.

On passe alors les rôles à l’échelle :

• Le Product Manager : un peu comme un coordinateur des Product Owners, sa mission est de garantir la cohérence fonctionnelle de l’ensemble.
• Le Release Train Engineer : un peu comme un coordinateur des Scrum Masters, sa mission est de garantir la cohérence organisationnelle et l’efficacité de l’ensemble.
• La Design Authority : à chaque niveau supplémentaire, il est nécessaire de rajouter une couche de cohérence structurelle globale. C’est le rôle que va prendre ce comité pour garantir la cohérence technique de l’ensemble.

A ce triptyque, on rajoute une Squad que l’on appelle la System Team, agissant en soutien des autres Squads, pour garantir la capacité à livrer de l’ensemble. Elle adresse les sujets liés à l’infrastructure, à la livraison continue et au déploiement continu notamment.

Pour parler de l’ensemble des Squads ensemble avec ces nouveaux rôles à l’échelle, on parle de Tribu.

Maintenant, regardons les événements évoqués précédemment et passons les à l’échelle :

• Le Planning devient le PI (Program Increment) Planning : un événement de Planning pour l’ensemble des membres de la Tribu
• Le Daily devient un Weekly pour s’adapter à l’échelle de temps de la Tribu et prendra 2 formes distinctes :
  • Un Scrum of Scrum regroupant l’ensemble des Scrum Masters
  • Un PO Sync regroupant l’ensemble des Product Owners
•  La Revue devient une revue de l’incrément produit par la Tribu après 6 itérations de 2 semaines
•  La Rétrospective de Squad devient une Rétrospective au niveau de la Tribu

Voici l’organisation à laquelle vous allez pouvoir contribuer si vous venez à nous rejoindre ! 🙂

Conclusion

La présentation semble avoir été bien appréciée et est bien rentrée dans le timing de 30 minutes questions comprises. J’ai pour ma part eu beaucoup de plaisir à raconter l’histoire de cette manière et à la scriber en live même si c’était bien la première fois que je le faisais. Mon style reste néanmoins très simpliste, j’ai encore un long chemin de progression devant moi !

Je suis de plus en plus convaincu du pouvoir du visuel dans les présentations et je vous encourage à y aller même si cela peut apparaître un peu disruptif dans les organisations dans lesquels vous êtes : croyez-moi, c’est un faux problème ! 🙂

J’espère en tout cas que cet article pourra vous inspirer pour aborder le sujet de l’Agilité à l’échelle, si courant actuellement !

Vos feedbacks et suggestions sont les bienvenus 🙂