Software Value Streams are the beating hearts of Software and IT organisations—where value is produced and delivered to customers. But before explaining the basics of value streams, particularly within the context of software, we must first define what Value is as a primer for understanding how it is created in the software value stream. 

Value is a measure of how much time others are willing to spend on obtaining our offering. This is important to understand as the exchange of time (often in currency) is the most fundamental mechanism at the core of all businesses.

Time is also the most valuable currency, as it’s the only resource we cannot replenish, making value creation span infinitely.

In our daily life, we exchange our time creating value for others (work) in order to acquire things we find valuable, such as buying a car. Creating value for others to acquire enough value may take a long time or a short time depending on your ability to create value. For example, it might take years washing cars (low value) to acquire an expensive car (high value).

Value is Subjective

Value is not rational—it is driven by subjective preferences in different individuals. Some may value leisure time, whereas others might value fancy cars.

The common denominator is that the value of an offering is determined by the time others are willing to sacrifice to obtain it, not, as we would expect, determined by the time required to create the offering. This is why certain products, albeit fulfilling the same needs, are very different in price.

As described, value is abstract and often not based on rationale. For the purposes of this article, we will assume the following simple approach:

“Value is created through concerted effort producing an offering a customer is willing to spend money(time) acquiring”

This simple definition doesn’t encompass creating the right offering for a market, nor whether it’s good business. Those aspects are incorporated in most product development and innovation models, which we will dive into in later posts.

Creating value through software has been going on for as long as computers have existed, but it’s still a very young domain. Radical changes continuously challenge the industry with massive technology advances. From very limited computers 20 years ago to hand-held multipurpose devices capable of almost anything nowadays.

The rapid pace allows for fast learning, but also limits the firm body of knowledge in the domain. We have come far, but still have more to learn.

Processes around software creation are also very young. Along with technology’s continuous growth, using traditional project models to build and deliver software has been anything but successful. Many companies that may have started with a traditional project model approach are now moving on to the more recent agile methods, inspired by the agile manifesto.

While the more modern project models surely are getting traction, we always keep first and center what the preconditions and utility is of the models. Let’s dive into how we pick-and choose between the models.

Porters Generic Value Chain consist of two activity types:

Secondary activities are organisational support intended to enable the primary activities:

• Procurement – acquiring necessary goods
• Technology Development – creating technology advances leading to new and improved products
• Human Resource Management – managing staff
• Firm Structure – organisational design and structure supporting the business

Secondary activities are often anchored in staff functions, cutting across primary activities in that they are support functions, ensuring effectiveness of the value stream.

Making a Margin

While the generic value chain is quite simplistic, it’s important to understand that competitiveness is defined by what you do to create your product.

The Margin is defined by the cost of the entire value chain, compared to what the customer is willing to offer to acquire your product. While we earlier defined this as time, in all companies we are looking at this from an economical perspective.

Hence the margin is: Product Price – ΣCost to Create Value = Margin per product

Software Value Streams

Now we understand the basic concept of a value stream, we will explore this in a software context.

Software value is created in the following order: Value Assumption is converted to Implementation which is confirmed through Validation allowing for Capture of margin.

Value Assumption

While defining the product, assumptions need to be made in relation to what customers are willing to pay for a feature. This is required for determining how large an investment the value proposition can honor. But since value is subjective, uncertainty is at the forefront of the software value stream.

Fortunately, marketing methods exist for exploring the value before committing to full scale development. Furthermore, the Agile communities have pressed for creating Minimal Viable Products. These are used to test (validate) the value proposition in the market.

Implementation

Implementation is where the product is created. Often it entails technology, architectural, and design decisions. Here, development is performed and continuously verified as the product is built.

Verification is related to correctness in the product. While incorrect product behavior will damage the assumed value, it’s focused on technical correctness and not validating the product against consumer expectations.

Validation

Validation concerns ensuring the product meets the customer requirements resolving the Value Assumption. Or, said simply: Is the offering appropriate for the customers use and willingness to pay for it?

Capture

Capturing the value from the product relies on distribution and adoption of the product offered. Depending on what is being sold this may involve none to a larger degree of training or roll-out. With large scale the capturing is staggered and performed across multiple releases. Depending on the project and business model these phases will occur more or less frequently. For some companies, capture is possible on a yearly basis, whereas others continuously release new value propositions to the market.

Software Value Stream Challenges

Software creation is laborious and skill intensive work

While computers do much of the heavy lifting today, creating software is time consuming as software automation is used only to a limited extent. While there are frameworks, reuse is a significant part of software development, and recombination and new software is often developed.

Skills also impact software development a lot. Due to the vast technology landscape and endless combinations, highly skilled staff is required to build a successful business. Obtaining college or university degrees and training  often takes years, not counting continuous certification and updates throughout an employee’s work life.

The skill of staff is significant in creating a great value chain as developer efficiency may be upwards of a factor of 10 in the difference between worst and best.

Complexity of software products is high

While software products may seem simplistic on the surface they most often are quite complex in their nature. For example, using your app for tracking your running sessions is simple. You turn on the app, go for a run, and when it’s done the data is neatly packaged, cut out in graphs etc., and perhaps you receive advice on how to improve.

 For this to be possible a short list of systems required could be:

•  A smartphone with an operating system
• GPS Satellites (containing loads of software) sent into space continuously helping you determine your location, speed etc. 
• Space rockets launching said satellites into space 
• Earth infrastructure for transmitting data to data centers
• serves with OS’ and APPs for collecting, storing and computing data

Of course, many of these infrastructure elements are used for many purposes.

Software is volatile

Software is very different from tangible products, as they can (and will) evolve on all parameters through their life cycle. Much like a house once the foundation is poured and the frame is built, once core elements in software are built, it may be updated multiple times across its life span. Foundational elements such as operating systems, communication structures, etc. are rapidly evolving, requiring continued maintenance of software products.

A second factor is a change of hands on the project. As many decisions are reversible, new eyes might incur new decisions leading to significant changes in the software. For this reason, software is volatile and continuously evolving as time passes. Unfortunately old decisions and rationale will erode over time. Consequently, understanding of the software will diminish and increase the likelihood of detrimental decisions later on.

Scaling Software Development is Troublesome

Scaling software development is no easy task. The effort required to deliver large scale systems often exceeds single departments, requiring scaling project models. Earlier, we discussed the transition from more traditional project models to agile based models. The move towards agile teams focused them on full domains, but limited scope. While this works for apps and minor programs, it is a challenge when multiple teams are required to complete the product and henceforth the value chain.

One of the primary caveats is that scaling agile projects is inherently different than scaling traditional projects. Whereas scaling usually is done within disciplines, agile pushes that teams should be fully capable of making their deliveries on their own. Thus requirements towards the teams fathom all aspects of delivering the product.

Secondly, teams become interdependent, making communication and alignment efforts increase exponentially.

In the software domain there are some dominant software value stream models that are worth considering:

• IPMA/ PRINCE2
• Less.works
• SAFe
• RUP

Always remember when applying models to consider your context and challenges. Failing to may lead to poor if not disastrous implementations.

Hopefully we’ve inspired you to dive further into the concept of software value streams and how they affect your business.

Exploring your value chain and all the steps involved most likely will be challenging, but it’s a healthy exercise for everyone involved—where you explore  a value stream, you will  always unveil potential for improvements that will propel your business into a better future.

Try it out for yourself and feel free to ask questions and share your story and views on value streams in the comments section below.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach