Tortoise Projects And Hare Projects - Setting A Sustainable Pace

Hi Folks

We probably all know the old story about the tortoise and the hare. Speedy hare raced off, got tired and had to have a rest while slow tortoise kept plodding on at a steady pace and eventually won the race. Even hare's mad dash towards the finish wasn't enough to catch up. Everyone knows the moral of the story - slow and steady wins the race. When it comes to running projects though, we behave more like hare than tortoise.

We start with a great rush, writing requirements, designs, specs. Having kickoff meetings. Then the long slog begins. The deadline is 18 months away. Plenty of time. The team starts to cruise. "This will be easy" we think, "Plenty of time". We focus on getting the requirements exact, the design "just so". We build frameworks and libraries of reusable components. Then suddenly the deadline is a couple of months away and we have nothing that works end to end. There's lots of bits but nothing joining them together. The crunch is on. We code like mad. Pull all-night shifts. Throw out our carefully designed frameworks and just focus on getting stuff done. Testing starts and the bugs start to pile up. More all-nighters to fix them. Then suddenly it's all over, the release is out. We all take some time off to recover and gear up to do it all again. Or we get burned out.

Developing software is not a sprint, it's a marathon. You don't finish a marathon by sprinting then resting then sprinting again, you win it by keeping up a steady, sustainable pace (you also finish by ignoring a lot of pain which isn't a good thing in a project but more on that in a later post). And yes, the "sprint" in scrum is badly mis-named as it implies that "sprint then rest" type of behaviour. This is not what the agile model is about.

One of the key concepts behind agile (and Lean) development is the sustainable pace. The team finds a pace that works for it and keeps going at that pace. While the tortoise may have been slow and steady, a project team should just be steady. They should maintain the fastest pace that they can sustain long term. And by long term I don't mean a week or a month, but potentially for years. A good agile team should be able to keep delivering consistently, increment after increment, almost indefinitely. Sounds good, but how does agile achieve that where traditional project management doesn't?

There are two main ways agile drives a sustainable pace. The first is through incremental development. Anyone who remembers university will remember delaying that assignment until the last minute then rushing to finish it in the last few days. Human nature is to delay work until the deadline looms. It takes a lot of discipline to focus on a deadline that is 12 or 18 months (or longer) away. By breaking up the project into small chunks, agile sets not one big deadline at the end but a lot of smaller deadlines right through the project. By continually having a deadline, where working stuff actually has to be delivered, no more than a couple of weeks away, agile teams are always working with the pressure of a looming deadline. That doesn't sound like much fun but remember that this isn't a year's work crammed into a month, it's a month's work crammed into a month. It's a realistic goal which is achievable without the team needing to work horrible hours.

The second key is frequent testing. A lot of the crunch in traditional projects comes at the end when testing starts and problems start being found. In an agile project, testing happens (or should happen) within the increment so issues are being found from day one. They should also be fixed from day one as well. Early testing along with a "stop the line" culture stops that last minute bug crunch and ensures not just sustainable pace but sustainable quality as well.

Cheers

Dave