Caffeinated Coder

…just do it over there and try to be quiet about it. I’ve got work to do.

Anyone who has ever worked with me knows that I am not fond of meetings. I’d like to think that I have improved over the years, so it is not quite as apparent to people who don’t know my body language well that I am getting impatient. I used to give ever-so-subtle hints like moving to the edge of my seat with my hands on the arms of the chair or throwing out the “…so is there anything else?” phrase with just the right intonation so as to warn listeners that there had better not be anything else. I’m sure I still do those things to some extent, but after being teased about it for a while I at least make an effort to exercise more patience these days.

One thing that has really helped improve my attitude towards meetings is the Agile practice of doing Daily Stand-ups. When I first heard that we were supposed increase the frequency of meetings from once every week to every day, I was skeptical to say the least. However, the format of a properly conducted stand-up meeting lends itself to very short, productive meetings that I actually find useful. Participants take turns answering three questions that focus on communicating to the group whether or not they have met the commitments they agreed to yesterday, what commitments they feel comfortable making today, and what issues are currently slowing them down. The physical discomfort of actually standing up in a circle is supposed to remind team members that they should be concise (the whole meeting should take no longer than 15 minutes) and reserve any topics that don’t involve the whole group for side discussions afterwards.

If you are new to the practice or are dissatisfied with how your daily stand-ups are currently being conducted, I recommend reading this article by Martin Fowler. I especially liked the section on Bad Meeting Smells (not to be confused with the body odor smells noticeable when standing too closely) and how to fix them. I definitely recognized a few symptoms that our teams have grappled with at one time or another, such as meetings lasting longer than 15 minutes, excessive problem solving, the “I can’t remember” phrase, and reporting to bosses not peers. I also appreciate how the main focus of each of Fowler’s suggestions relates back to the goal of keeping the energy level in meetings high, which is ultimately what I don’t like about the majority of traditional meetings I attend.

Now as for you meeting moths…shoo…

Someone sent me a great quote the other day from Douglas Adams:

“I love deadlines. I especially
like the whooshing sound they
make as they go flying by.”

It brought back distant memories of a gigantic waterfall project that I survived. I think the word survived is appropriate in this case because we labored on it for over 3 years before we ever released code to production, which by that time was somewhere between 12-18 months later than our original deadline (I blame my fuzzy memory on the excessive overtime that overshadowed that part of my life). As with any good old fashioned waterfall project, the first in a long series of missed deadlines was arbitrarily generated by the business and the project was both time-boxed and feature-boxed (at least in the sense that the amount of work rarely went down).

There were many months of intense overtime, implicit threats of being fired, low morale, and constant bickering with users over whether or not a newly requested feature (or as they liked to refer to it…bug) was explicitly or implicitly included in the 500 page functional specifications. I have clear memories of pondering whether I should keep the % complete cell in the project status worksheet at 90% complete for yet another week or move it up by 1% to delay the inevitable ‘Come to Jesus’ meeting for just a little bit longer just in case a miracle happened. The strange thing is that the project was still considered tremendously successful despite all the waterfall-induced deadline madness. Ah the good old days…

A few years ago, our IT department adopted an agile approach. I’m not saying that things are perfect. We definitely had speed bumps and hurdles during the transition period and still have occasional perception problems to deal with when a team’s velocity dips too low for too long, but it just isn’t’ the same. I rarely notice any users yelling at project managers or any developers working for over 40 hours or talk of an impending deadline that everyone is worried about missing. Teams actually seem to be able to release code at the promised time.

All of this makes me feel like a rite of passage is slowly fading away and 10 years from now young developers will roll their eyes whenever I reminisce about the ‘old waterfall days’. I will say, ‘Why…back in MY DAY…we didn’t have these sissy, daily stand-up meetings…We waited until the executives were good and ornery and before we bothered scheduling a status meeting…’

By the way, there is an excellent podcast on dotnetrocks about agile methodologies. It is a live panel discussion from last year’s Tech Ed in Barcelona with Roy Osherove, Seven Forte, and Kate Gregory.