OUI.sncf une table ronde pour plus d’agilité

A l’invitation de Frédéric Arnal, j’ai participé mardi 21 novembre à une après-midi sur le sujet de l’agilité d’entreprise :
« Agilité d’entreprise : OKR, Safe, Less… OUI.sncf vous invite à vous confronter à ceux qui essayent (avec succès parfois !) de mettre ces méthodes en place »
L’événement se déroulait dans les superbes locaux éphémères de OUI.sncf : https://www.youtube.com/watch?v=e5xQ72QITn0

2017-11-21 14.37.48

 Les équipes de Voyages sncf ont commencé leur transformation pour plus d’agilité en 2012. Feature teams, automatisation, raccourcissement des cycles d’idéation, DevOps, les chantiers n’ont pas manqué, comme le raconte cette vidéo un peu speed (effet TGV ?) : Agilité & DévOps @ Voyages-sncf.com: épisode 3
Renommée « OUI.sncf », l’organisation réfléchit aujourd’hui au nouveau souffle à donner à sa transformation. Elle s’intéresse en particulier à l’agilité à l’échelle en questionnant les promesses des principales approches connues : SAFe, LeSS, « modèle Spotify ».
« Nos équipes sont agiles et nous en sommes fiers. Mais suffit-il d’avoir des équipes agiles pour être une entreprise agile ? Et qu’entend-on par entreprise agile ? Est-ce intéressant d’en devenir une ? Le jeu en vaut-il la chandelle ? »
Atelier, retours d’expériences, questions, échanges se sont succédés en 2h30 de temps sans, bien entendu, épuiser ce vaste sujet. Les échanges se sont noués autour des interventions des intervenants conviés par Frédéric Arnal, Responsable mission agilité et devops :
  • Cyrille Caillaud – Coach chez Oui.sncf – a accompagné l’émergence de la Tribu finalisation
  • Emmanuelle Lefort – Coach chez Wemanity – a participé chez Axa, à l’élaboration d’un framework maison inspiré de LeSS, des Tribus de spotify et de SAFe
  • Christophe Keromen – Coach chez Goood – a facilité des Program Increment (SAFe) chez Air France – KLM
  • Mohamed Dabo – a travaillé un an chez ING dans un environnement SAFe.

Trois confusions

Je ne prétends pas résumer ici l’ensemble des échanges, mais reprendre des points soulevés dans la discussion et qui me semblent importants à commenter . J’insisterai en particulier sur trois confusions qui me semblent représenter un piège lorsque l’on mène cette réflexion sur l’agilité à l’échelle :

  • Agilité à l’échelle = processus linéaire de changement depuis les individus jusqu’à l’organisation en passant par les équipes
  • Agilité à l’échelle = agilité d’entreprise
  • SAFe = agilité d’entreprise
et je terminerai en décrivant un élément fondamental qui me semble souvent sous-estimé dans les mises en œuvre de Scrum et SAFe. Lequel ? réponse un peu plus bas !

L’Agilité à l’échelle n’est pas un processus linéaire

L’agilité dans le développement logiciel a commencé dans les années 90 en s’appuyant sur l’intelligence collective au sein de petites équipes. Ken Schwaber le rappelle pour Scrum dans un article récent :
Jeff Sutherland and I based it on these pillars:
  1. Small, self-organizing, self-managing teams;
  2. Lean principles;
  3. Empiricism, using frequent inspection and adaptation to guide the work of the teams to the most successful outcome possible.

https://www.scrum.org/resources/blog/scrum-simple-just-use-it

eXtreme Programming adoptait la même position à son origine :
The first edition of Extreme Programming Explained is a classic. It won awards for its then-radical ideas for improving small-team development, such as having developers write automated tests for their own code and having the whole team plan weekly. https://www.amazon.fr/Extreme-Programming-Explained-Embrace-Change/dp/0321278658
Aujourd’hui, l’un des problèmes (la formulation est notable : l’un des problèmes) qui se pose aux entreprises, réside dans le fait que plusieurs équipes apparaissent nécessaires à la réalisation d’un produit. Coordination, gestion des dépendances, alignement, synchronisation deviennent des enjeux nouveaux et majeurs. Scrum, puisque c’est aujourd’hui le framework de référence pour aborder l’agilité d’équipe, n’a pas été conçu en fonction de ces enjeux. Mettre à l’échelle ne peut donc pas se résumer à empiler des équipes Scrum.
En systémique, on dirait que ces nouveaux problèmes sont des qualités émergentes des éléments en interactions. Interactions qui sont aussi transverses : avec les architectes, les équipes qualité, les équipes marketing…
A un niveau logique supérieur apparaissent des questions qui n’étaient pas présentes au niveau logique précédent. C’est ce que SAFe acte partiellement en intégrant le thème de l’agile Portfolio qui n’est pas une simple mise à l’échelle de pratiques d’équipes.

Agilité à l’échelle # agilité d’entreprise

