Sunday, December 7, 2008

Team racing challenge with our application

So it was a lazy Friday of a hectic week and I found myself dazed with all the meetings I had been through all this week. To pep up the spirits I coaxed my team members to take up a racing challenge where they will try to book a return train ticket in record time. The fastest one, gets a 1000/= gift voucher.

It was lucky that we did it in a meeting room around lunch time, since the excitement this created within the team was amazing. We had a stop watch going and people were cheering each other frantically. People had to go through at least 7 screens to actually buy a ticket from the web application. Some people got confused with a few screens which sure showed how usable the app was. A few others were trying to use the keyboard shortcuts in the app, some of which did not work that well.

In all among Devs, BAs and QAs .. it was a a Dev who made a booking in record time of 2 min 26 secs. Half n hour of good team fun !

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.

Sunday, October 12, 2008

What's in a role ?

We are a team of over 100 people. While it is scary, we try to do our best to be as Agile as possible. And it is common sense to most that scaling Agile to fit large teams is quite a difficult task. But while we are at it, one of the things that keeps striking me, is the number of roles we ended up carving out for various teams on a big account. For some reason we have the following roles.. Program Manager, Project Manager, Agile Coach, Release Manager, Business Strategist, Release Analyst, Tech Lead, Lead Analyst, Lead QA... whew !

The other day I was going through this article in Dr Dobbs and one thing which stuck me was the naming of roles they used in organizing large teams. Having someone as a Product Owner, Team Coach, and Technical Owner, gives a feeling to me that roles have more ownership and are not doing vague things as managers. Having team coaches instead of project managers motivates someone playing that role to focus a lot more on building a great team than just crunching numbers for a project.

When I told someone about this, they just felt it was stupid. Maybe I am reading too much into the article and the role game itself.

Continous Monitoring

Well.. Thats the name which Owen suggests in his blog. When I read it, it pretty soon occurred to me that probably thats where I wanted to go with my scope monitor. Not only scope, but real time monitor of your project health.

There are some ideas on using Kodak digital photo frames in work areas for the same purpose, or even sleek LCD displays which can be wall mounted. Owen has uploaded a presentation on that which gives a lot of insight in actually implementing it at your workplace. What do I use now... well currently just a PC with a big monitor near the work area. I am still figuring out a way to put it high up on a wall somewhere.

Scope Monitor

Working as a project manager for an Agile team, I found out that one thing the team needs to keep an eye on all the time is the scope being burned down. I saw other teams putting up big visible charts in the traditional XP style, but what if you cater to a client whose requirements change every other day.

A simple thing which I tried out was to put up a Scope Monitor showing where we are in terms of burning down story points for a release. It gets regularly updated from a Jira web service at real time. Here is an example of what it shows

Scope for the release ----200

In Analysis --------------- 20
In Development ----------40
In QA ----------------------20
QA signed Off -------------20
Customer signed off ------60

A traditional practice in Agile teams also has been managers pulling out the iteration status when they close an iteration to show to the whole team. So why not take it to the extreme and give the team more focus. Another advantage is that once this is live and kicking, your mangers need not always come in standups and talk about quantity of work left etc.. since the team can already see it. A manager can now focus on other priority issues for the day.