project management - Technomancy

My most recent Rails project has been fairly interesting to me because it's the most structured of any project I've ever done. Every week there's a conference call between the development team and the clients in which we demo all the work that we've done in the past week, bring any questions of direction or specifics before the client, and discuss what area the next week's development should cover. There's probably a fancy agile name for this methodology, but we kind of just go with what works for us.

This has had a number of unexpected benefits. For one thing, it brings a good level of focus. When you commit to taking a feature for the next week, you need to think about exactly what that entails and how much you can take on in that time. You have to know your limits. It encourages you to build features in small increments since you have to go all the way from database migrations to UI and HTML views (and occasionally even Javascript enhancements, although that can usually wait) all in a single week. I found this to be very helpful both in terms of helping me focus on the task at hand and in terms of thinking about the feature itself. When there isn't much time between the initial discussion of a feature and the writing of its UI, it's easier to consider its impact upon the users. If your initial idea had some flaws, they can be discovered much more quickly than they would otherwise be.

Every week since I thought of it I've written out everything that the week's demo will cover. I've found it's helpful to write out exactly the steps you're going to take to demonstrate the new functionality. Any small questions that can wait for the demo are noted in the margins, as is a list of initial plans for what you will take next week. It's also great to have paper in front of you during the call so if there's a small fix you need to do you can just jot it in the margins.

I've found myself to be more or less terrible at time estimating in the past, but the structured nature of this project means I'm constantly thinking about how long things have taken in previous iterations and how I should consider future features in the light of this. I've never had such a small feedback loop before, so I think this experience will go along way towards improving my estimating skills in the future. Being able to go back over the demo sheets also gives me a concrete record of what was done in each iteration, which is a handy reference.

Thinking in small discrete steps is great.

« 2007-10-13T00:00:01Z »

Christoffer Sawicki – 2007-03-13T09:36:54Z

Hey Phil!

Just for the record, I suppose this is what XP calls “Add a Customer to the Team” and “Release Regularly”. (Yeah, I looked it up in Extreme Programming Pocket Guide by chromatic – a book I can gladly recommend.)

Matt Scilipoti – 2007-04-03T10:15:56Z

Thanks for a clear, concise description of why small discrete steps are great for you. This may help convince teams I consult with to at least attempt it before they discount it.

Your method of documenting the story looks effective. It’s refreshing to see someone creating a solution that is appropriate for their needs vs. “but, the book says we should…”. You can easily add diagrams and GUI “wire frames”. I can’t wait until I find something as simple as pen and paper that works effectively with a team (i.e. supports collaboration, separate locations, is searchable, easy to review/accept updates).

And most importantly… thanks for sharing.

Fabian Bartsch – 2007-07-17T12:26:36Z

Good evening Phil!

It was very interesting for me to read your article, because i nearly have the same 'close-customer-contact' as you had, on my last project. We have meetings every two weeks, and so the customer was very closely involved in the developing-process. What i have learned is, that its very difficult to find out, what the customer and our team had appointed eg. four weeks ago, if both are not documenting the meeting-points and agreements very exactly. so, one thing we had tried is to record the meeting with a dictaphone, so that the whole team can listen everytime to what was discussed at the meetings. another thing what i think is, if the customer is involved that closely, you save more time in the developing-process, because things can be corrected fast enough, so that you not have to make big changes at the end of the project. Thanks again for showing another approach to that topic : )

Best regards,

Fabian