6 Myths of Product Development
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.






« « Do only high benefit/cost work! || Radical Management » »
2 thoughts on “6 Myths of Product Development”
Leave a Reply Cancel reply
Subscribe to this blog
Interested in a Lean-Agile-Scrum course or Workshop?
Recent Posts
Blogroll
- Agile Advice – Mishkin Berteig
- All about Agile – Kelly Waters
- Brad Appleton's ACME blog
- Brian Marick's blog
- David J. Anderson's Blog
- Esther Derby's blog
- Hal Macomber's Lean Project blog
- Henrik Kniberg's Blog
- Implementing Scrum – Mike Vizdos
- Net Objectives' Blog
- Organizational Agility – Pete Behrens
- Partnership & Possibilities – Diana Larsen
- Rachel Davies' Blog
- Scrum Log – Jeff Sutherland
- Steve Denning at Forbes
- Succeeding with Agile – Mike Cohn
- The Lean Agile Executive Blog
- Tom Peters blog
Archives
Categories
- agile
- agile business
- Agile principles
- Better Agile
- business value
- BV Engineering
- Change Management
- courses
- elements of agile style
- freedom
- Getting started
- impediments
- Innovation
- Jeff Sutherland
- Kanban
- Key problems
- knowledge creation
- leadership
- lean
- Lean Software Development
- learning
- Listings
- Little's Law
- Little's Second Law
- managing agile
- Misc
- Nokia Test
- Paying
- People issues
- Recommended reading
- Release Planning
- scaling
- Scrum
- Scrum Intro
- Scrum meetings
- Scrum roles
- ScrumButt
- ScrumButt Test
- Self-organization
- Talks
- Teams
- Uncategorized
- video
- Yogi Berra
Recent Posts
Recent Comments
- Ellen Grove on The Fuller Picture of Scrum
- Rogerio Manso - MGP, PMP on Waterfall is done. Where is the debate now?
- Joe Little on The Fuller Picture of Scrum
- Scrum VS Waterfall | How do they Compare? - Lean Agile Training on Scrum Coaching
- LPA #97 Comment identifier le Dark Scrum (et en sortir) ? - Le Podcast Agile on Dark Scrum – Some comments
Archives
- February 2019
- January 2019
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- April 2018
- March 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- September 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- September 2016
- August 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- May 2007
- April 2007
- March 2007
Categories
- agile
- agile business
- Agile principles
- Better Agile
- business value
- BV Engineering
- Change Management
- courses
- elements of agile style
- freedom
- Getting started
- impediments
- Innovation
- Jeff Sutherland
- Kanban
- Key problems
- knowledge creation
- leadership
- lean
- Lean Software Development
- learning
- Listings
- Little's Law
- Little's Second Law
- managing agile
- Misc
- Nokia Test
- Paying
- People issues
- Recommended reading
- Release Planning
- scaling
- Scrum
- Scrum Intro
- Scrum meetings
- Scrum roles
- ScrumButt
- ScrumButt Test
- Self-organization
- Talks
- Teams
- Uncategorized
- video
- Yogi Berra
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.
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