since 2016, we use Holacracy to structure ou development and benefits are huge! We now have circles, roles and each salaries have the pleasure to work at Anybox.
My question is: How do you manage projects? Our job is to provide IT services. So, we have rôles from commercial to dev or hosting.First of all, a customer is firstly take in charge by the commercial role which has to define needs. Then, after the contract signature, it goes to the Technical circle, organized in several roles to deal with demands. After missions, it goes to billing role.
I'm asking if, instead of this functional orientation, we cannot create temporary circles to manage projets. for example for Project 1, I have circle 1 which contains a commercial role, an IT, a billing and a support role. This circle exists will project exists and is burst when project is done.
Do someone have pieces of information or feedback about this strategy?
Hey Sébastien - this could be a really good strategy, or a really bad one, or somewhere in between. The best way to find out? Try it, and see what tensions it creates! There's certainly nothing "wrong" with it from a Holacracy point of view. If it solves a tension to have a project circle, go ahead and propose one in your governance process. Good luck!
We do both. We are a shared IT service provider for multiple companies. Probably 99% of the projects are handled by people from various roles and circle collaborating in a shared Kanban or Scrum board. We don't do anything special with respect to governance.
On occasion, if the project is big enough by using enough dedicated resources for extended periods of time we will create a project Circle that only exists during the lifespan of the project.
From my experience, I wouldn't go for a circle per project... especially if you use some Scrum and/or Kanban. I.e. if you use Scrum, you may encode into governance Scrum practice, which is we did with several of our clients - kinda like a Scrum App. As [@mention:450819477778576386], I've seen some companies creating a circle at some point for a specific project, but was not designed upfront, there was a tension at some which trigger this circle creation.
Hi. When some partners are mostly dedicated to a specific project, the governance needed for this project is very specific and the cost of creating a new circle (core roles, meetings, etc.) is acceptable compared to the overall cost of the project, then yes, sometimes we do.
But this is brought through a tension of the specificity (current roles don't fit the specific needs).
I would definitively not advise it as a "rule". For me, a project belongs to the operations by essence.
I just published, "Holacracy® Basics: Understanding Projects and Project Teams" on Medium which doesn't directly answer the question, "What criteria do you use to determine if you need a project-oriented circle?" but it does delineate some core distinctions about projects which may help.
Great responses, always starting form a tension based approach to the problem I'd say that if the project has such a relevance/scope/duration that it might take advantage from encoding some preferred paths of communication/expectation then it might be worth creating a circle for it. If instead it has more requirements for continuous alignment over specialization then following other more "value-chain oriented" agile approaches (like Kanban) might help more than creating specific roles for it. If the two aspects cohexist than adopt both approaches at the same time (in the end isn't that what doing tacticals and governance is all about?). On projects that are repeatable by nature, encoding even some light communication patterns in roles together with some setup/Kpi management/support/post mortem expectations might help for quicker future re-editions .