Holacracy Community of Practice Archive, 2015-2019 Community Holacracy Web Site

Project / product retrospective meeting

I was going to propose to our circle to have retrospective meeting after a product is released, the participant would be several people energizing product manager role, software engineer role, tester role, and data scientist role. 

However, when I think about it, the objective of the meeting is to discuss about how the project / product milestone went, is there anything that can be improved in our process? this feels very similar to what we would do in governance meeting. A product development doesn't involve all team member so I don't think that governance is the right place to retrospect.

Is there anyone who uses retrospective along side holacracy? how does it work then? do you stop at generating tension, and take it to governance? Some of the retrospective meeting process that I know would include brainstorming of an issue, asking why several times, and this is not align with holacracy way, right?

2 Replies
Eliana
10/28/2017

Hi Fajar! I have been thinking about this topic recently, as the tactical structure doesn‘t leave any spaces for Mindstorming, Experience Transfer or Retrospective corrections but we really need to adjust our processes and also the way we are working together since the implementation. I don’t think that a Governance is the right place to do a retrospective, anyway I was thinking about a Retrospective Workshop to be followed by a  Governance, so that we can discuss and use the collective intelligence in a creative way first and then just implement the needed adjustments in a holocratic way while Governance Meeting. I think both kind of methods are complementary, as we still need to push collaboration within our team and we need the commitment of every single one of us to build up the new strategy. Once we find a common vision, we will be able to go back stronger into the holocratic governance process, I guess. 

Chris Cowan
10/28/2017

Fajar, 

We use retrospectives in H1.Their purpose is unique and doesn't fit the Tactical or Governance meeting structure as you and Eliana stated. 

I would recommend having "a facilitator" with a specific process in mind, which you probably already have. 

Regardless, one important step (or expectation) would be to emphasize that people should be taking notes on tensions to process as a result of the retrospective. Those tensions then could be governance or tactical. This ensures that the retrospective stays focused on its purpose, which is surfacing data (i.e. generating tensions).

Though again, I've seen retrospectives combined with brainstorming, so it can work, just pointing out that processing tensions still needs to be grounded by the individuals who feel them. So, we'll requests projects and next actions of each other, take notes ourselves on tensions we feel, and then basically it's on each person to process their tensions accordingly. This should be all that's needed unless the governance is off somehow. And if the governance does need to be updated...well, of course you do that in a governance meeting. 

My point is, even if (and maybe especially if) you're brainstorming things like a group process, watch out for setting implicit expectations. In my experience, the retrospective surfaces interesting data which informs how I'll decide to energize my roles, meaning I may not see a need to change any governance (my interpretation got updated). But that shouldn't stop someone else from bringing a tension to governance that they want to solve.

So, don't try solving governance issues outside of a governance meeting. And IMHO...the best way to avoid that, is make sure everyone knows that they should be documenting any tensions they feel (to be processed later).

The only exception to this might be if there is clearly a process owner (say a role accountable for "Defining the process for...") in which case the entire retrospective might be geared towards that role as the decision-maker. Kinda like how our Strategy Meeting Process involves several people, but is really just for the Lead Link to figure out what to do about it. In which case, it's more obvious that everyone else in attendance is really just a datapoint to help one specific role.