Reflections on "The Sprint"

I am really enjoying reading the 'Slack' book by Tom Demarco (Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency). It's setting in enough that I am pressuring myself to not do real work right now and write something for the blog instead. He makes many great points, and ones that I've already been trying to push on my colleagues (for example, by ordering one of the support staff to not stay a minute past quitting time and "Go home!").

One section I found interesting was his description of the "Sprint" at the end of a project. He describes one way of handling the sprint, where team members pull marathon weekend work shifts, taking naps on the office couch or overdose on caffeine to keep going. The team will stick it out together until Monday morning, and (hopefully) will finish victorious. Another way is to have people work regular overtime in the last weeks/days before the launch to finish everything up, rather than crashing all of the resources at the very last few days. He explains that each one of these methods has a different effect on the team morale. To do the sprint over a couple days rather than the last few weeks, although exhausting, can create a real bond and almost a 'high' for the team as they pull together their last bit of energy to bring themselves to the finish. The extended overtime will more likely lower the morale, cause stress and problems with personal life, etc.

The description of the weekend marathon sprint brought back memories of college, of the last days before my senior engineering project was due. Three other Mechanical Engineering pals and I had spent the year together designing, building and testing a small low-cost and feul efficient turbojet engine. In the last days before our project was due the engine was built to the best of our ability and we were gathering our reports, writing up our research and putting it into as presentable a thesis as possible (engineers trying to write a paper...funny). We were in and out of the engineering building at all hours of the night, taking turns sleeping and writing, and thankful for the one or two 24 hr takeout places nearby. It was an amazing bonding experience, and we did finish in the end and get our report written, nicely bound and in our advisors office by that Monday at 5pm.

I was 22 back then, and had alot more energy and the drive to do those marathon work sprints. The best I can compare it to now is the first few months after each of my daughters were born, staying up at all hours of the night to handle feeding & changing and whatever other needs they had, trying to get daddy to help with whatever he was biologically able to do, although even that was a project sometimes.

But, enough reminiscing about those wonderful sleepless nights, I started to think about the sprints I've been involved with for my software projects. Not too many I'm happy to say, and I even wonder if the ones I was involved in were very effective, especially when it comes to quality of product.

Writing, fixing, and migrating code is not exactly something you want to do when you're tired, there's way too high of a risk of error and more problems as a result. We like to joke "Hey, don't drop the database by accident" when our programmers write scripts on the database, because someone did once, by accident of course and thankfully not on the live database. Making critical decisions about a project is not something you want to do when you're tired, it's too easy to get caught up in the moment and not be able to think clearly. System test and bug checking is not something you should do when you're tired, you don't have the focus you should have and will be too quick to rush through testing because you feel so close to the finish.

The times when my project team has had to do these types of sprints to get a project done have not ended in disaster, for the most part things were ok (except for that one time years ago when we realized at 2am Monday morning that we had to roll back an entire project and months of programming work, by the time people got into the office at 9). And even though it might have been a nice bonding experience, I can't say I love doing it this way. I would like to think that in an ideal world we won't be in the situation where we have to pull marathon work shifts to get the project out in time, and I'd like to say that in the interest of quality we should avoid this all-together.

Is it possible to always avoid? Probably not. I am fortunate to have a client who allows me flexibility most of the time with my launch dates, and I guess I should just be grateful for that!