Marty Andrews

artful code

Tuesday, December 9, 2003

How did <i>I</i> become a <i>Manager</i>?

I have the very official title of Iteration Manager on my current project. Recently, I was involved in some discussions with another project team that wanted to follow a similar structure, and someone very observantly mentioned that they had no-one in the role of Iteration Manager. All eyes turned to me. "What do you do?" they asked. Here's some of what I came up with...Kick-Off MeetingThis is run on the morning of the first day of the iteration, usually in lieu of the stand-up (we cover the stand-up details during the meeting). There are a few things that happen during the iteration:
  • I usually come up with an iteration theme to describe the goal for what we are doing in the coming two weeks. Examples of past themes have been "Look and Feel" or "Performance". This is the first thing I announce and provide some description around.
  • I then go through each of the story cards and get someone on the team to describe them. This is usually the person who has gone to the story card meeting and written up the story details.
  • The project manager and I have usually had a go at drawing up the stories on the white board before the meeting, and try to show some basic priority, and any dependancies (ie. the story card at the top-left should be done first etc.). We describe this to the team and get their feedback, making any changes if necessary.
  • Finally, we ask the team members to sign up as owners of stories, and for pairing for the first day.
Stand-Up MeetingWe run our stand-up meetings every morning at 9:30am. They include the development team, testers, business reps and project management staff. Often this number exceeds 15 people, so I'm quite strict on keeping any particular person focussed on the purpose of the meeting. People recognising issues is great, but any discussion around it that starts I immediately suggest should be held after the meeting. I try to get everyone to answer three questions:
  • What have you done since last meeting?
  • What are you donig today?
  • Is there anything (issues or otherwise) that the team should know about?
We usually manage to get through this in about 10-15mins. Its quite common for a couple of groups to chat about issues afterwards.Daily HuddleImmediately after the stand-up meeting (usually about 9:45am), the developers gather around the white-board in what has become known as the "huddle" to sign-up for tasks for the day. I'm there really to stop people procrastinating for 20mins about who should do what. Basically I just hand texta's to anyone who hasn't signed up and head them towards whatever blank spaces I see. Sometimes I take the opportunity to encourage pairs to swap as well.Tear-downThis meeting has evolved into two disparate sections, so I'll describe them independantly:The first part of the tear-down is a demo to the whole team (including business and testers) of new features that have been built by the team and have passed acceptance testing. I get the story card owners (they signed up for ownership in the kick-off) to prepare a short demo of a couple of minutes on their story. This sometimes requires a bit of data setup on their part. Each of the story card owners demonstrate their story, with some clapping and cheering after each. This is a regular point for everyone to feel good about how the project is progressing.After the demo, the business people and testers leave, and the developers get together and again go through each card. This time though, they talk about technical implementations of the story card. We discuss major technical issues, design desicions etc. This part of the meeting is usually facilitated by the lead architect, and is largely a chance for him and the other senior team members to keep an eye on the architectural goodness of the app whilst keeping the whole team up to date about what is happening on a technical front.RetrospectiveI always use "How to run an Iteration Retrospective" by Joshua Kerievsky as a guideline. My project retrospectives are very similar, but have a few noticeable differences:
  • We have a couple of extra sections - "Stuff to talk about" and "Stuff to try". This is just because things don't always fit into the main sections.
  • Instead of asking everyone what worked well/needs improvement, we just give everyone a texta, and they write up the points themselves. Its much faster, but I think this only works because everyone is used to the process now. I wouldn't start out that way with a new team.
  • After all of the points are written up, we have a quick chat about them so everyone knows what they mean.
  • Finally, everyone gets a texta again and votes for any issues they think are important to them. We action the top 5.
In addition to all of this stuff, I do some ad-hoc things on a daily basis. These are harder to describe, as they are more reactions to what is going on. Some examples are:
  • Trying to make sure people have a pair to work with.
  • Encouraging people to swap pairs.
  • Bringing around lollies to everyone (keep the team happy).
  • Encouraging people to have ad-hoc design meetings, or at least to chat with the senior developers on difficult technical issues.

No comments:

Post a Comment