Pages

Sunday, November 30, 2008

Feedback Workshop

One of the important things I learnt as an apprentice from Owen Rogers was the importance of giving and receiving feedback and building a feedback culture around it in a team. Somehow in the last few years in Thoughtworks, owing to work pressures, these things have taken a backseat.So in a valiant attempt to revive these, I borrowed Owen's feedback workshop material and studied it. It clearly brought back memories of one of our "Self organized teams" we had built in the India office where exchanging feedback was natural to team members.

I work as a Project Manager for a team of around 30 people now. I waited for a day when there were hardly any meetings for the team, no IPM, no showcases and less chaos. Since it was my first workshop, I picked a group of 6 people from the team who were generally excited about trying out something off work. The group nicely included developers BAs and QAs. We sat in a circle and I gave each person a piece of paper, pencil and an eraser.

After a brief introduction where I spoke about why feedback is important and how it is different from the regular employee appraisal, I asked the audience, how many of them felt , we lacked a good feedback culture and almost everyone had there hands up. That was a lot of motivation to actually get started. We followed the Art Critic model and decided to draw "The Team" as the Art. After 5 mins, we exchanged the sheets of paper so that every member got someone else's work of art.

I asked people to think about two things they found good about the piece of work they had with them. After 2 mins, one of the members volunteered to share his feedback with the artist. I started emphasizing that it works best if one makes eye contact while giving feedback, and also addresses using first person. Using these tips multiple people tried giving their feedback to the artist. It was quite nice to hear what people had to say and actually watch what people had drawn that represented the team. (One of them had drawn a man lifting a huge basket of work and walking). I also emphasized the fact of saying thanks after one receives a positive feedback.

Then we did the same exercise for sharing feedback about things that could have been improved in the art work. I again emphasized on how well one can phrase such sensitive feedback, importance of soliciting it in first place, and the Giver's fantasy of how the giver doesn't have control over how the feedback is received, plays out. When one of the feedbacks was exchanged , I immediately saw the receiver going on their defensive and saying "Hey, I did not mean that in the drawing" or "Ya i thought of that, but did not do it because...". I took some time to speak about how its so natural for our defense mechanisms to kick in when we get some feedback about improvement on our work. I also spoke about how one can think about it as the giver's opinion and then proceed to think about why the giver has formed such an opinion and how it can be made better.

Once everyone finished their turns, I handed them a leaflet which contained the gist of what we spoke about, and also a set of questions seeking feedback about the feedback workshop. Being a PM of the team, I was also more interested in what feedback mechanism they most preferred in the team (Open , one on one in a room, impromptu as it happens. etc..).

At a personal level , I was really excited to relate to some of the things I wanted to say, with the actual feedback that someone tried to give in the group. It also felt really nice when one of the old timers, Raghu, said that.. it has been way too long since any such thing was done in TWI and he felt glad. I will wait and see when we can do a feedback session related to work itself within the team and explain how it should be separated from a salary appraisal.

The next thing probably would be more workshops, with some new ideas and feedback. I might also try the Myer-Briggs test, a few things from Fifth Discipline, and De Bono's techniques.

Tuesday, November 11, 2008

Scrum of Scrum bloat

If you are running an agile project divided into more than 3 teams, you will normally end up with Scrum of Scrums. The only problem with this is that it can become unusually longer if each project has a lot of burning issues. And burning issues have the potential of attracting a lot attention, people speaking out of turn, lot of cross talk, and in general a lot more to talk about. To enforce discipline in such chaos, one suggestion that Gabbar gave me was to put up a stop watch of 2 minutes per person. A talking token would have worked if it was heavy enough, but again with people joining over conference call , it doesnt work.

I used this version of an online stop watch and it worked well so far. It is also available for desktops and can be shared over web meetings. People automatically started making their updates crisp and to the point.