Scrum rencontra Holacracy <3 Et elles vécurent heureuses…

  • Jonas Vonlanthen

Scrum et Holacracy sont des mĂ©thodes complĂ©mentaires. Elles peuvent Ă©lĂ©gamment se combiner. Petit retour d’expĂ©rience sur la façon dont cela se passe depuis plus de trois ans chez Liip.

Un peu d’histoire

Avant l’adoption d’Holacracy en janvier 2016, nous avions dĂ©jĂ  dĂ©veloppĂ© notre propre systĂšme de gouvernance d’entreprise. Celui-ci Ă©tait basĂ© sur la mĂ©thode de gestion de projets agile Scrum, que nous “respirions” depuis 2010 dĂ©jĂ . En d’autres termes, nous avions rĂ©pliquĂ© la structure de rĂŽles et l’organisation du travail Ă  la Scrum Ă  toute l’entreprise. Cela concernait la gestion de nos projets clients, mais aussi la gestion de notre administration. Je me rappelle avoir eu le rĂŽle de Scrum Master du bureau de Lausanne. Ma responsabilitĂ© principale Ă©tait de maintenir un “cadre” dans lequel les Liipers lausannois pouvaient Ă©voluer sans obstacle. Je maintenais un Backlog de “User Stories” liĂ©es au dĂ©veloppement de notre bureau et nous organisions le traitement de ces stories en “sprints”. Je me souviens Ă©galement que notre Ă©quipe d’administration tenait un Scrum Board physique qui contenait en continu toutes les tĂąches en cours et Ă  faire.

Ce systĂšme de gouvernance agile “à la Liip” a bien fonctionnĂ© pendant quelques annĂ©es. Jusqu’à ce qu’il devienne trop contraignant. Il Ă©tait destinĂ© Ă  la gestion de projets, pas aux processus opĂ©rationnels de l’entreprise . Nous devions constamment le “tordre” afin qu’il continue Ă  fonctionner. PassĂ© 100 collaborateurs (dont 6 managers, car nous avions toujours un niveau hiĂ©rarchique Ă  ce moment-lĂ ), nous avons dĂ» nous rendre Ă  l’évidence : cette version de Scrum pour la gouvernance de Liip n’était plus suffisamment efficiente.

Comment pouvions-nous alors faire Ă©voluer notre organisation d’entreprise de maniĂšre Ă  absorber durablement notre croissance (~20% par an en termes de collaborateurs) ?
Deux chemins s’ouvraient à nous :

  1. Augmenter la hiĂ©rarchie : soit agrandir l’équipe de direction, soit insĂ©rer des couches de gestion intermĂ©diaires.
  2. Effectuer des recherches afin de trouver un systÚme radicalement différent.

Ayant toujours pensĂ© que les systèmes fortement hiérarchisés sont voués à l’échec, nous avons pris le chemin numĂ©ro 2. sans trop hĂ©siter.

Et nous avons rencontré Holacracy

Ces recherches nous ont menĂ©es, entre autres, au livre “Reinventing Organizations” de FrĂ©dĂ©ric Laloux, puis Ă  Holacracy. Ce qui nous a tout de suite plu, c’est le fait que Holacracy vĂ©hicule un systĂšme de rĂšgles trĂšs explicites, dĂ©crites clairement dans une constitution, open source et Ă©volutive. AprĂšs plus de dix ans d’existence, Holacracy Ă©tait aussi au bĂ©nĂ©fice de rĂ©fĂ©rences intĂ©ressantes (dont Zappos et ses 1500 employĂ©s).

Mais est-ce que Holacracy impacte le travail que je fais avec mes clients?

Quand nous coachons d’autres entreprises désireuses d’adopter Holacracy dans leur organisation, une question revient souvent :

Est-ce que je vais devoir apprendre le fonctionnement d’Holacracy à mes clients?

