My friends and colleagues over on the SellingAgile group were discussing productivity recently. Tony and Clarke were at the heart of the discussion, it went a little like this:

Tony made an excellent post, too long to quote here, but I particularly liked this:

In the age of interaction-centric systems, it’s all about speed. Forgo the false god of utilization. Concentrate on speed and concentrate capacity, so that those valuable software products and the mountain of moola that each of them can bring might arrive today rather than tomorrow.

To which Clarke asked:

Are you saying that if everyone is busy all the time then they will actually be a slower at doing things?

To which Tony responded:

Yes, Clarke, if we ensure that we have active projects enough to guarantee that every developer has project work available, then we _CAUSE_ the whole system of resources to work at approximately half its sustainable speed. Management teams worldwide are wasting approximately half of the capacity of their development teams and, consequently, half of their development payrolls.

It became clear that some folks believed productivity is low because we’re overloaded with work.

Basically, this boils down to the fact that software developers (amongst others) rely on creativity in order to do their jobs well. Without suitable periods of “down-time”, work simply moves from one task to the next with little regard for “can this be done any better?”

Tony then went on to make this remarkable statement:

Think of multiple marathon relay races. We have one team and many marathon relay races for the team to run. If we schedule the races so that one race must end before the next race can start, then our team doesn’t get to finish very many races per day or per week or per year. So we surely want the races to overlap. But for each of our runners we absolutely do not want his/her segments across races to overlap. That would force the runner to jump from track to track and race to race without handing any baton to a downstream teammate. So, we overlap the races, but we don’t overlap any one runner’s segments across races.

Today, due to our unfortunate and grossly inadequate understanding of interaction-centric systems, we schedule the STARTS of our races far too closely to each other. This guarantees that every one of our runners is always on some one track or another, running at least one race and usually several races simultaneously. Then we require our runners to make progress simultaneously on all their active races, by failing to prioritize the races. This forces each runner to hop from track to track and from race to race repeatedly, before the baton of any one race is transferred to the next teammate. This is multitasking in all its ugliness.

Clearly multitasking is absurd in the context of relay races. But it is no less absurd in the context of product development. Yet this absurd behavior is precisely what we cause when we strive to maximize utilization. The resulting lack of performance is a tragedy of our own making.

Whilst folks think that having a steady stream of work is good, it seems that we worry about a number of things:

• that we won’t have time to complete the current task (and do it well)
• that we won’t have time to complete the next task
• this appears to be a recursive worry

So, my take on this discussion resulted in this:

1. Start something.
2. Focus on it using decent chunks of time.
3. Do it well.
4. Finish it.
5. Don’t allow yourself to be distracted by “what’s coming next”. Don’t flutter from one task to the next and back again.

Leaving an activity in an unfinished state will cause further distraction as your mind will play tricks with you, you’ll be worried about the unfinished tasks whilst you are working on current tasks. Break your tasks down into manageable chunks (task time average = 30 minutes), proceed to start each task and finish it, allow yourself some downtime (if you refer to it as slack, it’ll be consumed by the project, avoid using the word slack). Doing less work should will actually make you more productive.

Related to this:
How much pressure is required to make somebody more productive?

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making