by ·0 Comments

[Feb 2018: S3 changed the name from Effectiveness Review to Peer Review]

Since the last blog post(see http://tomek.kaczanowscy.pl/2016/12/sociocracy-3-0-effectiveness-review/) we run 2 more effectiveness reviews (ER in short). This blog post gathers my thought, comments and lessons learned. Hope you find it useful.

Preparations.

Based on previous experience I took the following steps to make the next effectiveness reviews even more fruitful:

  • I prepared a document explaining shortly what it is and what is expected of the participants.
  • I tried to make driver & role description more visible during the meeting – so that the appreciations and improvement suggestions were more related to it.
  • Last time we ended the ER with development plan in form of some additional notes added to the “improvement suggestions” flip-chart card. This time I wanted to end the meeting with more explicit development plan (i.e. written down separately, so there would be no confusion on what was really decided).

Also, I created a short checklist for anyone who wants to run an effectiveness review (with some basic stuff like how to prepare room etc.)

Time

Recently I’m pretty focused on the meetings efficiency. I hope to run ERs regularly so I want them to be as concise as possible.

In one of today’s meeting I set some strict rules: we speak straight to the point, no discussions, no preamble, no starting with “Uhhmmm…. Well… so…. Of course I agree with what [name of previous participant here] said, because I also feel this is very important. And also I would like to add that …” (15-20 seconds gone, now multiply it by number of participants and number of rounds!). It worked wonders – we avoided a lot of time wasting talking and the whole event was much shorter.

However, later when I discussed the event with some participants, I learned that there are some downsides of this approach (excerpt from an email I got):

“I thought the meeting was slightly rushed with the onus being on short sharp bullet points of feedback however I think we could have elaborated on our points more and given examples which could help benefit the person.”

In general there is some tension between having an efficient meeting and allowing people “to do the long and non-value talking as they usually do”. Currently I value efficiency more (but I try hard not to be rude interrupting people etc.) Still, my approach could be improved – one person suggested that giving examples (context) for appreciations could be valuable, and I agree with this idea.

Anyway, I believe that with artful participation it is possible to have a very fulfilling first ER taking less than 30 minutes. I also think that the consecutive ones (for the same role) can take half of this time.

My learning also is, that if you clearly state the purpose of the meeting (easy-peasy in case of ER: first we do appreciations, then we do improvement suggestions, so in the end we can have development plan) then it is pretty simple to stop any discussion that is not moving us towards the goal of the meeting.

Taking notes

Taking notes sounds simple, but it ain’t so. After one of today’s ERs we had notes so good, that people who wern’t there would benefit from reading them. The notes from the second ER would be completely cryptic to someone who wasn’t there.

In general, I think taking good notes is a skill that could be trained.

As for now, flip-charts worked for us better than whiteboards. The notes on flip-charts were more readable. Not sure why – probably because the flip-charts offer infinite surface which encourages the scribe to write longer sentences (and thus achieve better readability afterwards).

My ER

One the ERs today was mine (“lead by example”, isn’t it?). I have to say this was a positive experience. First, it is really encouraging to hear the appreciations and learn that this thing, that maybe I was even embarrassed about (oh, no, I can’t bother them again with this, no, I really can’t), that they actually appreciate it. Second, the participants gave me some really valuable feedback on how I could improve. Some of the things I was aware of (“delegate more!”)  but some were new to me. And even for things I knew about it makes a difference if you hear it from few people. At least for me.

And BTW. I think I did a good job on selecting people – I took some close cooperators but also few “independent thinkers” that I do not work on daily basis but who are influenced by my job. Thanks to this, I got feedback from very different perspectives. 

I ended up with a 5-points development plan. Some of the tasks too big to be “action points” but rather directions I should move into.

During my ER I had this feeling that some participants are actually more nervous than I was. It seemed to me, that it was hard for them to express their opinion in a public setting. Probably my role might have some impact on this, however, I know all of the participants pretty well and we are on friendly terms, so I’m not sure where this hardship is coming from. Also, it seems that for some people it is awkward to give feedback in such public setting. No problems with appreciations, but improvement suggestions are hard for some. I wonder if this is only because we are not used to do it in such manner? Some also dream of good, old, corpo days when managers would handle the hard stuff (an excerpt from the email I got afterwards):

“Obviously its a lot harder to give more constructive criticism face to face so I prefer anonymous then the manager will collate all feedback.”

Final Notes / Random Observations / Concerns

Notes to myself on what to improve:

  • Work on roles – our old job descriptions we use instead of driver&role are not good enough.
  • We need more skilled scribes.
  • We need more skilled facilitators.
  • Sending email with guidelines for participants seems to work pretty well.
  • I still have no clue how to efficiently amend the driver/role during the ER meeting.
  • The 1-month frequency is not good for everyone. Need to be flexible with this.

Some doubts:

  • If the role is not clear enough then so are the improvement suggestions. So, first work on the roles.One of the concerns we have is the following. The ER concept seems to work fine when there are no major issues with roles. The atmosphere is friendly. How will it work if there are some serious issues with person in role? Will the participants be polite enough to express their doubts in form of civilized “improvement suggestions” or will the whole meeting divert into some kind of judgment and punishment for the hero?
  • In general I feel ERs are a valuable addition to what we do, and we should continue. However, I have doubts whether ERs are suitable for everyone. Will developers benefit from this kind of meeting? I’m not sure. I think in the case of many devs code reviews, 1-on-1s with tech leads and team retrospectives might be good enough.

by ·0 Comments

[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  – 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:
  • 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!