Je vous rassure tout de suite, la rĂ©ponse est non (et heureusement ;-) ). Je crois d’ailleurs que la plupart de nos clients ne se sont pas rendus compte du changement. Nous gĂ©rons tous nos projets, depuis 2010, avec Scrum. Holacracy est un outil que nous utilisons en interne uniquement, pour opĂ©rer notre entreprise.

Comment Scrum et Holacracy s’unissent

L’utilisation de deux mĂ©thodes de travail fortement intĂ©grĂ©es dans une seule entreprise peut sembler dangereux. Avec du recul, je constate qu’elles se marient trĂšs bien. Notre organigramme montre que toutes les Ă©quipes de “production” ont crĂ©Ă© les rĂŽles de base de Scrum : Scrum Master (SM), Product Owner (PO). La raison d’ĂȘtre et les redevabilitĂ©s du SM et du PO ont Ă©tĂ© reprises du Scrum guide. Les Ă©quipes ont crĂ©Ă© les rĂŽles supplĂ©mentaires qui leur Ă©taient nĂ©cessaires : Frontend/Backend/Fullstack developer, DevOps, UX Designer, etc. Tous ces rĂŽles continuent Ă  fonctionner avec Scrum sur les projets clients. On les retrouve Ă©galement dans la structure Holacracy.

Comparaison de l’ensemble des processus itĂ©ratifs des deux mĂ©thodes :

Processus Raison d’ĂȘtre Qui est conviĂ© PĂ©rimĂštre
Holacracy
Gouvernance Adresser les tensions d’ordre structurel Membres du cercle (Liipers) Structure du cercle / de l’entreprise
Triage (tactical) Adresser les tensions d’ordre opĂ©rationnel Membres du cercle (Liipers) Projets internes au cercle / Ă  l’entreprise
Scrum
Raffinement du Backlog Prendre soin du backlog de produit, afin qu’il soit prĂȘt pour les prochains sprints L’équipe Scrum (Liipers & client) Projet client
Sprint planning DĂ©finir ce qui va ĂȘtre fait lors du sprint Ă  venir L’équipe Scrum (Liipers & client) Projet client
Sprint review DĂ©montrer ce qui a Ă©tĂ© fait lors du sprint qui se termine L’équipe Scrum (Liipers & client) Projet client
Sprint retrospective Inspecter et amĂ©liorer le processus / la structure du projet L’équipe Scrum (Liipers & client) Structure / fonctionnement de l’équipe Scrum

Chacun de ces processus a une raison d’ĂȘtre spĂ©cifique. Elle est nĂ©cessaire au bon dĂ©roulement des projets ou Ă  l’amĂ©lioration continue de la structure. Nous constatons, qu’il pourrait y avoir un overlap entre les processus Holacracy et la rĂ©trospective Scrum.

Les équipes autogérées (ou cercles) chez Liip gĂšrent cette relation en maintenant les rĂ©trospectives dans leur forme. Tous les sujets (ou “tensions”) qui Ă©mergent de la rĂ©trospective n’y sont pas tous traitĂ©s. Les tensions concernant des problĂ©matiques internes sont rapportĂ©es lors de la prochaine rĂ©union de triage Holacracy de l’équipe en question. Cette rĂ©union est souvent agendĂ©e peu aprĂšs la rĂ©trospective en question.

Continuez à faire des rétrospectives!

AprĂšs trois ans de pratique, je trouve qu’il reste utile de maintenir les rĂ©trospectives “à la Scrum” : Ă  travers une interaction de groupe, elles permettent de faire monter Ă  la surface des sujets Ă  traiter, que l’on n’aurait pas forcĂ©ment identifiĂ© seul.

Ma recommandation est donc la suivante : si vous vous lancez dans Holacracy tout en pratiquant Scrum, continuez Ă  faire des rĂ©trospectives. Et assurez vous d’utiliser les processus solides de Holacracy pour en adresser les sujets Ă  traiter!

Quelle est votre expérience ? Votre avis ? Je me réjouis de lire votre commentaire ci-dessous !


Qu’en pensez-vous?