- Read the 2nd post in this series Holacracy II: Roles and Responsibilities in Development
- you might also be interested in our founder Ruben Timmerman’s more recent post 8 challenges to overcome when adopting Holacracy.
Our development team is implementing Holacracy. It is a learning process for us and I plan on writing about this process as I attend the trainings and while we stumble about the implementation. This first post is about our basic understanding (and initial skepticism) of Holacracy, and the types of meetings needed to implement it properly.
This week, our development team at Springest started out with Holacracy, following our Marketing, Product and Sales teams. Although our other teams were quite enthousiastic about their implementation of Holacracy, we have been putting it off for development for a while, because we were a little sceptic about it. We have been practicing a basic implementation of Scrum, mixed with Kanban, for quite some time now and as far as we knew Holacracy was based on what dev teams have been practicing for years with principles like Scrum, Lean Startup, Kanban, and what authors like ?? in Rework, ??, etc. have been advocating for years now in practicing development. “We own that shit” is what I thought. Then I heard some more. You could call Holacracy an implementation of GTD (Getting Things Done, the productivity method by David Allen), but for your company instead of peronsally. GTD? Wut? We don’t need that stuff! We have Kanban boards (ours is called Kanbam ;)), tickets, peer tested pull requests, super short dev cycles, near-continuous integration, stand-ups, and retrospective meetings. We already know what to do, and when to do it. But.. there was stuff to improve. We had more and more discussions creeping into our stand-ups stretching them from 10 minutes to 20 minutes, and our two weekly retrospectives were growing into tiring sitdowns with devs addressing dozens of topics in all areas of our work: velocity TDD, CI, deadlines that we miss, data that is missing from our Kanbam board, estimates that are off, bugs that pop up and nobody feels accountable for. We were clearly on the wrong path, meetingwise. OK, that might sound a bit depressing, but we really love to focus on what we can improve in our process and we’re not easily satisfied. And then, this week, Diederik from Realize came to tell us the basics of Holacracy meetings.
##3 types of meetings
As I understand it now, there are 4 types of meetings, each addressing a different level of the process. In decreasing level of abstraction, and increasing frequency, these are:
- Strategy (most meta, least frequent)
- Standups (most concrete, most frequent) Strategy meetings are management meetings, sort of, by the lead-links of each “Circle” (teams are called circles, but more on that later) and happen only once every two months or so, so I’ll skip those until we’ve actually done one. I will just cover the basic knowledge that I have on Governance and Tactics meetings.
Governance sounds like management, sounds like overhead. Can we kill it? Hardly. Holacracy seems to focus on accountability and ownership of responsibilities (tasks). Governance meetings are meant for determining what these tasks and responsibilities are and how they can be divided into “roles”. The team provides these roles and they are assigned to team members by the lead link. Everybody will have a bunch of roles, but probably no more than ten. The people in the Circle (team) determine what these roles are and divide them amongst the people in the Circle. I do not have any real examples of roles in our team yet, but in the next couple of days we will have the first roles determined and divided. I am curious about the roles that will come up. Could be that we have a lot of people with just the “developer” role and a few more roles for our PM’s and me, but I’m beginning to think we will come up with some more. In a governance meeting are no “actions” discussed, just the process and the people running it. This in contrast to Tactical meetings.
Tactical meetings are all about metrics, projects, updates and “next actions” and are the most frequent meetings that we will have. I am guessing (as we have not had any tactical meetings yet) that we will discuss implementation stuff. Not like tickets, a little more meta probably, but the key objective is everybody leaving the table knowing what to do next.
As far as I know these have the same structure as our scrum standups: what have you done yesterday? What are you doing today and do you see any problems that need to be addressed now in order to get it done?
##Could this work for us?
Yeah, I think so! Retrospectives have not been very efficient lately. There is too much stuff to address and the topics are in too many levels of our work to result in concrete, and actionable tasks. That’s what people generally need, so that they can feel accountable for it. This results in strategy issues bubbling up in our standups and people not knowing what to do. Taking these levels apart in seperate meetings could help us to have more actionable results and a higher level of ownership and accountability. I also hope some implicit tasks and roles will bubble up and create more clarity in who does what, and why. I am excited to see where this will lead us, and I’m very eager to hear your feedback and experience with Holacracy and GTD in a development context!
Find out more about Springest.
Want to work at the biggest learning source in the world?