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.

Friday, November 28, 2003

I can drive pretty fast, but am I going in the right direction?

Speed tells us how much distance we cover over time, and velocity adds to this by giving us a direction as well. If we don't arrive at our destination on time, that can be for a few different reasons. We might not be driving fast enough, we might have spent some time going in the wrong direction, or we might have spent some time just parked by the road and not driving at all. Jason Yip helped me clarify some ideas around useful measurements on an agile software project with this example...So my mate Con the courier didn't last long in his job. His boss asked him to drive a package from Melbourne to Adelaide, a trip which takes about 8 hours (if you go straight there). Three days later, he turned up with his delivery, and the boss was fuming."My Grandma can drive faster than that! What happened!"Of course, Con had a different story. He showed his boss the trip meter in the car, which distinctly showed an average speed of 110kmh, 10kmh faster than the average of the best courier drivers. However, the boss also noticed that the total distance was about 2000km (its only 800km between Melbourne and Adelaide)."2000km! Bloody hell - did you come via Timbuctoo?!"Con explained to his boss at this point that he had in fact come via Sydney, not Timbuctoo as first thought (silly boss), and whilst he was there he had worked with a specialist to build a steel framework in the car that would enable it to carry loads of up to one tonne, should the courier company ever need it. The boss obviously had no argument for this logic, but was still confused about the timing."Even if you did come via Sydney and soup up the car, it still should've only taken two days. What happened to the other day?".The boss had obviously forgotten about the regular meetings that had been instated by the parent company. Con pointed out to his boss that he had to stop driving twice a day to attend a couple of one hour phone conferences about car maintenance and planning for new courier routes.Cons boss seemed somewhat flustered by all of this, and was actually quite annoyed by Con's arrogance. He said nothing more at the time, but a few months later, Cons contract wasn't renewed...I see examples of these scenarios every day on agile software development projects.The programmers are inevitably pretty good at what they do. They work hard, and can produce working code quite fast. The amount of time they spend at work is the Project Speed, but the time they spend actually cutting code is their Programming Speed. The difference between these two figures is the Non-Programming Time, and if it's large could mean that, like Con, the developers had to stop driving to spend time in meetings or other activities.Most of the time, the developers are producing code that actually works toward some feature that the customer has asked for. This is their Velocity. The difference between Programming Speed and Velocity is the Non-Velocity Programming Time. Some of this is legitimate (like producing spikes for example), but developers can also be tempted to build unecessary things too (like Con did with his stell framework in the car).All of these metrics can tell you something useful about a project, and they can be quite easily measured as well. Metrics also provide you with great power in influencing (appropriate) change, and can help prevent against knee-jerk reactions like "the programmers aren't working hard enough" when in fact they are actually just spending their time in meetings.Perhaps if Con had measured his facts and just shown the log book to his boss, instead of using his "I know better than you" attitude, he would still have his job today...

Wednesday, November 26, 2003

Musical Introductions to Agile Project Events

We have a bunch of different events that occur at regular times throughout the iteration on our agile project. Daily Stand-Up Meetings being a classic example. One of my colleagues, Perryn Fowler, has seen fit to delve into his library sound grabs to provide with a musical reminder of whats coming up...It all started a few weeks ago, when Perryn worked on a particularly long and drawn out task. A bunch of tests were broken as a result of the work being started, and Perryn slowly clawed his way back to a working build with his new features in it. It took a few days all up, and we were keen to integrate the work. When it was finally time to commit, we heard a song being played from Perryn's desk with the following lyrics:"I'm checkin' in.""He's checkin' in.""I'm checkin' in.""Checkin' chekin' chekin'."This is, for those who don't recognise it, is from the Simpsons episode "City of NY Homer Simpson" where Marge, Bart, and Lisa see a broadway musical in which a celebrity checks in to the Betty Ford Clinic.At the stand-up meetings this week (which people generally don't get too excited about being first thing in the morning), Perryn again decided to pep up the team with a tune. On Tuesday morning, we had a tune from "Caravn of Love" by the Housemartins:"Every woman every man""Join the caravan of love""(Stand up) stand up""Stand up""Every body takes a stand""Join the caravan of love""(Stand up) stand up""Stand up"Then on Wednesday morning, Perryn went for some Bob Marley:"Get up, stand up: stand up for your rights!""Get up, stand up: stand up for your rights!"We've had great success with our musical introductions so far, and are on the hunt for more tunes to show events during the iteration.

