Value Stream Impedance

December 15, 2013 — Posted by Al Shalloway

This blog has been replaced by Introducing the Value Stream Impedance Metric.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Is this identical to what Grady Booch used to call "Software Development Friction"? or is it only similar?

I have to think there is a principle or three from Reinertsen's "Principles of Product Development Flow" that directly lead us to identify VSI (and probably give some insights on how to quantify it).

Brad

thanks for the question, but asking to have conversations on one of the user groups listed.

http://groups.yahoo.com/neo/groups/leanagile/conversations/messages/7601

You have an interesting perspective on this, but it is not new to try to quantify it. For example, the COCOMO II estimating model quantifies various factors as having an impact on the time that a project will take. These numbers were based on research and they have value, even if our current project teams operate differently than in the past.

For example, there is an adjustment factor for "Applications (Business Area) Experience", which is 1.51 for a project size of 100K lines, which I think means that you could multiply your estimates by 1.51 in that scenario. Even if you don't use the number directly for that purpose, it still identifies this as a known factor with the potential to increase the impedance.

A more practical example is "develop for re-use". When instructed to work this way, it can add up to 24% to the project. I'm quite familiar with that particular impact in my development work!

(I'm not particularly knowledgeable about the COCOMO model - my info comes from Steve McConnell "Software Estimating - Demystifying the Black Art" book).

I am not estimating how long something will take to develop.  I am talking about how the system within which things will be developed will aid or hurt the development efforts.  COCOMO focused on the work entering the system - that is a way of estimating how long the work would take based on the work to be done.  I am talking about how the system effects the effort of work to be done.  Strategies can be used to lower the VSI of a system.

In this way I would suggest what I am saying is somewhat new.  I believe our bad estimating practices are not due to the fact that we can't estimate well, but due to the fact that our systems often have huge resistance to getting work done efficiently.

 

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban