Introducing the Value Stream Impedance Metric

December 21, 2013 — Posted by Al Shalloway

Note: This is an updated version of the original “Value Stream Impedance” blog.

This is the first of a two part blog.  This one will define a new term – the Value Stream Impedance.  While the term is new, the concept is one many of us are familiar with.  The other blog will describe how to use it.

Systems thinking tells us that most of the errors people make are due to the system instead of the individuals.  That is, good people make mistakes significantly more often in bad systems than they do in good systems. For examples, testers who are located away from the development group that are given their work in big batches will not do as good a job testing as testers embedded with the development group. This does not mean that people aren’t important. It actually means just the opposite – because people are important we don’t want to waste their time in bad systems and we need them to improve their current systems. 

The approach therefore needs to be:

  1. Identify the challenges of your current system
  2. Understand why they are there
  3. Learn how to improve the system

The value stream impedance (VSI) is a quantitative measure of the resistance work in a value stream faces. This resistance is due to several factors.  These include how work to be done is selected, sized and sequenced, the organizational structure of the people doing the work and the way the people do the work.  The contention is that the more impedance, the more extra work that is created.  The key word here is extra.  In other words, not only does the system slow us down, it creates additional, unneeded, work to be done as well.  Examples of this is the thrashing that often takes place when software developed by different teams are integrated.

VSI is not a new concept.  It is well established that work being coded in one location and tested in another takes more time to complete.  Bugs are found late and the costs to fix them literally  go up. The challenge in this situation is that the work does not flow well within the structure of the organization set up to do the work.  On the other hand, a co-located, cross-functional team (e.g., proper Scrum team) has a very low impedance.  I’ve long claimed that Scrum works because its organizational structure allows for work to be accomplished with little added waste. 

Components of the Value Stream Impedance Measure

The Value Stream Impedance (VSI) measure is an attempt to quantify the challenges of a current value stream. There are several components to this overall measure.  These are:

  1. The number and size of the work in the development teams input queue
  2. How teams are organized
  3. How people are both geographically organized as well as who they report to
  4. The sequence that the work is done in
  5. The work-level inside system
  6. The degree of automation within system
  7. The length of feedback loops for verifying assumptions and actions made
  8. The amount of technical debt

VSI is an attempt at an holistic method.  One that can be used to guide Scrum teams, improve attempts to do Agile at scale, and caution those following the Kanban Method to not be overly myopic with it.

When Scrum teams are properly formed and manage their work properly, it is easy to see that the VSI for the value stream (at least that part within the Scrum team is very low).  At the same time, because the VSI refers to the entire value stream, not just that part within the Scrum team, the VSI concept reminds us that merely looking at the team scope of the value stream is incomplete.  Many Scrum evangelists forget this and assume the dynamics present in Scrum within a team are the same as those dynamics across Scrum teams.  The fact that they are not has led to many failed attempts to Scale Scrum. Companies start with great teams but can’t get them to collaborate well due to the high VSI between the teams.

Calculating Value Stream Impedance (VSI)

We can look at each of the seven factors that affect VSI provided earlier and attempt to quantify them to some extent:

The number and size of the work in the development teams input queue adds to the VSI the more there is:

  • Unprioritized work
  • Large batches of work
  • More work than the development group can handle

How teams are organized will increase the VSI if:

  • Teams need to integrate after developing their work
  • Feedback on the quality of the full system implementation is delayed

How people are both geographically organized as well as who they report to will increase the VSI if:

  • The teams are not co-located (the more geographically distributed the more the impedance
  • Different roles report to different managers who manage them separate from each other (that is, the organization is highly siloed)

The sequence that the work is done in adds to the VSI if requirements, analysis, design, code and test are done as separate steps.  The larger amount of work done at each step will increase this due to slower feedback.

The less automation of tests, integration and deployment the greater the VSI because:

  • Regression testing will be slowed, making it more likely larger batches will be worked on thereby increasing delays to feedback
  • The time taken to do manual testing could have been used for more useful purposes
  • Manual testing is prone to be error-prone as well as incomplete
  • More manual efforts on integration and deployment means they will happen less often, thereby increasing the time to achieve feedback.

As the length of feedback loops for verifying assumptions and actions made increase, so will the VSI.  This happens because:

  • Long feedback loops increase the likelihood that the wrong things are created
  • Fixing bugs takes longer than would happen with quick feedback loops

As your technical debt increases, so will your impedance.  This happens because:

  • Unclear code requires additional time to figure out how to change it
  • Poor code quality increases the likelihood that a change will cause an error.  These errors will often require interruptions to other work

Improving Your Value Stream Impedance

We can improve our value stream impedance by taking steps to reduce those structures, management, workflows and anything else that contributes to them.  The following is a list of actions to take that can almost always lower VSIs..  I’ve listed them in the order of the 7 categories previously listed:

Size, priority and amount of work:

  • Use Minimum Business Increments (MBIs) to size the work.
  • Sequence the work in the order of their importance. 
  • Limit the input queue to match the work capacity as overloading the input wastes time

Remember, “Often reducing batch size is all it takes to bring a system back into control" - Eli Goldratt, creator of Theory of Constraints.

How teams are organized,  geographically located and who they report to:

  • Create cross-functional, co-located teams
  • Teams need the skills to design, build and test user facing functionality
  • If you cannot create cross-functional teams, have teams that work together pull from a single backlog so as to be working on related items at the right time.  See Coordinating Teams with  Backlog Management for more information.

The Sequence the Work Is Done in:

  • Use test-first methods.  In particular, start with acceptance test-driven development (ATDD) and then add test-driven development
  • Have developers and testers work together to build and validate what is built

Work Level Inside the team:

Increasing the following will decrease the VSI within the system:

  • Automated testing
  • Automated integration testing
  • Automated deployment

Pay down your technical debt through:

  • Test-first methods (ATDD, TDD)
  • Test automation
  • Understanding proper agile design

All of the above will quicken feedback loops which will lower the amount of induced work.

The VSI of a system can provide a useful indicator of the challenges we will counter in a value stream.  Understanding what causes a high VSI enables us to take corrective action to lower it.

The initial ideas of the VSI grew out of the realization that many of the pioneering ideas that Net Objectives has created over the years consistently contributed to our clients. These methods have been combined into a breakthrough course The Multiple Scrum Team Workshop.  If you are having troubles with Scrum , or are having success with Scrum at the team level, but can’t get an entire value stream to adopt it well, drop me a line.

Because this blog is a work in process.  I am requesting feedback in one of two places.  If you are interested in how to apply these insights to the Scaled Agile Framework, please see the thread relating to this blog the SAFe linked in group. If you are not interested in SAFeTM, please see the thread on the Net Objectives Support Group (LinkedIn). I will likely not respond to questions here as I would like to have more of a community discussion.

Al Shalloway
CEO, Net Objectives

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.


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