The importance of having a goal

The positive effects of working towards a specific goal are well understood. If we can also measure the progress we've made towards our goal, the chances of success increase further.

Here's a quote from Heidi Grant Halvorson taken from an article on the habits of successful people:

Just promising you'll "eat less" or "sleep more" is too vague — be clear and precise. "I'll be in bed by 10pm on weeknights" leaves no room for doubt about what you need to do, and whether or not you've actually done it.

What has this talk of early nights got to do with iterative development?

A team that sets itself a goal to implement and release selected stories in a fixed length iteration or sprint has a clear target to aim for. There's also a very easy way to measure progress towards that target. Aiming to complete those stories brings a subtle but important sense of urgency.

Agile techniques that don't use fixed length iterations (such as Kanban) have their merits, but they don't instil the same focus on delivery.

It's easy for us to get caught up in code and lose site of the bigger picture. Awareness of the iteration plan (and how much work you expected to be able to complete when you made it) helps keep the project on target. When things aren't going as smoothly as you hoped, keeping a weather eye on the iteration's progress gives you an early warning about features you or your team are finding problematic. You get an opportunity to steer the team in an alternative direction without wasting time on what might be a relatively low priority.

That's where my sense of urgency comes from, and it's why I prefer to work in iterations.

On the subject of urgency, this is a great quote from Bruce Upbin about one of his old instructors:

His goal was to keep all of his students in the pocket between boredom and anxiety – but closer to anxiety. In other words, we shouldn’t be so overwhelmed that we break down and give up, but we also shouldn’t be coasting either. He kept the rhythm fast enough so that we were challenged, but not so difficult that we lost the steps completely. And he kept tuning the difficulty level of the class to stretch but not break us.

About the author

Graham Ashton

Graham Ashton is an experienced agile team leader and project manager, and the founder of Agile Planner. You can follow him at @grahamashton on Twitter.