“Lorsqu’un bazar, qui est un système de problèmes, est pris à part, 
il perd ses propriétés essentielles et c’est la même chose pour chacune de ses parties.
Le comportement d’un bazar dépend plus de la manière dont ses composants interagissent que de la manière dont ils se comportent indépendamment les uns des autres.  
Russell. L. Ackoff

Le manifeste agile intègre bien cette notion en insistant sur l’importance des individus et de leurs interactions, mais la situe dans une vision orientée équipe et non entreprise.

Les problèmes émergeant au niveau le plus haut de l’organisation font de l’agilité d’entreprise une question radicalement différente de celle de l’agilité d’une équipe IT. Enjeux de pouvoir, poids des structures, influence d’acteurs tiers (syndicats, RH, …), prolifération des signaux, échelle de temps différente, imposent d’intégrer de nouveaux concepts au-delà du référentiel agile traditionnel. En appeler au manifeste agile et aux équipes auto-organisées ne suffit plus…

Agilité d’entreprise # SAFe

SAFe s’est élaboré autour d’équipes Scrum. Les rôles, les événements de SAFe calquent les rôles, les événements de SCRUM. Par la suite, le framework a intégré Kanban, mais sa structure s’enracine dans Scrum.
Cependant Scrum et SAFe évoluent de manière très différentes.

Scrum vers l’épure

Le principe actif de Scrum, selon Ken Schwaber (cf. lien à la fin de l’article), consiste à mettre le système sous tension pour faire apparaitre les points de tension afin de résoudre collectivement par inspection et adaptation les problèmes rendus visibles :
  • au niveau de l’équipe (auto-organisation)
  • au niveau de l’organisation (rôle méconnu et souvent sous-rempli du Scrum Master)
« The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.” Scrum Guide 2013
Scrum ne cherche pas à donner d’indications sur la manière de gérer ces problèmes. Au contraire, au fil des années et des versions du Scrum Guide, il affiche résolument sa dimension de framework (un cadre vide de pratiques), détaché de tout lien avec l’IT pour s’appliquer dans un maximum de contexte.
The Scrum Guide is a body of knowledge that explicitly defines what Scrum is (and, by default, what it isn’t). The Scrum Guide doesn’t tell you how to use Scrum, how to implement Scrum, or how to build products with Scrum.
Ken Schwaber
Une recherche d’épure en phase avec cette citation Saint-Exupéry :
La perfection est atteinte non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.

SAFe vers l’embonpoint

A contrario, SAFe cherche à offrir une réponse à tous les problèmes se posant dans une recherche de plus d’agilité. Pour cela, il intègre et tente de digérer d’autres approches : Kanban, Lean UX, DevOps, LeanStartup…
D’où sa tendance à l’embonpoint. Cela peut sembler une quête illusoire, d’autant plus qu’il conserve en parallèle la dénomination de « framework ».
Piloté par un marketing agressif, SAFe s’est ainsi mué lors de la version 4.5 en « SAFe® for Lean Enterprises », entretenant par cette appellation l’ambiguïté qu’il apporterait une réponse totale aux entreprises en quête d’agilité. Cette évolution s’appuie sur l’argument que toutes les entreprises ayant une composante digitale, un framework conçu pour mettre à l’échelle l’aspect IT, renforcera l’agilité globale. C’est encore une fois négliger l’aspect systémique, adopter une vision linéaire du bas vers le haut et ignorer la complexité au niveau logique de l’entreprise.
Comme le mentionne sa promesse, Safe a été conçu pour optimiser le Delivery :
develop on cadence
Cela ne suffit pas pas pour structure une entreprise agile.

Agilité version Scrum et SAFe : et les impedimenta ?

Impedimenta : Charrois, bagages, etc., qui alourdissent la marche d’une armée. 
Ce qui entrave l’activité, le mouvement.
Larousse

Scrum se référait initialement à trois piliers : Transparence – Inspection – Adaptation.  Ces trois piliers constituent en fait l’armature de la fonction transformative de Scrum : offrir un cadre propice à l’organisation pour que ses différents composants puisse apprendre à apprendre et s’adapter en conséquence.
Le cadre proposé par Scrum joue bien ce rôle au niveau de l’équipe, grâce en particulier aux rétrospectives et à la revue de Sprint. Cependant, il échoue souvent à le porter au-delà de l’équipe. Dans la majorité des cas que j’observe, le Scrum Master ne joue qu’un rôle local, se restreignant à une conception limitante de chien de berger de l’équipe, là où Scrum le conçoit comme évangéliste vers les niveaux supérieurs de l’organisation (voir plus haut).
SAfe ne fait pas mieux car s’inspirant linéairement de Scrum. Il rajoute un cadre d’apprentissage au niveau Programme (regroupement d’équipes Scrum ou Kanban en Agile Release Trains) via des pratiques récurrentes et mises à l’échelle depuis Scrum : PI Planning, Inspect & Adapt…C’est généralement insuffisant pour traiter les problèmes non locaux aux trains.
SAFe n’inclue pas explicitement de dispositif de conduite du changement. La mise en place de SAFe doit se compléter par la mise en place d’un processus structuré de traitement des problèmes mis en lumière par l’adoption du framework, en particulier au travers des cadences des Program Increments. Sinon, le changement apportera juste plus de désordre, de stress et n’aboutira pas aux bénéfices escomptés.

