To Timebox or Not to Timebox (Part I)

I was never particularly interested in project management or scheduling until I read the book Agile Estimating & Planning by Mike Cohn five years ago. I'd been working in software for 20 years and scheduling seemed like a dull and tedious exercise at best. At its worst, scheduling seemed like a black art full of lies, falsehoods, and deceptions.

As a programmer interested in learning about agile, I started reading books focused on the technical side of agile software development. Most of the agile programming and software design practices made sense to me. As far as I could tell, the agile approach scheduling seemed to boil down to "only plan 2-4 weeks ahead." This seemed neither practical nor sensible. I picked up Agile Estimating & Planning to find out what the deal was. The answers I discovered were much more interesting than I expected and eventually motivated me to eventually change careers from programming to project management.

The first idea in Agile Estimating & Planning that rocked my world was planning using iterations (now more popularly  known as sprints). It was my first exposure to timebox scheduling. I was used to working with milestones in software development. It was often unclear whether milestones were defined by "date" or by a "state." Dates were set for milestones, but there was also the expectation that certain goals would be achieved. The dates were usually more clearly defined than the goals and milestones were usually months apart.
 
Timeboxed iterations immediately struck me as a great idea after seeing a lot of problems planning and scheduling programming work over the years:

• The time horizons for development could be long and work often involved a lot of uncertainty, failure, and iteration. Planning and scheduling was often done irregularly, if it all, after the initial phase of the project when the least was known and understood.
• Scheduling often took the form of getting precise estimates for a long, linear sequence of tasks. Gantt charts showing a single line tasks for individuals, each task starting on a specific day and ending on a specific day, were rarely a reflection of reality.

The timeboxed method of planning described in Agile Estimating & Planning made intuitive sense to me as an software engineer.I believe that there are many advantages:

• Regular frequency of planning. Planning and scheduling needs to be an on-going activity throughout a project. Requirements and priorities change and a lot of information is learned as development progresses. I've had problems when planning was irregular: 1) too long a period and plans and schedules are far out-of-date and people are no longer working to a plan; 2) it's annoying as a programmer when goals and priorities change out-of-the-blue on a frequent basis. There are costs associated with planning and switching tasks. They need to be considered and managed.
• A comprehensible time horizon for planning. When I'm thinking about time and programming work, I can wrap my head around a few weeks. Much longer than a month and I start waving my hands. It becomes easy to procrastinate. I've rarely seen a detailed task plan survive and be useful for more than a month.
• A focus on deliverables and not activities. The focus on planning for iterations is the delivery of useful functionality fulfilling a clearly defined definition of "done." It's not about completing activities. Ultimately, results are what matters. The activities required to meet goals are more uncertain and change more frequently than the goals themselves. I find focusing on completion of activities leads to the problem of  Parkinson's Law: Work expands so as to fill the time available for its completion..
• Commitment-driven planning. I'm a big fan of making and keeping commitments in work. [I could write a whole post about it.]  I want to be able to commit to results that are achievable. Given a fixed time horizon I can comprehend and a pile of estimated work, I can make judgment about "too much" or "too little."

As anyone who has seen my schedule diagrams, I have a much easier time picturing and working with schedules visually by using timeboxes: fitting work items of various and somewhat variable size into buckets. This has been a natural fit for how I've seen the activity of programming. I'm not usually proceeding along a linear series of steps that start on day X and end on day Y.

Other people have written about the virtues of timeboxing. As well as planning software projects, timeboxing has also been useful managing my own time using the Pomodoro Technique.

At first I thought timeboxing was "it," a general purpose solution for all of the planning and scheduling challenges I could care about. That lasted until I had to schedule game art and asset production. Next post I'll write about the limitations of timeboxing when I find a need to use a different approach.