6 Myths of Product Development – Take 2

Months ago, I mentioned here a great article. It is the article titled: Six Myths of Product Development, by Stefan Thomke and Donald Reinertsen.  From the Harvard Business Review.  These are mostly lean product development ideas.

Strongly recommended.  Especially good for managers and executives.

Here are the fallacies or myths it mentions in one list:

• High utilization of resources will improve performance.
• Processing the work in large batches improves he economics of the process.
• Our plan is great; we just need to stick to it.
• The sooner the project is started, the sooner it will be finished.
• The more features we put into a product, the more customers will like it.
• We will be more successful if we get it right the first time.

I wanted to discuss them some, with the hope that I might entice you to read, understand, and act on the article.

Let’s do the first two today.  Quickly.

1. High utilization – Myth

Ok, ceteris paribus (other things being equal) high utilization of the resources would be good.  Lower cost per widget.

But in knowledge work especially, we only deceive ourselves. First, it is often based on the false premise that knowledge workers are fundamentally lazy.

Demoralized, demotivated — maybe.  But not lazy.  (Ok, maybe 1 in 30 has some real laziness, but we do not recommend ‘pushing’ on high utilization to get that fixed. Fix it another way, and we do in Scrum.)

Second, high utilization, as shown in the article, leads to low through-put from the system (to us, the system is mainly the Team).  Nothing gets delivered quickly.

And in product development (eg, software development) fast delivery is ESSENTIAL. Well, it is much much more essential and critical than my capital letters imply.  We barely have a glimpse, in my opinion, of how critical it is.  And in how many ways it is critical.

Once we recognize that, then we must struggle with seeing the utilization level, and adjusting it to the optimum level. (We are not proposing super-low utilization. Just lower than we usually have, to enable faster through-put.)  We have some rough techniques for that in basic Scrum. As you become professional in using those techniques, you may want to fine-tune the techniques for each team.

Again, the old pushing for high utilization by some managers is killing us. Managers should focus on speedy delivery of smaller things (smaller releases).

2. Large batches – Myth

It often feels as if we become more efficient with large batches. And, it is partly true in a way.

But it is mostly false, and in all the important ways.

Large batches tend to lead to silos. That means we tend not to work together as a team (in all the bad ways we mean with that phrase).

Large batches means that problems are hidden. And hidden problems are much harder to fix. And, in knowledge work, the bad news does not get better with age.

Large batches means that things are not delivered quickly to the customer.  And speedy delivery to the customer is essential.

Large batches allows our knowledge a much greater opportunity to decay in value. In all the many different ways it can decay in value. Often to zero.

I have to mention the ‘carrying costs’ of large batches.  It leads to much more ‘inventory’ or ‘work-in-process’ (WIP).  If you could see or visualize the cost of that ‘partially done work’ and you were a good manufacturing manager, you would be aghast at all the excess cost.

And our work is done by very expensive people.  The accumulated costs are huge.

So, while it seems (and is a bit) more efficient in some ways to have large batches, in net the costs are higher. And the ‘time to market’ much slower.  A lose-lose.

***

There are two short commentaries on the great article. Please read it.

 

« « Question: How do I implement Scrum? || Question: The Basics of Agile Contracts » »