Value Stream Management - another top down approach to ROI?

Value stream management, probably most noticeably introduced as a part of the SAFe framework in nothing new. It is a simple visualization of the value creation process connected to the financial aspects. In short, it is a way to organize work based on finance and perceived value to the end user. This approach is another top-down version and as such it comes with both positive aspects and negatives. If handled correctly it can be mostly positive however.

Let us begin by setting the stage for what Value Streams actually are: artificial constructs designed to match value with cost. In a sense that is the same as a line organization that continuously create value, but with a specific value in mind that is not tied to IT structures such as systems.

This is where the first problem usually start to show itself: what is value and to whom?

If you have spent any time with Agile or Lean evangelists then you know they will talk about the end users experience as the one and only metric of importance. I find that to be a naive and narrow point of view because as a company you are in the business of making money. That means that the metrics that matters is what do we benefit from as a company. In order for the company to benefit you usually want end user satisfaction, but it is not the only metric.

There is no benefit for the company if the end user is satisfied, but the company lose money because of it.

In order to set any form of metric to measure value you need multiple perspectives and this is very difficult when you have experts that either focus on end user satisfaction or company profit. The answer is in the middle, but very few companies have the capability to bridge the gap and find that value.

Defining what value is

What happens is that value often are defined in services rather than value. Customer support for example or E-commerce. In some cases it even is split into business areas such as countries or brands. Neither is probably what constitute a value stream, but then again value streams are artificial constructs that still are very poorly defined other than "what drives value" in a typical theoretical abstract manner.

My advice for this is to define what value are you driving and how will the company benefit from it. This is something almost all companies already have as it is a part of Portfolio management. Everything that you have a budget for already have value creation as part of the metrics used to motivate the funding. The only thing you need to do is to take your portfolio and sort the items in there into recurring areas. You can do that with a simple card sorting activity because if you work with Portfolio management you probably already have this in place in a way and you just need to challenge the structure a bit.

It is worth mentioning that value streams are not organizations or departments. They are time limited artificial structures that you should treat as long term project or programs. Eventually these value streams will change, in fact you should have a process to re-evaluate value streams annually or at least bi-annually to verify that the value creation are still in line with what you expect from a value stream.

Value Streams live on top of systems

This is as true for Value Streams as it is for programs and projects. All IT organizations are system based and no matter what financial body you place above it should live above the system structure. What I mean by that is that each system should have one truth when it comes to documentation and competence. So financial bodies that touch the system will "borrow" competence from that system and they will share documentation with other financial bodies that touch that system. This prevents fragmentation of information and duplication of technical roles such as architects and test.

It is common that when you define value streams that you will define entire systems as part of that value stream. This makes sharing systems less of an issue, but you should still keep in mind that the value stream is more or less hiring that system to deliver value and that other can, and usually will, have reason to pass through that system as well.

Measuring Value. Actual value.

When you start working with the value stream you will have certain things that you measure to see how well you deliver value. If you have defined the value  correctly as suggested above, then you will get multiple points of value to combine into the actual value. This is where it is common that companies realize that they do not have the tools to actually collect the metrics. In some cases they get the metrics, but do not know how to combine them into actual value.

My advice here is to make sure that you define value the same throughout the company. Don't use arbitrary points of measurement like t-shirt size or story points because they will be useless at scale. You also need to measure cost, for real. Most companies only start to measure cost after the requirement phase, which provide a very skewed perspective as there are a lot of costs involved in defining a need.

So start measuring all aspects of the processes before the need hit the development team and you will probably be amazed about how much time is spent defining the need. Ideation, meetings, workshop, decisions, estimations, technical solution design and requirement analysis easily add up to 50-500 hours of work for even small needs. I have seen features that added only a visual effect on the side with negligible value cost well above $50.000 just in meeting costs to argue about the correct implementation.

You also need a way to translate other arbitrary measurements such as customer satisfaction into something useful. Hopefully you already have a template for this if you work with ROI from CRO, or at least you have some way to measure how an increased customer satisfaction also increase profit for the company.

When you measure actual value and not just a part of the value creation, then you usually will have very different results than if you only measure single points.

Value Streams. For real.

Like I said, value streams are nothing new and most organizations already have it based on either financial value or customer value. The trick is to combine the two into value streams that give you the real answer to the big question: what creates value for the company and how do we improve that.

Combining soft values such as feelings with hard values such as money is no easy feat however. As you dive into the esoteric and abstract world to try to combine the intangible with hard realities you should expect to fail initially. There are no magic formulas for working with value streams, which is why you should be aware that this will probably be a very expensive exercise of futility unless you truly commit to making it work.

If you commit and you find that sweet spot between measuring too much and not measuring enough, then I firmly believe you will have a big advantage compared to your competitors. If you also work with predictive activities to test theories before you commit to them, use predictive data analysis and engage with the end users to drive decisions, then you are a winner, regardless of what field your business operates in.

Just don't throw in Value Stream Management as some form of magic bullet, because it is not.

You will not be the best in the world by adding a new way of training, you still need to put in the hard work. This is true for sports and it is true for business processes as well. You do the work and you commit to it. Or you fail.

Commit, or fail.