The Weekly Demo

lauantaina, helmikuuta 16, 2008

I've been involved in a few Agile projects and have formed a few opinions some positive and some negative. For example, I don't think that Agile methods work very well for established mass market desktop products while I think it works superbly for IT projects, web applications and projects that have a relatively small number of customers. I especially like the ability to come to a stopping point quickly and show the changes to the team and customers, which is what I'm going to talk about today.
I love weekly or bi-weekly demonstrations with the team and monthly customer meetings because I can get feedback and adjust my product rather than committing to something very uncertain. This demonstration schedule does not necessarily match the iteration cycle either and can run on just a developer's desktop. The point is to show the latest changes from one demo to the next, give credit where it is due, make minor adjustments to design and requirements and give a clear indication of the velocity of progress. My favorite benefit is the amount of sleep I get at night.
Yes, sleep is my favorite benefit. I don't worry about whether the customer is going to like what I am building by the time I hit delivery date. I don't have to worry about the work-flow because the team and product management have tried it a dozen or more times. I don't have to worry about major silly bugs because the demonstrations have usually exposed them already. As we know, all software crashes at the most embarrassing time: during a demo in front of a crowd. By ship date I can rest assured that anything glaring, bug or requirement, has been discovered and solved.
Building demonstrable code is not easy on a one or two week schedule. The goal is to stop building new functionality early enough to integrate and stabilize the code for demo. I like having only one week between demonstrations because the code base has not moved terribly far forward, which makes integration easy. I usually spend a portion of the day prior just for testing the changes and making fit and finish modifications. However, I can't do very much in the way of major changes. I work to get to the next demo and so I either must finish my changes entirely, disable the new code or demo around the incomplete code. Planning the demo is obviously important.
It often happens that the conceptualization of a work-flow turns out to be somewhat flawed. One can argue during the design phase that the flow is wrong but it is difficult to dissuade some individuals without having them actually try it. A demo illustrates the work-flow issues with perfect clarity. The results are the requirements, UI, back-end and test plans may change, but they changed early enough in the development cycle to be corrected investing a major development effort.
Regular customer demonstrations may not be an option. Some customers find demos annoying while others are happy to see progress. Regardless, showing them the progress made and the work flow at regular intervals is incredibly valuable in ensuring that the delivered product is what they want. The changes can be as simple as labeling issues where the customer realizes that the label is Ok, but they really call it X or Y. Its a 2 minute fix that makes the customer happy. Other changes can be very invasive, but you caught it early so there is hopefully time to solve it.
Making weekly team demonstrations effective is a straightforward process. First, have goals for what should be accomplished from one week to the next. Second, plan when to stop development and focus on integrating, testing and bug fixing. Third, during the demo describe the changes from the previous demo, giving credit where it is due. Fourth, modify the code after the demo to include suggestions and comments.
The weekly demo is incredibly valuable for finding flaws in requirements, work flow and implementation. In the best case, it validates that you were right all along. In the worst cases, it gives you the opportunity to change directions earlier rather than shortly before a delivery date. In any event, you know that by the time you deliver the final product that you are aligned with customer expectations.

You Might Also Like