Calendar scheduling versus to-do scheduling. “Clock time” versus “event time”.

David Allen (the Getting Things Done guy) discusses lists versus calendars in his latest email/blog post.

This relates to a point raised in a book I’ve just finished reading  Wait: The Art and Science of Delay by Frank Partnoy.

Calendar time, “clock time”, is a relatively recent development in the history of humanity.  Trying to fit our tasks into scheduled time is always a problem, as we’ll never know if we’ve scheduled the right amount of time until we’ve completed the task.  Partnoy argues that getting work done by scheduling with clock time is all about efficiency, the desire to use every second in an approved manner.  This idea came about thanks to Taylorism, still a huge influence on management and project thinking.  Clock time is derived, Partnoy tell us, from Babylonian mathematics being in base 60 and the lunar month occurring twelve times in a solar cycle.  it has nothing to do with governing our schedule in reality other than marking how much time has passed.  Using clock time to organize our list of things to do seems odd when we realize this.  We could just as easily have ten hours in a day as twenty four.  If the moon was slightly different in size, we might have fifteen months in the year.  Using clock time is obvious, as it’s there, but it has no inherent ability to actually define our real world obligations.

Contrast this with “event time”.  Event time is, for example, “after lunch” or “when I’ve finished this”, or “tomorrow evening at sunset”, or “when Bill comes to visit next”.  Or “when I’ve finished this” I say again!

GTD’s approach recovers a focus on event time with the concept of “next actions”.  For each project – something that requires more than one step to complete – you determine the next action.  Once you’ve determined your list of next actions, you do them.  You fit them into you day around actions that have to be taken at specific times, such as meetings.

This is also a concept addressed in an agile approach.  We handle “clock time” in Scrum sprints or by measuring Kanban cycle time.  We acknowledge the inability to know ahead of time exactly home much clock time we need for a specific task using a variety of techniques.  Size-based estimation, team-based capacity that averages individual capacity, velocity, limiting WIP, all speak to this.

And then we do the work using event time.  When this is “done done” we’ll move onto the next thing.

Anyhow, once again, it turns out that social history proves to be a great source for understanding and improving our methodologies.  As one of my coaches says “Read.  You won’t live long enough to get it all unless you read!”  Indeed.