This is the first of a two part blog. This one will define a new term, one that we are all familiar with, even if it’s never been explicitly defined before. The other will describe how to use it.
As a systems thinker I am always looking to the system within which work takes place to se its impact on the work. We have all seen the affect systems have on people. Systems include the physical arrangement of folks as well as the workflow within that. For example, non-co-located people don't work as effectively as co-located folks do in software development. Furthermore, separating who coders and testers report too has a deleterious affect. These systems effects can be dramatic. Unfortunately, we don't often attend to them as much as we should.
Value stream impedance is a quantitative measure of the resistance work in a value stream faces due to the organizational structure of the people doing the work. The contention is that the more impedance, the more extra work that is created. This is not a new concept. It is well established that work being coded in one location and tested in another takes more time. Bugs are found late and the costs to fix them therefore 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 included waste. It’s not a coincidence that the value stream impedance (VSI) of a properly formed and functioning Scrum team can approach 0.
While creating a Scrum team which has a low VSI is not difficult in small organizations, it is not easy to do so in large ones. Even when Scrum teams are present, where they are located and how they interact with each other can create a large VSI.
Calculating Value Stream Impedance (VSI)
All change agents attempting to achieve Agile at scale have some intuitive method for determining whether a change will result in improvement. Three seem to be three primary approaches. The first assumes that their approach is best and that anything that takes you closer to it is a good idea. Scrum takes this attitude. Transition occurs by removing impediments teams face using the structure demanded by Scrum (co-located, cross-functional, self-organizing teams). The Kanban method takes the opposite extreme. Don't change anything at first. Instead, establish a method of analyzing the efficiency of your value stream by establishing both visibility and work in process (WIP) limits. Then, make improvements to the workflow by managing WIP. A little reflection lets us see that Scrum ignores managing WIP explicitly within the sprint while the Kanban Method ignores team structures. The third approach...
Clearly co-location, cross-functional teams, people reporting to the same manager, and working on fewer projects will improve the system within which people work. The VSI is an attempt to quantify things. I doubt that at this early stage in the definition of the VSI one can create a very accurate VSI, but in the attempt at doing so we are making explicit our intuition. In my opinion, all too many Agilists ascribe the reasons for success to the wrong thing, with many not even appreciating the affect that systems have on the work taking place.
The intention of quantifying one’s VSI is to have a discussion point about whether a change will be advisable or not. One should never just do a change due to a lower VSI being achieved. And after a change is made, some measure should validate that it was a good move (a shortened cycle time for example). However, the quantification of the VSI is a means to have people talk about what makes it less efficient to do work. I believe it is possible to create a reasonably accurate VSI metric. I am proposing the following as a start – something that must be refined as we use this more.
Here are some things that contribute to VSI:
Structure of people doing the work:
- non-colocated teams (the further apart the teams the more the impedance)
- long feedback cycles (longer the feedback, more the impedance)
- separate code and test organizations (off-shored test organizations seriously raise VSI)
- steps in the workflow that jump between different organizations
Practices that raise VSI:
- multiple stakeholders telling the team what to do
- people working on multiple projects
- working on large batches of work
Practices that can lower VSI:
- having minimal business increments (MBIs) in your development input queue
- version control
- continuous integration
- automated testing
- test-first
- managing WIP
- having cross-functional teams
- using explicit policies
- shared product backlogs
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 SAFe, please see the thread on the Lean-Agile Yahoo group. I will likely not respond to questions here as I would like to have more of a community discussion.
See the following blog (may be a few days until it is posted) that discusses how the VSI can be used.
Al Shalloway
CEO, Net Objectives
