A little history
Before the adoption of Holacracy in January 2016, we had already developed our own corporate governance system. It was based on the agile project management method Scrum, which we had been "breathing" since 2010. In other words, we had replicated the role structure and work organization ala Scrum throughout the company. This concerned the management of our customer projects, but also the management of our administration. I remember having the role of Scrum Master in the Lausanne office. My main responsibility was to maintain a "framework" in which the Lausanne Liipers could evolve without obstacles. I maintained a "User Stories" backlog related to the development of our office and we organized the processing of these stories in "sprints". I also remember that our admin team had a physical Scrum Board that continuously contained all current and upcoming tasks.
This agile governance system "Ă la Liip" had worked well for a few years. Until it became too restrictive. It was intended for project management, not for the company's internal processes. We had to constantly "twist" it so that it would continue to work. After 100 employees (including 6 managers, because we still had a hierarchical level at that time), we had to face the facts: this version of Scrum for Liip's governance was no longer efficient enough.
How could we then develop our company organisation in such a way as to sustainably absorb our growth (~20% per year in terms of employees)?
Two paths opened up for us:
- Increase the hierarchy: either enlarge the management team or insert intermediate management layers.
- Conduct research to find a radically different system.
Having always thought that highly hierarchical systems are dommed to failure, we took the path 2. without too much hesitation.
And we met Holacracy
This research has led us, among other things, to Frédéric Laloux's book "Reinventing Organizations", then to Holacracy. What we immediately liked was the fact that Holacracy conveys a system of very explicit rules, clearly described in a constitution, open source and scalable. After more than ten years of existence, Holacracy also had interesting references (including Zappos and its 1500 employees).
But does Holacracy impact the work I do with my clients?
When we coach other companies that want to adopt Holacracy as a step towards self-organization, a question often comes up:
Will I have to teach my customers how Holacracy works?
I reassure you right away, the answer is no (and fortunately ;-)). I believe that most of our customers have not been aware of the change. We have been managing all our projects since 2010 with Scrum. Holacracy is a tool that we use internally only, to operate our company.
How Scrum and Holacracy join forces
The use of two highly integrated working methods in a single company may seem dangerous. Looking back, I see that they marry very well. Our organisational chart shows that all the "production" teams have created the basic roles of Scrum: Scrum Master, Product Owner. The purpose and accountabilities of the SM and PO have been taken from the Scrum guide. The teams created also the additional roles they needed: Frontend/Backend/Fullstack developer, DevOps, UX Designer, etc. All these roles continue to work with Scrum on customer projects. They are also found in the Holacracy structure.
Comparison of all iterative processes of the two methods:
| Processes | Purpose | Who is invited | Scope |
|---|---|---|---|
| Holacracy | |||
| Governance | Addressing structural tensions | Members of the circle (Liipers) | Structure of the circle / company |
| Tactical (triage) | Addressing operational tensions | Members of the circle (Liipers) | Projects within the circle / company |
| Scrum | |||
| Backlog grooming | Take care of the product backlog, so that it is ready for the next sprints | The Scrum team (Liipers & client) | Client project |
| Sprint planning | Define what will be done in the upcoming sprint | The Scrum team (Liipers & client) | Client project |
| Sprint review | Demonstrate what has been done in the sprint that is ending | The Scrum team (Liipers & client) | Client project |
| Sprint retrospective | Inspect and improve the process / structure of the project | The Scrum team (Liipers & client) | Structure / functioning of the Scrum team |
Each of these processes has a specific purpose, needed for the smooth running of projects and for the continuous improvement of the structure. We note however that there could be an overlap between the Holacracy processes and the Scrum retrospective.
The self-organized teams (or circles) at Liip manage this relationship by keeping the retrospectives in their form. Not all the topics (or "tensions") that emerge from the retrospective are covered. Tensions regarding internal issues are reported at the next Holacracy tactical meeting of the team in question. This meeting is often scheduled shortly after the retrospective in question.
Keep doing retrospectives!
After 3 years of practice, I find it useful to maintain retrospectives "Ă la Scrum": through group interaction, they make it possible to bring to the surface subjects to be treated, which we would not necessarily have identified alone.
So my recommendation is this: if you go into Holacracy while practicing Scrum, keep doing retrospectives. And make sure you use Holacracy's solid processes to address the topics to be addressed!
What is your experience? What do you think? I look forward to reading your comment below!