6 Myths of Product Development

March 6, 2013

This is a very useful article in the HBR, by Stefan Thomke and Donald Reinertson.  Reinertson is well known in the lean-agile community.  It is excellent.  Go here to buy it for $6.  Well worth it.

Here are the myths or fallacies they mention:

1. High utilization of resources will improve performance.

By ‘resources’ they mean mainly people. Speed of delivery is much more important.

2. Processing work in large batches improves the economics of the development process.

Instead, small stories in small sprints gets fast feedback from business stakeholders.

3. Our development plan is great; we just need to stick to it.

For many reasons, during the course of ‘development’, the needed features will change. And other things will change.  Hence, the plan must also change.  That’s ok, or at least, that’s the nature of innovation work.

4. The sooner the project is started, the sooner it will be finished.

Reduce WIP.  Stop starting, and start finishing.

5. The more features we put into a product, the more customers will like it.

Deciding what to omit is as important as deciding what to include.

6. We will be more successful if we get it right the first time.

Demanding that teams “get it right the first time” just biases them to focus on the least-risky solutions.

***

This article is good for helping managers see what lean-agile-scrum is all about.

 

Facebooktwitterredditlinkedinmail

« « Do only high benefit/cost work! || Radical Management » »

Posted in: Better Agile, Innovation, leadership, managing agile
Tagged: Tags: , , , ,

2 thoughts on “6 Myths of Product Development”

  1. Kurt Häusler

    Hi,
    nice list. I agree with it 83%

    “4. The sooner the project is started, the sooner it will be finished.
    Reduce WIP.”

    Hi,

    this is not actually a myth. It is true.

    Also reducing WIP won’t help entire projects or products get finished sooner. It just means that individual items within the project or product can be delivered on average sooner, with all the advantages that that brings (quicker feedback, less waste, can realize value of a feature earlier).

    The more items in your product or project, the lesser the role that lead time plays in determining total project duration. Total project duration depends mostly on throughput or velocity.

    If you want to ensure that a project is finished by a certain date, then making sure you start early enough is main mechanism one should use to ensure that. Increasing throughput would be another option. Better yet would be to stop thinking about whole projects or products needing to be “finished” on certain dates, and instead talk about which features need to be delivered when.

    Reply ↓
    1. Joe Little Post author

      Hi Kurt,

      You are correct, of course.

      What they were really getting at in the article was not clear enough from the few words I quoted.

      What they meant was, having lots of WIP and getting lots of projects started and keeping very busy with no slack — all that usually means that projects will be delayed. And delay is far more important than reducing costs by maximizing ultilization.

      So, they propose: Reduce WIP (work in progress). As a kind of opposite way of thinking: Get one project done. Then start a new project. (In overly simplistic terms.)

      If you can start the $7, please have a read of the article. They explain more there. I think it is very good. And apologies that I quoted too little from the article.

      Thanks, Joe

Leave a Reply

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