Where does the time go?

Friday 21st October, 2016

Let’s consider a single week; the figures I’ll use came from a company I was working with recently. They had a number of developers and designers working together as an agile team, and although some of the details I’ll talk about are specific to developers, there are similar things for designers — or indeed people doing totally different types of work.

So. What is a week?

Five days Monday to Friday, 9-6 with an hour for lunch. That’s 40 hours.

40 hours to a week

If you’re really efficient, your standup is genuinely five minutes every day. If you’re honest, a lot of the time it’s 15-20 minutes, particularly if people start assembling five minutes early, and chat a bit as they leave. We were more like that.

That’s up to two hours on standups

Every iteration we had a retrospective meeting.

One hour for a retrospective every two weeks

And we spent time as a team every week doing backlog grooming, estimation and so on. (This wasn’t ideal in some respects, but the whole team wanted to be involved throughout.)

Planning always takes longer than you think it does

Hopefully everyone gets a one-to-one meeting with their manager regularly.

I can’t overstate the importance of one-to-ones

Lots of teams use github Pull Requests or something similar for code reviews. If each developer spends half an hour a day reviewing others’ work, that’s more than two hours a week.

Half an hour a day adds up quickly

If you’re unlucky, there are lots of company meetings you get sucked into. If you’re lucky, then you’re probably spending more time on code reviews. And of course some company meetings are important, so you can’t eliminate them entirely.

All-hands meetings, cross-functional update meetings, …

And there’s always other things…

20 minutes’ ping pong every day? It’s not actually that much

So that leaves us with:

27 development hours in a week

Note that quite a lot of the other thirteen hours are work as well. But here we’re thinking in terms of the time available to plan, build, test and deliver new functionality.

27 hours sounds okay, doesn’t it? But we’re not finished yet. Consider a year:

365 days in a year

Unless it’s a leap year:

366 days in a leap year, but let’s just ignore that

(Let’s pretend it isn’t.)

We don’t work weekends. Or at least, we shouldn’t work weekends. Let’s hope no one is routinely working weekends, because that’s a whole different issue.

That’s about 105 days not even in the office

In the UK we have eight days that are “statutory holidays”, like 1st May and “Boxing Day”.

It’s okay, there are still over 250 days left

If you’re in fulltime work in the UK, you get another 20 days’ holiday by law.

232 days left

People will take some sick days. (I got this number from averages for the IT sector in the UK, although it’s quite heavily contested.)

228 days left

Good companies invest in their employees, whether that’s sending them on courses, or to conferences, or just giving them the authority to learn new skills and techniques on company time. Four days is probably the least-defensible figure here, but it also isn’t completely crazy.

224 days left

Let’s make it easy on ourselves, and say:

220 workable days per year.

Okay, so with 220 workable days out of 260 weekdays per year, and with 27 “development” hours per week:

27 * 220 / 260, because we need to adjust the idealised week of 27 / 40 development hours to take account of all the time out of the office during the year.

So the average week — taking into account holidays, training, sickness and everything — contains:

23 development hours

Where did it all go? We’ve lost 17 hours per week!

6 hours out of office, 11 hours on non-development work, leaving 23 hours.

Of course, if you do the sums for your own team you might come out with very different numbers. Maybe you’ll have more development hours, or maybe less. But you aren’t going to get 40 hours per week, every week, out of every team member.

Summary

There are two points here.

Time spent doing productive work is precious, and we should work to defend it against unnecessary meetings and other interruption.
It’s important to recognise that just because someone is a developer doesn’t mean they’re going to spend all their time at a computer typing in code.

Even if you include planning meetings, standups and standing at a whiteboard in “developing”, there are other things that employees need to spend time on: things like CPD, mentoring and one-to-one meetings with their managers are an important part of their job too.