The Value Stream Impedance (VSI) Metric

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

The Value Stream Impedance 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

We can look at each of the 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 amount of work in process (WIP) throughout the system.  There are different degrees of WIP. This includes:

  • # of stories opened but not completed
  • # of features started but not completed
  • # of MBIs started but not complete/li>
  • # of MBIs on the product backlog

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<?li>
  • Poor code quality increases the likelihood that a change will cause an error.
  • These errors will often require interruptions to other work

Using the Value Stream Impedance Metric

It can be argued that the VSI Metric is not a real metric because it doesn’t yield an absolute number.  However, each component of the metric has a strong correlation with the overall VSI. This does is not inconsistent with systems-thinking because the components are intertwined with each other in a strong positive loop when improvements are made and a strong negative loop when degradations are made.  For example, increase the number of items in play will have adverse affects on the other components of the metric.  This is one reason that Lean-Thinking is so useful – there are seldom tradeoffs between its core mantras.  This enables even a qualitative measure of the VSI of a system to provide a useful indicator of the challenges that will be encountered 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 recognizing that virtually all of the pioneering ideas that Net Objectives has created over the years were created to improve flow.  Typically we saw a challenge and understood the cause of the challenge was violating some Lean principle.  We would come up with different ideas and those that reduced resistance to flow virtually always resulted in improvements.

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 have listed them in the order of the seven 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, Sustainable TDD)
    • Test automation
    • Understanding proper agile design

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