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

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 :

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 !