One of the most misunderstood concepts in software developments is value streams for software. This is particularly true in organisations with a Failureship culture where value streams are seen as a solution to show you how to create an organisation chart for your software development teams. In software organisations with a failureship culture, parts of an organisation will be bundled together into a value stream. The value stream will normally be a rebadging of an existing organisation following a rather expensive analysis by a consultancy with no knowledge of software, lean or agile.

What is a Value Stream in Software?

A value stream is a set of processing steps that create something of value. In manufacturing where the term originates, the value stream is static. If you want to create a physical widget or a car or a space rocket, the same processing is needed to create the same thing of value. As a result it makes a huge amount of sense to organise around the value stream, to organise around the processes that create something of value to the customer, so that the delivery of value can be optimised.

There is something very very obvious about value streams… The value is in the output. The customer gets value from consuming the output produced by a value stream. That means the processes and inputs in a value stream can all be changed as long as the output that the customer needs remains unchanged or is improved. For this reason, value stream mapping should start with the output that satisfies the need of the customer and work BACKWARDS to the inputs, something that experts and consultants rarely do. In software, working backwards was summarised by Jenny Martin as “OOPSI” (Outcome -> Output -> Process -> Scenario -> Input).

There is a HUGE!, MASSIVE! GINORMOUS! difference between production of software and the production of physical goods. Everyone knows it and it has a profound impact on the concept of a value stream… but is generally ignored by thought leaders, experts and consultants. The value stream in the production of physical goods is optimised to produce the same physical thing MANY times. The value stream in the production of software only ever produces a thing ONCE! Software development never aims to produce the same thing twice or more. NEVER EVER EVER! Whereas production of physical goods optimizes the value stream to produce the same thing many times, software only ever produces a thing ONCE!

Now let me address the screams of horror from the devOps community. There are repeatable processes within software development that can be treated as value streams, deployment of software to testing and production environments, and the repetitive operations like account provisioning and daily batches. Creating new software investments and Bug fixing are NOT repetitive.

A software value stream is the group of teams that need to collaborate in order to deliver something of value to a customer and as a result generate business value for the organization. The value stream is the teams required to deliver an investment. The value stream is not a group of teams that work on the same product or system, or share the same manager within a silo.

Rather than a “Technology investment”, it should be referred to as an “Investment involving technology”. This is because investments involving technology may also include the following non-technology teams that need to be included in the value stream:

• Legal
• Compliance
• Architectural Governance board
• Customer help desk / Call center
• Support Teams
• Sales
• Marketing
• Training

Creating a value stream in software is a very simple two step process:

1. Create a list of investments involving technology.
2. For each investment, create a value stream by listing ALL of the teams needed to deliver the investment.
   • 2a Add all the obvious teams needed to deliver the investment.
   • 2b Now add all the software teams needed to deliver the investment that are outside of your department.
   • 2c Now add all the software teams needed to deliver the outside of your company.
   • 2d Now add all the support and adoption teams that are needed to deliver the investment.
   • 2e Now add all the governance and compliance teams that manage stage gates and hoops that the teams delivering the investments need to jump through.
   • 2f Now add all the non software related teams that are needed to deliver the investment including Legal, Human Resources, Sales, Marketing…
   • 2g Keep looking out for more teams needed to deliver the investment.

You will end up with a set of investments and associated value streams as shown below (each investment/value stream has its own colour):

There are a number of points that are easy to understand from the diagram:

1. The value stream is dynamic. Potentially each investment can involve a different set of teams.
2. Work should be coordinated and managed focused on the value stream, or in other words the investment.
3. An individual should be assigned the responsibility for coordinating the value stream activities to ensure they are focused on the delivery of the investment.
4. The scrum of scrums and retro of retros should be set up for the investments/value streams.
5. There is no value having a scrum of scrums for the department. A scrum of scrums for the finance department or operations departments would by definition become a status meeting as the teams are not working towards the delivery of the same investments.
6. A department focused retro of retros is valuable to agree cross team improvements, perhaps about standards around like code quality, technical debt or test automation practices.
7. Where the same two teams or even same sets of teams repeatedly appear in the same value streams (e.g. General Ledger2 & Regulatory Reporting, and Payments1 & Discounts above) it may be worth merging the two teams and splitting them into two new teams that can cover the responsibilities of the two original teams. This situation occurs because the original teams are system aligned rather than value stream aligned.

Static Value Streams as Organisational Units

Occasionally investments will always involve the same value stream. In this case it is possible to create a static value stream by using the value stream as the basis for a permanent organisational structure. If this is done, the organisation should be vigilant for changes that result in investments that need teams outside of the value stream organisation department.

Strategic and not so strategic consultancies derive huge fees from their clients for helping them with “Org Design”. As a result, consultancies without understanding of the delivery of software investments like to create organisation based on “value streams”. The consultancies are fortunate because sales driven certification schemes promote this practice in the form of “Agile Release Trains”. An agile release train is an arbitrary group of teams that are currently owned by a single department that are thrown together to coordinate their delivery, even though they are not working on delivering the same investments. The static values stream or “Agile Release Train” approach is demonstrated on the diagram below:

The diagram shows that the static value stream or “Agile Release Train” cuts across the real value stream required by the investments. It focuses the cross team coordination on the wrong teams, the coordination and planning is focused on the teams owned by the same manager rather than the teams that need to work together to deliver an investment. This means that roles are required to coordinate activity between the static value streams or “Agile release trains” and the teams do not directly collaborate in a scrum of scrums.

If you can fit the entire value stream inside an Agile release train, you are likely to be successful in your implementation. If you cannot fit the entire value stream inside the Agile Release Train, you are likely to result in a waterfall style project manager lead nightmare. This is clearly beneficial to consultancies who provide project managers to clients and have trained hundreds of thousands of consultants in practices that most agile practitioners do not consider to be agile. This is why organisations who make extensive use of consultants adopt Safe. All of the consultancies are promoting Safe because they have heavily invested in “Agile” (but actually Safe), and they normally do not have deep experience in Extreme Programming and test first automation (Specification by Example, ATDD, GivenWhenThen). The decision for the client is made easy, “We have decided to adopt Safe because all the consultancies have promoted it, we just need to choose one of trusted partners to lead the implementation”. Although this might appear to be failureship by the consultancies, it is not. When we approached the consultancies and explained we wanted to do something better, they were very helpful and supportive, agreeing not to promote Safe to anyone in our organisation. The failureship is the individuals and companies promoting Safe to the consultancies when they know it only works in certain contexts.

Value streams result in the delivery of value to customers. If your “Value Stream” is based on a system or department and it needs to work with teams outside of your “Value Stream”, then you are part of a failureship anti-pattern.