Search

Saturday, July 23, 2005

Overtime?

Although it's not unusual to avoid crunch early on in a project, it's also typical to have very little real (product value) progress. It's almost as if things are taken easy early on and you save the pain for the end!

We're several months into two new project with major significant deliverables finished and very little overtime experienced. The main difference I see is with our good velocity of progress. This can be attributed to the intensity of the 2-week Sprints early on. This intensity drives real deliverables and real daily (8 hour) intensity. If we can focus on product value early, reduce the risk early and not save up our debugging and tuning for the end, we can keep this high-intensity, low overtime pace up for the entire project.

The goals of a Sprint create an increase in intensity every two weeks for the review. Waterfall intensity will peak every milestone deliverable, but since you are focused on documentation up front (which is typically lower intensity) and integration/debugging at the end (which is higher intensity coupled with the project deadline), then you get a trend like the red line. When intensity rises beyond a certain level, someone in the chain of command is going to push the "mandatory overtime" button.

This is not to say that Scrum avoids overtime. One team did put in a weekend day at the end of their Sprint recently. This was a decision by the team to meet their commitment.

Also I wouldn't say that we have the XP engineering practices down pat yet. We're building a backlog of bugs that will bite us at the end unless we continue to improve unit and functional testing. This is a big priority now.

No comments: