Economies of ( scope | scale | flow ) for Software Development

I was posed this question over email with regards to my recent Intro to Lean Software Development talk:

I like the slides a lot. I did have a few questions. I was wondering if you could say a bit more about what you mean by “economies of scope”. I recall reading Mary Poppendieck’s “Leading Lean Sw Dev” book and the part where she spoke of economies of *flow* over economies of scale, but I hadnt seen the term economies of “scope” and wanted to know more about what it means and the difference between economy of flow and economy of scope, especially as it relates to managing software complexity and reducing the economic impact of variability.

I typed out a long reply to this person and figured it would make a good post, since others might have the same question. Here’s my abbreviated email response:

When Mary was talking about scale vs flow, she was referring to the push vs. pull mindset for actual production development & task distribution. So instead of throwing 100 tasks at your team, regardless of capacity, economies of flow says to ‘pull’ tasks as capacity frees up.

When I was referring to scale vs. scope, I was referring to the concept of product development and the differences between traditional manufacturing and knowledge based product creation like software development. Economics of scale is when the total cost per-product (TCPP) is driven down the more of something you produce. For example, the more screws I can produce, the cheaper each screw gets to produce via various bulk discounts. In this regard, you want to reduce variability, since variability will probably result in scrapped work ( screws too long, not cut right, etc… ) or delays. It’s in my best interest to produce as much as a I can to get those benefits.

Economies of scope occurs when you can drive down the TCPP the more types of products you can produce. This would come from the modularity supported by the products. Think of a car manufacturer relying on a single chassis as the base for several product lines. This is really evident in software, where a single entity can either be reused or configured to create a new product or as the basis of a new product ( i.e. a framework, library, etc… ).

As you can imagine, harnessing economies of scope for software teams has a huge upside. There’s a lot of value ( monetary & otherwise ) in the variability that can be supported inherently by software.

That’s where lean software development diverges from other traditional lean based product development & manufacturing. You can’t just eliminate complexity and variability, because frequently, that’s where a lot of the value comes from. You want to manage that complexity and make sure that the economic impact derived from developing, supporting and maintaining it is justified.