Holacracy claims to improve Agile and time management. It’s supposed to make any team run better by continuously evolving the roles in the team to fit the work better. Is it really better than Agile approaches like Kanban or Scrum? Here’s my opinion.
Holacracy means that the whole of the team is in charge, not just the manager. In essence, Holacracy is a process of organizing self-direction and self-organization in teams. Self-organizing knowledge workers are proven time and again to be more productive than managed ones. I researched Holocracy to discover new insights for building self-organizing teams.
Getting Teams Done, a Holacry guide
I based my research mostly on ‘Getting Teams Done,’ a practical guide for implementing Holacracy. Getting Teams Done is written in the style of ‘The Goal’ and ‘The Phoenix Project.’ There’s a fictional story of a team that transitions from a hierarchical way of working to a Holacracy. This makes the book easy to read and digest. Apart from the book, I did some interviews, read a couple of experiences with Holacracy, and consulted the official Holacracy website.
How Holacracy works, compared to Agile
In Holacracy, a team is called a circle. The Holacracy process has two mandatory meetings for every circle: the governance meeting and the tactical meeting. These meetings are supposed to happen biweekly and alternately. The difference with Scrum is that the meetings have a very strict process. In Scrum, you’re free to optimize the process, and only the input (what to inspect) and the output (what to adapt) of the meetings are defined. This gives Scrum much more room for continuous improvement.
Holacracy roles
In Holacracy, a role is defined as a set of mandates and responsibilities. They have the power and the responsibility to get things done. It’s much like a function description except that it’s not everything a person does in her position: it’s just one of her roles. Unlike a function, it also explicitly evolves. So as a person, you might have multiple roles. Or you might share a role with other people. The role definition is short and clear to everyone involved.
Example role definition: Content marketeer
Purpose
- Planning and publishing content in order to make the brand visible to clients and future clients.
Domains (mandate)
- Content plan
- Publishing content to the blog and to social media
- Brief third parties for content
- Spend €10.000 per quarter for boosting posts
Accountabilities
- Growing the Audience
- Generating quality leads from marketing content
Note that the role describes work that never finishes. It contains verbs that are infinitives. I think this role definition lacks empiricism. It would be better if there were a measure of success. How do you know if you’re doing your work well? What are the ambitious goals you could achieve within your role that would really impress the rest of the team?
Holacracy has 4 predefined roles:
- Lead link: Defines priorities & strategies. Assigns roles.
- Representative link: Represents team in a super circle to resolve tensions that originate from there
- Secretary: Recordkeeping, mainly concerning roles
- Facilitator: Leads the two Holacracy meetings and makes sure the rules are enacted
‘Tensions’ and the Governance Meeting
Governance in Holacracy is based on an interesting concept: the distinction between roles and people. This is also a basic concept in deep democracy. The nice thing about separating roles from people is that you can discuss the performance of a role without becoming personal and emotional.
When the roles in a circle don’t fit the work or the circle members, they feel tension. Sensing and discussing tensions is very important in Holacracy. Tensions make up most of the agenda of the governance meeting. The goal of that meeting is to resolve those tensions by tweaking the roles or policies for the circle. The process is based on consent: the circle is not looking for perfection. It’s looking for a good-enough solution that doesn’t raise any valid concerns.
‘Obstacles’ and the Tactical Meeting
The tactical meeting is much like a Kanban daily standup: it’s about the work to be done. This meeting misses many of the powerful aspects of Scrum and Kanban, however. There is no motivation to focus and reduce work in progress. Neither is there a drive to finish work so new work can be started. It’s just a weekly discussion of any obstacles that might have come up. In my experience, waiting for a week to discuss obstacles with the team is way too slow.
In Holacracy, the individual roles are supposed to track “projects”. “Projects” are defined as having specific outcomes that require multiple sequential actions to achieve and that would be useful to work towards, at least in the absence of competing priorities. They are written with a past participle. E.g., “Analytics system implemented”
I think the downside of this is that projects tend to become individual people’s responsibilities. This hampers flow and team commitment.
Full Holacracy ruleset
I won’t go into every detail here. If you want to see all the rules, there is a constitution that defines all the rules of Holacracy. Team managers are even required to sign it and literally “cede their authority into the constitution’s processes and endow the due results therefrom with the weight and authority otherwise carried by the ratifier(s), as further detailed in section 5.1 thereof.“
Interesting Holacracy elements to make teams more Agile
I’m not tempted to try and implement Holacracy as a whole. The process is just too restrictive. I’m much more at ease with a framework approach like Scrum. Yet there are some elements that I will adopt.
1. People are not their role. They fulfill their roles.
I will make a point of separating roles from people in my Scrum coaching practice. This will make switching roles easier. It will also improve the quality of the retrospectives.
Don’t say: “She IS the Scrum Master,” but say “She’s fulfilling the Scrum Master role this sprint.”
2. Roles should be continuously clarified and evolved.
I will add a retrospective technique to my collection where we pay special attention to roles. Dependability is an important factor in team performance. Clear roles will improve team dependability a lot. I will develop a retrospective technique where every role is a ‘bucket,’ and the whole team can reflect on them. In a typical web team, this could be a Scrum Master, Product Owner, Front end developer, Tester, or UX designer,… In my experience, the responsibilities of each role always depend on the skills of every team member and the challenge at hand. Clarifying and evolving them is bound to increase commitment and productivity. Maybe the roles can even have some wall space in the Scrum room.
3. Tensions fuel continuous improvement
Tensions are usually regarded as a bad thing. While Scrum celebrates diversity and makes a point of involving experts from multiple disciplines in work, it does not explicitly say a difference of opinion is a good thing. I’ve seen teams devolve into single-minded steam engines. That hampers agility because more eyes see more risks and opportunities.
By celebrating tensions and crediting them for the continuous improvement they fuel, conflict becomes less of an emotional thing. Where people work together, there will always be conflict and tension. The trick is to harness it for productivity.
Conclusion: Holacracy vs. Scrum
Holacrcy is more related to Sociocracy than to Agile and Scrum. However, as the method is positioned as “a concrete framework for encoding autonomy, agility, and purpose-alignment into your organization’s DNA,” I will compare it to Scrum and Kanban.
If your team is moving fast, changing fast, and innovating fast, Holacracy might not be the right choice for you. Its improvement cycle is too slow. The focus on tension at the individual level is no guarantee to produce visionary organizational value. Kanban brings more focus with a simpler method at the expense of defining clear roles.
I wouldn’t call Holacracy agile because it’s not empirical like Kanban and Scrum. There is little motivation to move the needle at a time. It seems that Holacracy is more like a gearbox and optimizes every individual gear to mesh well with the others. Scrum and Kanban work more like a snowball. They gain momentum all the time yet remain open enough to change course when needed.
| Holacracy | Kanban | Scrum |
|---|---|---|
| great for operational teams | great for operational teams | great for innovative teams |
| biweekly improvement rhythm | daily improvement rhythm | daily and biweekly improvement |
| built-in scaling model | focussed on the team level | focussed on the product level |
| predefined roles (Lead link, secretary, rep link) | no roles | predefined roles (Scrum master, product owner, development team) |
| strict process | strict principles, flexible process | framework adapted to needs |
| focus on tension | focus on flow | focus on value |
Share this article about Holacracy and Agile to help other people!
If this article is useful, remember to share it with others who might benefit. You can point them to my Facebook page about teamwork. You can also point them to LinkedIn.
