Throughput or Productivity?

I’m tech-editing an article for the Agile Journal. I’m having a discussion with the author about the words “productivity” and “throughput.”

I believe that what we measure in agile teams is throughput, the number of features through the team over time. I don’t think we measure productivity, the number of features per person or per team over time.

In kanban, it’s quite clear. We measure throughput. To me, it’s clear in iterations, too. We measure throughput.

The author likes the word “productivity.” I don’t :-) And, the author is a smart cookie. We’re still in tech-edit, and we have more to do, and the author will win, when push comes to shove.

It’s a very subtle distinction. What do you think? Throughput or productivity? Productivity or throughput? Which one?

20 Comments

  1. Productivity is too easy to confuse with activity. I prefer the connotations of throughput, even if I don’t have the expertise to back up that personal preference.

    Reply
  2. It’s a bit of a red herring question isn’t it? I mean, surely throughput and productivity are both (poor) proxies for effectiveness? A better question might be: “how do we measure effectiveness?”. And more acutely, “how do we measure the effectiveness of the WHOLE system?”. Measuring just one part (dev) of the whole system smacks of local optimisation and Analytic thinking.

    – Bob

    Reply
  3. I think a question to think about is:
    What is the difference between the 2 words?

    for me “throughput” does not necessary mean it is finished.
    when something is produced, it is. In that sense I am for productivity.

    I do agree with you that productivity has a large connotation for most people.

    And then I think the famous Weinberg phrase:
    if you don’t have 3 options, you have not thought hard enough.

    ;-)
    y

    Reply
  4. Depends on how you define productivity, Johanna! I remember a part in the business novel “The Goal” by E.Goldratt where Jonah asks (sort of) this: “Alex, what is productivity? Are your robots productive?”. Alex thinks about it because he claimed previously that robots had been deployed in their plant in order to increase productivity. Together, Jonah and Alex find out that productivity is something that brings the company closer to its goal: making money. The robots were not productive because they manufactured a lot of stuff that could not immediately be sold (inventory). This did not bring the factory any closer to its goal but even pushed it away from it.

    Does this help your author to make a difference between throughput and productivity, Johanna?

    Reply
  5. I do not think this can be called productivity.
    Productivity to me is something that is measured *against* something, to have a (if possible a unit-independant) ratio in the end that values something. (productivity for instance; story points measured per person/team/time etc)
    It looks like the confusion starts when we’re talking about time. Because throughput and productivity gives then the same calulation.

    Throughput looks more like an absolute value, although it’s often presented per agreed unit of fixed time.

    hth, Johan

    Reply
  6. I happen to think “productivity” is a loaded term that means many different things to people. I think of it as a rate of production (what the system produces over time – that could also be divided into chunks of person or team if necessary), so if your author can be clear about their meaning, it can probably work.

    If this is in a system where the features that get developed are really those that the larger system needs, then you start to deal with some of the local optimization problems that Bob Marshall mentions.

    This is why Theory of Constraints defines “throughput” differently. In Theory of Constraints, it isn’t Throughput until it has been sold. The thinking being that if you make a lot of widgets (or complete a lot of stories) but they just sit in a warehouse (are never built into a product that your customers buy), then it was a wasted effort. Make stuff that customers want – that they want now.

    Reply
  7. At least in my experience, there are differences in connotation, and some people never get past that.

    Throughput has a whole-system, X-per-calendar-time connotation. As Goldratt ToC expresses so clearly, Throughput is where the Money is.

    Productivity has a system-component, X-per-hour-of-effort connotation. As Goldratt’s “The Goal” tells it, Productivity is where the Management is, and this is often unfortunate, especially when the system is organized by function. You’ve maximized production productivity and earned your bonus, but the firm’s going broke because we can’t sell it or can’t ship it. Along with the love of money, local optimization is the root of all sorts of evil.

    I’d go with Throughput, because Productivity has that local-optimization connotation, at least in my circles. But that really depends on your audience.

    So you can use either, provided you’re careful about definitions. What is the denominator, effort or calendar time? Are we considering the whole system or a part?

    Reply
  8. I prefer ‘throughput’ because, right or wrong, it can be measured.

    Reply
  9. When you say throughput / person, do you mean each person’s individual contribution? That sounds like a terrible thing to measure. If you measure how much I personally produce, then I will stop helping my teammates. Focusing on individual contribution only makes sense in a simple system, in a complex one, the whole is not equal to the sum of it’s parts.

    Also, you say that Kanban measures throughput, and while it does, it’s focus is on cycle time. This makes sense to me, because throughput & productivity are too easy to game. They depend on the size of the X being measured. Which depends on the estimation done by the team. Which is the team being measured… Again and again, I’ve seen the pattern of increased focus on velocity (throughput) -> more time spent (wasted) on estimation -> inflated estimates.

    Reply
    • Jeremy, no, not each person’s contribution, the team’s contribution. Sorry if I did not make that clear.

      Reply
  10. I’ll share three quotes with you, with which you are probably already familar:

    “In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software, or reducing the development time, but I seldom find a manager obsessed with improving quality.” – Gerald M. Weinberg, “Quality Software Management Volume 1: Systems Thinking”

    “Concentrate on quality and productivity will take care of itself.” – W. Edwards Deming

    “Quality is the ally of schedule and cost, not their adversary. If we have to sacrifice quality to meet schedule, it is because we are doing the job wrong from the very beginning.” – James A. Ward, “SHAPE Forum,” 2003

    Productivity measures output per some input, usually units of labor. If we concentrate on this, as Goldratt has pointed out, we are often optimizing the wrong things. You have stated this several times previously.

    I think you are clear when you say that throughout is measured by implemented features. Too much wordsmithing can get everyone confused. Stick with your definition of throughput.

    Reply
  11. Symantics arguments like this are often the challenge of transitioning to the agile mindset – yes the mindset. I think that folks that practice traditional PM are seeing the common sense light that delivering in shorter cycles and keep the business engaged throughout delivery works well. That being said, I still see mid-level managers wanting to command and control. Theses folks will often ask me how do we increase productivity – I say you don’t, you increase value.

    Reply
  12. I’m going to go against the trend in comments and offer “I like both”.

    I think we measure Throughput (in features) and calculate productivity. I’ll tend to express productivity in terms of $ per feature calculated off throughput and team run rate ($). This works regardless of choices with regard to Scrum vs. Kanban, and in my experience provides a balanced view of effectiveness. As with any metric, adding a target will lead to it being gamed, and team-estimated sizing is the first thing you’ll see gamed.

    Reply
  13. Throughput is by far the real measure as productivity can be misleading, especially depending on how you measure it. e.g A software developer in a iteration less Kanban environment is finishing 10 units of coding and unit tests every week which are further sent to integration testing. Now if productivity is measured by activities of what he does, coding, unit testing etc, it could come out as he is highly productive. However if the items he is delivering are getting stuck in testing, his throughput is low. Ofcourse if you will measure productivity as well on the test pass only, then productivity and throughput will become synonymous.

    Reply
    • Hrishikesh, it’s really about throughput by the team, too, not by the person.

      Reply
  14. Throughput means units per time period. In this case the number of words per day(for example).
    Throughput = time period / input

    Productivity is related to input and cost of final product. Productivity is high if the outcome costs more with the same input. OR if the output costs the same with smaller input.
    Productivity = Cost of final product / input

    Even though the throughput is high, productivity might still be low and vice versa.

    Reply
    • Hi Kaido, you are correct.

      So in software, we care about throughput, right? Because that means we get features through the system. We don’t care about the productivity of any single person. Productivity doesn’t matter. Throughput matters.

      I think you and I are agreeing :-)

      Reply
  15. Throughput is independent of quality, or effectiveness. Throughput is simple to measure.
    If you make statements of productivity or productivity gains, you should also measure quality, pricing, effectiveness.

    Reply
    • Hi Eugene, I agree that throughput is independent of quality or effectiveness. I’m not so sure it’s simple to measure, though.

      If you have a small story, that’s just one piece of a large epic, that’s one piece of the puzzle. You finish that. That’s your throughput.

      If you waited to finish the entire epic, you would do yourself a disservice. Why? because your throughput is lower, although your feature size is larger.

      It’s so hard to measure quality, pricing, and effectiveness, I don’t even know where to start. I can measure the cost to fix a defect. I can measure escape rate. (I’ve written articles about these.) I have not written about pricing. I don’t know where to start with effectiveness.

      This whole thing is still a conundrum to me.

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>