What is a Value Stream and What's the Inherent Problem?

In May we will be delivering a Disciplined Agile Value Stream Consultant, DA VSC, training course, certified by the PMI with our partners Process Mentors. The development of this PMI course is led by Al Shalloway, and is based on his FLEX system. 

The three of us at Novavi, as well as Joshua Barnes and Glen Little at Process Mentors, and many others have been collaborating with Al for almost a year, helping him develop the material through regular weekly alpha sessions. During this time I have learned a great deal about how to apply lean principles in the context of an agile organisational transition, and want to publicly acknowledge the cohort I was with, and especially Al.

A key component of DA FLEX is to resolve, “The Inherent Problem”, which I will discuss later.

Firstly, I have to define what a value stream is, and why it is important. Here is a definition from the DA Senior Scrum Master training material:

A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages for one or more development teams (where agile methods begin), and on through final delivery and support. A value stream begins and ends with a customer.

The last sentence is the most succinct and direct component of this definition. The single most notable part is the emphasis that a value stream considers the work, not the people.

I have seen in some enterprise scaling approaches, such as Scaled Agile Framework, where the value stream has a definition which appears to be organisational rather than work based. In what some people describe as the ‘Spotify Model’ this may correlate with a Tribe.

SYSTEMS THINKING.

Russ Ackoff does a better job than I ever could in this video in explaining what systems thinking is:

Similarly it is well described in “The Fifth Discipline” by Peter Senge. Eli Goldratt also featured it strongly in his lectures. Goldratt asserted that if you optimise the part, then the whole is consequently sub-optimised. Goldratt definition of Inherent Simplicity is another element of what DA FLEX aims to achieve.

This is a key consideration in Theory of Constraints, TOC, as we need to attend to throughput through the whole system and not necessarily create local optima that cause queues further down the value stream.

THE INHERENT PROBLEM

Now that I have explained the definition of a value stream, and articulated the importance to consider the system as a whole it is worth considering The Inherent Problem which is a key concept in the DA VSC material.

If we consider an organisation that is designed traditionally, departments are separated functionally, and presented vertically. We might have Marketing and Sales, Product, Development, Delivery and Operations. This would be on top of Finance, HR, legal, IT and more. Each department would be cost centred and its GM/HOD accountable for the budgetary controls and thus setting their own strategy, budget and execution.

This necessarily means that there is a bias towards a motivation to consider optimising for that which one has accountability and in all likelihood greatest visibility. This is sub optimal for the entire company.

Pat Lencioni, in his book "The 5 Dysfunctions of a Team" explains that this can be mitigated, to a degree, by leaders considering their 'first team' as that of the Leadership Team itself, rather than the silos of their individual departments.

Returning to the definition of a value stream. The work flows left to right through each functional area. It starts and finishes with a customer. We know from TOC that throughput is important and thus any delay must be avoided. In the manufacture of physical goods this is wait times and inventory. In knowledge work it is often decisions to be made. If there are 4 items concurrently in WIP it follows that, on average, each item is waiting for 75% of the time. 

The above paragraph identifies the wastes of delay, handoff, and inventory. The likelyhood of defects increases and delay in detection is another concern. Decision delay, or decision latency, is a considerable cost and one which is present in many organisations I have been involved in. A Standish Group “Chaos Report” several years ago identified that decision latency is a significant cause of project failure.

The Inherent Problem creates decision latency. This is because while the works flows left to right in the value stream, the people are managed vertically in the organisation. This means that every time a work item is held at a stage in the value stream while a decision higher in the organisation is made it causes delay. It is by far the biggest cause of waste in technical or knowledge work.

WHAT TO DO ABOUT THIS?

So far this article has been somewhat theoretical and abstract and so I’d like to jump to a specific example of what I have done in the past to address this, to make it more practically understandable.

A few years ago, I was leading an Agile Practice at a fintech in Auckland. It was ultimately renamed Tactical Delivery and I shifted the emphasis on enabling rapid tactical decisions to increase the throughput. I was very pleased that after my time there I would hear Product Owners and Kaizen Coaches talk, frustratedly, in terms of decision latency.

Part of my role leading this practice was to review and revise the Solution Delivery Lifecycle, SDLC. This landed on my desk on my first day in the job. It was a strategic objective of the company for the year 2018 and led to an org restructure to enhance throughput and minimise handoffs.

The first thing I did in the review was to facilitate a series of Value Stream Mapping workshops to understand what the current flow of work looked like. Visualisation is crucial, you cannot manage what you can’t see. From this it was evident that there were multiple products which had unique Value Streams through the organisation. It was also obvious that there was a lot of Work in Process , WIP*, a lot of waiting, and little visibility.

WIP* As a side note, I've recently learned why there is Work in Progress and Work in Process described in the acronym WIP. I had, by habit, used Progress and assumed it was an Americanism or something with Process. The distinction is important. Sometimes work is in the Process but waiting, thus not progressing. Therefore the more accurate term is Work in Process as this also captures the avoidable, (and indeed unavoidable), wait times.

From there we started to explore where the constraints may exist. This is straight from the playbook of Goldratt, but applied in the software context. It was interesting to see the divergent understanding that people within the organisation had of the whole system , and I suspect few (if any) had an understand of the end to end flow.

The next step was to consider what we might measure.

We had to be cautious to measure the right thing and not have unintended consequences from people gaming the numbers. We ultimately settled on Cycle Time, CT, being important. This was defined as the duration from when the work first went to the backlog of a team to when it was delivered live. Unfortunately, because the company had quite a rigid 10 week delivery lifecycle (5 releases per year) the CT tended to always gravitate to that resolution, so the numbers were’t much help.

The next metric we looked at was, what I called inventory. With my manufacturing background I was acutely aware of what WIP looks like when held in a warehouse. The cost is also significant and visible. Cost of creating code is likely to be higher in many cases, but unfortunately less visible. having an appreciation of how much unfinished work we have in the system is an important metric as we might then look at strategies to try and suppress it.

I have also since read that Don Reinertsen would measure queue time, QT, rather than CT. This is because QT is a leading indicator and thus one might be able to remedy an increasing queue. CT, being a lagging indicator, identifies the problem after the fact.

HOW DOES DA FLEX ADDRESS THE INHERENT PROBLEM

Al Shalloway, in his creation of DA FLEX, understands that we need to attend to the system and optimise as a whole, make incremental changes to improve the flow in the system and to improve queue time by enabling decisions to be made at the tactical level within the value stream. 

Couple this with the work of L.David Marquet in Intent Based Leadership, it is clear that if leaders push authority to the information and assist with decisions being made closer to the work, then the decision latency will be systemically improved.

If you are interested in how we might address the Inherent Problem, optimise the entire value stream and reduce waste by decision latency, I would strongly recommend considering the DA VSC Workshops that are running worldwide.