Saturday, November 8, 2003

Seating layout for 20 please.

The department I am working in at the moment is moving floors. I've made enough noise about optimising are physical team layout in the past that the programme manager asked me to plan it.We had 20 seats in all that I had to fit the following people into:
  • 1 Programme Manager (part time)
  • 1 Project Leader (part time)
  • 1 Release Manager
  • 1 Business Representative
  • 1 Developer/Iteration Manager (me)
  • 14 Developers
  • 1 Continuous Integration Machine
I was basically given the option of making the final call, but there were a few guidelines that our programme manager wanted me to try to follow:
  • He wanted to sit near his boss (who was adjacent to our area in the top right).
  • The "management" types on the project should be near each other.
  • The business representative should be near the other business staff (adjacent to our area at the
  • bottom right).
  • The developers should be near the other development teams (adjacent to our area at the left) to allow for fluctuation in the team size as the project went through various phases.
  • Department ettiquette said that senior staff (we have three of them on our project) should be offered the window seats first.
In addition to these guidelines, I came up with a couple of my own:
  • Three of the developers were supporting another released project part time. They needed to be close to the project leader (he was responsible for that other project).
  • I wanted the development team to be as close together as possible (in a "pairing zone") for day-to-day work to maximised communcation. That meant seating 100% allocated staff in that area and putting our best computers on those desks.
  • I wanted the senior staff to have desks next to the pairing zone to achieve ExpertInEarshot.
Phew! That was a lot of things to keep in mind for a seating layout. Just to make things worse, I had one final card to play. I wanted the entire team to get together and agree on it. One of the other management types told me I was nuts, but I did it anyway.So I drew our floor plan section up on a whiteboard and wrote everyones initials on a post-it note. Then I gathered everyone together and told them all of our guidelines. I immediately had a couple of issues come out which I noted on the whiteboard to keep in mind. We needed a baseline, so I started by putting all of the developers (our largest group) on the plan. Then I fitted in people at random around it.This baseline brought up a lot of discussion. People could now see exactly where they might be sitting, who they were next to etc. However, it was actually very close to our final plan. The main discussion was around the shape and location of the "Pairing Zone" on the layout. A vertical shape put developers the closest together but didn't work with the window seat ettiquette. A horizontal shape on the left was good too, but didn't allow us to have senior staff and management nearby at the same time. We ended up compromising by moving the zone to the right a bit, which meant it had a walkway up the middle, but we could achieve all of our other goals.A few minor shuffles later with input from management and everyone agreed. It only took about 20 minutes - amazing!Shortly after the meeting I made one shuffle to move myself to the edge of the developers and the managers, but went and told everyone. No complaints. The programme manager (who couldn't make it to the meeting) also made one minor change where he swapped to of the senior staff (they were sitting next to each other anyway). Now everyone affected had had input to the seating plan.
New seating plan

Sunday, November 2, 2003

The creation of a web-site

I've spent a couple of days worth of effort now setting up my first serious website (this one) from scratch. With any luck some people might find some useful information here that helps them out. I've learnt a bunch of stuff along the way.The design I basically made up using a combination of features I've seen on other web sites, plus a bit of experimentation. The intricacies of cascading style sheets was unfamiliar to me when I started, but now I'm at least a novice user... winkThe blog is run by greymatter, an open source perl project. The wiki is a customised version of JSP Wiki which is obviously a JSP based product - again open source. I've used the wiki many times before on various projects and find it very easy to use. The rest of the site is just plain old html.I think I've got a lot more to learn, but so far I'm happy with how its turned out. I'm looking forward to learning a whole bunch more as I use the site in anger.

Sunday, October 26, 2003

Setting up a blog

I've now largely finished setting up the greymatter blog. It's pretty straightforward. Just drop in the perl scripts and then follow a bunch of menus to get it set up.The HTML templates for all of the screens are edited via a web app as well. The hard work was basically getting the blog look and feel to be the same as the site look and feel.Now for the wiki...