Enterprise Transition Team

Ce dispositif de gestion des impedimenta au niveau de l’entreprise était évoqué sous le nom d’Enterprise Transition Team par plusieurs auteurs…dont Dean Leffingwell (créateur de SAFe) :

“The creation of an internal agile enterprise transition team drives the enterprise vision for the agile transition and also facilitates its implementation. Implemented properly, it re-orients the transition from a top-down mandate to a middle-out and bottom-up buy-in of the impending change.” Dan Leffingwell

“If the transition effort warrants it, establish an Enterprise Transition Community that provides energy, support, resources, guidance and occasional direction to the improvement communities who are doing the real work of driving the agile transition across the company.” Mike Cohn

This is a group of senior managers, often led by the agile champion, responsible for creating an environment where organizational impediments are handled.
Their job is to prioritize the impediments and then create teams to resolve the highest priority impediments. This is a very visible mechanism that is supported at high levels of the organization and reaffirms its commitment to a successful agile transition. Dan Lefebvre

Il est essentiel que toute démarche de transformation agile, à quelque niveau de l’entreprise que l’on s’adresse, comporte une composante, fortement soutenue par le sponsor, de résolution de problèmes. C’est ce processus, soutenu par une équipe avec de réelles pouvoirs de décision, qui soutiendra la capacité de l’organisation à apprendre à apprendre pour devenir plus agile.
[Ajout 2017-12-06] Jeff Sutherland défend l’importance de ce groupe dans un article récent dont je vous recommande la lecture : Executive Action Team

Agilité entreprise : au-delà de Scrum et SAFe…

Résumons mes propos en deux idées majeures :
1) Scrum et son descendant mutant SAFe souffrent irrémédiablement de leur genèse : une conception de l’agilité au niveau des équipes IT ancrées dans les problèmes des années 90. Penser l’agilité d’entreprise, requiert d’autres métaphores (j’y reviendrai dans un prochain article « Métaphores agiles ») et des approches plus holistiques et systémiques.
2) Arrêtons de parler d’agilité ou d’agile, sans préciser le contexte dans lequel on l’applique. L’agilité appliquée à l’entreprise, n’est pas l’évolution linéaire de l’agilité produit qui n’est pas la somme des agilités des équipes de développement.
Cela m’évoque cette citation de Camus :
« Mal nommer les choses, c’est ajouter au malheur du monde. »
En s’ouvrant sur son environnement, en invitant à l’échange, l’événement organisé par OUI.sncf s’inscrit bien dans une logique d’agilité d’entreprise. Même lorsque l’on y débat de SAFe qui, lui, relève de la synchronisation des équipes « Produit » plutôt que de l’agilité d’entreprise.

Pour aller plus loin…

Le sujet est très vaste et encore en pleine exploration. Voici quelques liens pour approfondir :

Des articles de blog

Un livre

ENTREPRISES VIVANTES, Ensemble, elles peuvent changer le monde, chapitre « les entreprises redynamisées » et article « l’agilité créatrice de valeur globale » par Damien Thouvenin

Des conférences en vidéo

  • Agilité, une histoire de flou (Agile Laval 2017)
    • Points abordés : Agile Scrum > Scaling Agile/Scrum > Transformation agile > Organisation agile. Attention au changement de dimension qui prend place entre « Scaling Agile/Scrum » et « Transformation agile »
  • Organisation agile ? Scrum is not enough (ScrumDay 2015)
    • Scrum, organisation agile ? Parle-t-on de la même chose ?
      Quelle stratégie adopter ?
  • LeanAgile, la transformation grand écran (FKUG 2016)  
    • Trouver son chemin dans la complexité et préserver son esprit agile ?

Ce qu’en disent les auteurs de Scrum [Ajout 2017-12-06]

Ken Schwaber

« An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization. »

« Scrum is Hard and Disruptive », texte de Ken Schwaber diffusé aux CST en 2006.
http://blogs.collab.net/agile/scrum-is-hard-and-disruptive  « If it’s not hard, you’re not doing Scrum […]. It disrupts the organization to be the best it can be, and it puts facts you’d prefer not to know right in your face. »

Jeff Sutherland

« SAFe is an IT framework that is useless in sales, marketing, and other areas. (…). SAFe also does not address organizational incremental change which is essential for business agility. »
« Scrum@Scale starts with management education and setting up an Executive Action Team which will lead the transformation ».

Restez à l’écoute si le sujet vous intéresse, nous proposerons début 2018 deux événements :

  • petit déjeuner « agilité à l’échelle, ça monte ou ça descend ? »
  • formation d’une journée « Ambitions d’une agilité à l’échelle et préparation avant le départ »

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s