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

Agile retrospective - Holacracy style

Hey, I wanted to share our current version of our team retrospective process in case anyone found it useful. It is pretty much a standard agile retrospective process that you might see in Scrum, with a little Holacracy mixed in. I suppose you could also use it to help folks generally identify tensions in any team, not just in software teams.

Here's the basic process:


Checkin Round: Normal Holacracy meeting style checkin round

Data capture: on a "sticky", put items on a sticky note for the following (we limit to 5 per person, but you can adjust for team size):
 - What went right? 
 - What went wrong?
 - What had you confused?

Group the items and discuss: sometimes we use labels for the groupings/themes that emerge

Pull out actions and projects: be sure to capture these in Holacracy tactical meeting output format; someone can volunteer to email them, and each person is responsible for putting their items into their personal organization system.

Closing Round: Normal Holacracy meeting style closing round


I think the important piece is to make sure you have clear, actionable items at the end, consisting of projects, actions, or tensions to bring to governance.

We're a virtual team, so here's a template of the virtual retrospective board we use in the GlassFrog circle for you to copy and use. You can also do this in person with real sticky notes and a nice big wall:

https://docs.google.com/drawin...khk/edit?usp=sharing

6 Replies
Bernard Marie Chiquet
02/09/2016

Thanks Alexia for sharing, it's very helpful - we'll use it with one of our IT company client

Sergey
02/10/2016

Thanks for sharing. The only problem that I see with this approach is its "sameness". If I will do all my retrospective the same (in format) I will bore to death its participants after 10 repetitions. That is why retrospectives (in scrum or else) should be different every time you run one. That is how I teach organisations to do it (being a Certified Scrum Trainer).

Here is a few other ways just to get you started:
http://www.plans-for-retrospectives.com

Tim Higgins
02/11/2016

I agree with Sergey.  Very simple changes help to make the Retrospectives more interesting.  One, for example, would be to put your 'sad', 'glad' and 'mad' stickers on a timeline of the period you are talking of in the retrospective and get people to draw a line of how they were feeling on the timeline.

Alexia Bowers
02/11/2016

Thank you for the insights! I think you could drop any reasonable retrospective process into the sticky note portion of the process. I think the main thing is that you have a checkin, a closing, some sort of tension/data gathering process, and make sure that all solutions are funneled into clearly stated and clearly owned projects and actions (or action to bring a tension). I have seen lack of engagement when the team felt like the retrospective didn't lead to any concrete changes, and I think tying it back to Holacracy makes the meetings more engaging because it makes the value more obvious.

I think a variety of processes might raise different types of data, so that might also be a good reason to change up the process type. We probably haven't run this process with enough consistency to see fatigue with it, but I do think that Holacracy really makes it more engaging for us in the GlassFrog circle.

Do you have any other processes that might be useful, especially for folks who don't use agile, but want to use a retrospective style meeting to help a team get in touch with their tensions? 

 

Sergey
02/11/2016

A common process for retros is:

1. Opening & check-ins
2. Gather data
3. Generate insights
4. Decide on actions
5. Close the retro

In what you described it looks like you miss very important step 3 Generate insights. This can lead to fixing the symptoms and not addressing root causes.

You get the data (feel the tension: my head is warm), and you jump to actions (lets put ice on your head to cool it down). Actually missing and not treating the root cause (flue).

Another remark that I can not not to make is: Its not possible to use Agile. Agile is a state of being, its a mindset, a philosophy, a religion if you want. And its not possible for a team to do Agile. You can do Scrum, or Kanban, XP or other framework, but you just can't do Agile. You can be Agile. Its an important distinction. Sorry for being picky . Don't want to offend anyone.

Alexia Bowers
02/12/2016

Hi Sergey,

I think that the 'Group the items and discuss' is meant to be the generative part (your # 3)  - so thank you for adding that distinction. We aren't too formal with the process, and we sort of do a little of #3 & #4 in there - though most of the deciding on actions is done by the role taking the action/project.

Regarding agile, I agree with you - it is weird to 'use agile' - it doesn't make sense conceptually. I meant 'use agile' as shorthand for 'use agile software development methodologies' - I had thought the rest was implied, so I apologize for the confusion. I really only think of 'agile' as describing something else (agile principles, agile methods, etc.), so I didn't expect that interpretation, but I see it now that you say it!

I do disagree that you can 'be agile' in the sense you described it - I would actually say something more like 'you can embody agile principles'. To me, 'agile' describes something based on context and is sort of meaningless by itself, and difficult to quantify and embody. Unless you mean 'agile' in the traditional sense, as in 'agile like a cheetah', then maybe you can be agile, but definitely not me!