[Feb 2018: S3 changed the name from Effectiveness Review to Peer Review]
I rarely write about S3, but when I do, it is long and boring. 🙂
Below you will find my experiences with the S3 effectiveness review (currently called “peer review”) – an idea that I borrowed from S3. I hope that maybe some comments that I share will help you to run yours.
Ah, names of people are changed in order to “protect the innocent”.
So, there is this team, that was going some reconstruction, meaning people changed roles. And I thought, that maybe this is a good point to introduce some new practices (and I have to admit I was looking for some opportunities to introduce selected S3 patterns since I attended an S3 training with Lily & James).
Fortunately, John, who was appointed team lead, agreed to become my guinea pig. So here is what we did plus some comments/improvement ideas:
- Started with the driver (why this team lead is needed) and with role description. All written down by John & me, and later reviewed and enhanced by another member of the team. We ended up with 1-page doc (used google docs which is nice for collaboration/sharing).
- Decided to run effectiveness review once a month.
- Asked Joanna – an agile coach from an agile consulting company (with some S3 experience) – to facilitate the meeting and help us prepare.
- From the very beginning we planned (and John agreed) that this event will be opened to observers – I wanted few leaders of other teams to join us so they could observe and learn how it looks like (and hopefully want to introduce effectiveness review for their teams as well).
- Since we had no previous experience, we tried to plan it very carefully. Joanna & me worked (shared doc again) to list all things to be done – like what kind of materials should be printed, who the scribe will be, what should we tell the participants beforehand etc. In short, we wanted to make sure this event will be well prepared, so that it runs smoothly.
- I talked with every participant (selected by John) explaining the idea and their role. Also, I talked with all the observers. All received an email with links to:
- https://patterns.sociocracy30.org/peer-review.html
- Role driver
- Role description
- We set the room so there was a circle of 6 chairs (for the main participants) and some places outside the circle (for the observers). We decided to take notes on flipchart.
- The scribe, wrote down every appreciation & every improvement suggestion on the flipcharts. Tip: We used two different colors alternately so each idea was well visible.
- We ended up with some action points for John (all related to the gathered improvement suggestions) for the next weeks.
- After the event the scribe sent around all the notes gathered during the event
- The whole event took us ~55 minutes. I think we can cut the length of this meeting by at least 10 minutes next time.
The results / comments / improvement suggestions:
- Reception
- In general this was well received both by team members and by observers.
- I asked some team members how they feel about it. They say it seems really valuable.
- Some comments from the team members like “a pity we haven’t used this approach earlier” (this team has quite a troubled past, so maybe such effectiveness reviews could had been useful).
- What was good
- Friendly attitude is IMHO crucial. The fact that our facilitator (Joanna) was beaming with positive energy helped a lot.
- Asking “external expert” – Joanna in our case – to facilitate this event was a good idea.
- It is very valuable to have different people participating – in our case we had 3 team members, a product owner, and IT recruiter. All of them had recently worked a lot with John. Thanks to this diversity John received very different comments. Good.
- A note about transparency: as I said before we sent around the notes from the event. Surprisingly, this helped another team member (who wasn’t participating) to understand his situation in the team (do not want to go into details here, only stressing out the fact, that unexpected – and good – things happen after you let the information flow.
- Flipchart notes worked very well. Recommended.
- Emotions
- One person told me he would probably die if it was his achievements being discussed in such public setting. This is an important information to me – maybe for some individuals we should go with something less public (kudo cards?).
- John is a very open person, but I observed that he was nervous before we begun. Fortunately, he was doing a really good job recently so he received a lot of appreciations and this relieved the tension.
- Next steps
- I talked with the observers trying to persuade them that maybe, possibly they could also benefit from establishing roles and running such effectiveness reviews. One person wants this very much, others are more cautious, but in willing to give it a try.
- And yes, we will definitely run the next session for John in one month time.
- From the discussions with some observers we have this idea, that such effectiveness review might not be feasible for some roles – for example, we were wondering if for regular devs, this would give anything more than what they learn during daily code reviews & architectural discussions. Not sure about this one, will see.
- When discussing the idea of organizing such effectiveness review for a specific person I heard that “in case of this particular person, such a very positively-aligned meeting could make things worse”.
- The context here is that the person in question has a very high idea of his skills/quality etc. And since effectiveness review is pretty much about positive feedback it could result in even bigger ego.
- Also, in this particular context, the idea that the person selects participants seems kind of dangerous – we could expect this particular person would select only those, who would praise him. I guess in such cases the list of participants should emerge from some discussion among e.g. person and his boss, and not based solely on person’s opinion.
- Improvement suggestions
- We should focus on the driver and role description more. We drifted too much from John’s responsibility to general ideas of team improvement. It was also valuable, but not exactly what we hoped for. Next time I want to have the driver/role visible all the time (overhead projector).
- We need also to help people prepare even more than what we did this time. I think it is crucial to first have a good discussion about the driver and the role with the whole team. Also, all participants should understand that the meeting is about helping someone fulfill his role better. However, as for the first time I’m really happy with what every participant brought to the discussion.
- We will probably ask Joanna to facilitate few more events but then we want to do it ourselves. After all, it doesn’t seem such a big deal.
That is all folks. Comments/questions welcomed! Cheers!