Holacracy is said to be improving on Scrum, Agile and Getting Things Done. It’s supposed to make any team run better by continuously evolving the roles in the team to better fit the work. Is it really better than Kanban or Scrum? Let’s find out.
Holacracy means that the whole of the team is in charge, not just the manager. In essence Holacracy is a process to organize self-direction and self-organisation in teams. Self-organizing knowledge workers are proven time and again to be more productive than managed ones. I researched Holocracy with the aim to discover new insights for building self-organizing teams.
Getting Teams Done
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 factional story of a team that makes the transition 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 I consulted the official Holacracy website.
How Holacracy works
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 alternating. 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.
In Holacracy a role is defined as a set of mandates and responsibilities. They are 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 a 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.
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 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 super circle in order to resolve tensions that originate from there
- Secretary: Record keeping, mostly with regard to 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 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 tensions. Sensing and discussing tenstions 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. Furthermore all obstacles are discussed, person by person. I’m not sure this brings enough focus in the team. It feels like a bit of waste.
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 in every detail here. If you want to see all rules there is a constitution that defines all 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
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 fulfil 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.
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: Scrum Master, Product Owner, Front end developer, Tester, 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 their bit of 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 the work, it does not explicitly say a difference of opinion is 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 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, innovating fast, Holacracy might not be the right choice for you. It’s 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 as 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 are more like a snowball. They gain momentum all the time, yet remain open enough to change course when needed.
|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|