Tuesday, June 28, 2011

What Is Work?

I've been doing an agile training session with a team, and they mentioned that (1) they didn't ever finish everything that in the iteration; (2) all stories were coding stories; and (3) they had themselves set up at 6 hours per day each of "actual working time".

Can you spot the assumptions in those statements?

Assumption 1: "actual work" is writing code. Nothing else is work, just overhead.
Assumption 2: it's possible and sustainable to write code for 6 hours per day. Each.
Assumption 3: it's not a do-able thing unless you write code

This isn't an uncommon philosophy. This team happens to be all developers, but you hear other engineers - testers or support engineers - say similar things, just substituting "testing" or "working on customer issues" for "writing code".

It's also completely wrong.

You see, we don't ship code. We ship a product.

We ship a solution to other people's problems, something that enables them to do things faster, better, stronger than before. And to do that, we have to do a lot more than write code.

All of these things - and others - are work:
  • writing code
  • going to a meeting (hello, sprint planning meeting, anyone? company all hands)
  • answering emails, even from HR about when you're going on vacation
  • composing a design proposal for that nasty scaling problem
  • walking through UI mockups with the designer
  • fixing the build system
  • reviewing - or writing - product documentation
  • reading a white paper about your competitor's implementation
  • prepping a paper to present your company's solution at a conference
  • creating a patent application (and these take a really long time!)
In short, we do a whole lot! Most of it doesn't fall into the category of "the main thing that defines my job" (writing code, or testing, or helping customers, or whatever).

So, let's look at that statement again: (1) they didn't ever finish everything that in the iteration; (2) all stories were coding stories; and (3) they had themselves set up at 6 hours per day each of "actual working time".

Well, of course they didn't finish. They were tracking one part of their job - the coding part - and assuming they'd spend 6 hours per day on it. That leaves 2 hours per day for all the other stuff, and that's simply not enough. So there are two choices: extend the day, or stop assuming so much of the day is spent on one part of the job.

Now, in agile planning, there are two things you can affect: how much total time you think you have, and the stuff you count toward that time. Some things aren't ever going to show up in agile planning: answering emails, for example. Other things are more flexible; many teams choose to make "write white paper" a story, for example. Because not everything shows up, then we have to respect that we will spend part of our time working on things that are in the sprint, and we will spend part of our time working on things that aren't in the sprint. I've seen teams that put very little in their sprint, and they ended up with about 2 hours per day per person scheduled. I've seen other teams that put almost everything in their sprint, and for them 6 hours per day per person was about right. Most teams I've worked with are at about 50%; they spend about 4 hours per day per person on tasks that are part of the sprint.

This sounds low: "What do you mean the team is working only 4 hours per day!??!" It's not really low, though. It just means that the team is doing non-sprint tasks for the rest of the day. They're still working, just not on the things that are tracked in the sprint.

Respect the totality of the work, even the work that you didn't plan for. You'll be more sustainable and more accurate because you were honest about it.

1 comment:

  1. Wow. At Thoughtworks some years ago we tracked estimated hours vs. actual hours quite closely and accurately and I don't think *any* team, no matter how advanced, ever clocked 6 real hours per day. The very best teams came close to that, but it was still 5 and a fraction.

    ReplyDelete