Value Stream Mapping – why it matters and what best practice looks like

Value stream mapping is fast emerging as a successful technique for maximising efficiency and reducing the waste within the modern software development lifecycle, particularly in Agile and DevOps environments. Here we will take a look at what value streams and value stream mapping are, why they matter, and suggests some steps towards successful implementation.

Most organisations want to move towards faster and more agile development and to deliver continuous value internally and externally. Identifying what activities will deliver the best value and reduce wasted effort plays a major part in achieving those goals. It matters because many teams spend a lot of time on actions that do not have the same beneficial impact as others.

I’ve personally seen organisations waste 15-20% of development effort. Some might be more. Some might be less. Some may have no idea because this waste is hard to quantify.

As part of DevOps, Agile, and the evolution of the modern software development lifecycle (SDLC), this is why value streams — and value stream mapping — are hot topics right now. It is well known that DevOps is a complex process that requires structure, visibility, and orchestration if everything is to flow smoothly and continuously.

Based on the SAFe Agile Framework, value streams have been defined as representing “the series of steps that an organisation uses to build solutions that provide a continuous flow of value to a customer”. So far, so good, but mapping those value streams in relation to each other and their impact is hard, but important work.

Understanding value stream mapping

Value streams vary. Some are more efficient than others. Some are manual while others are automated. Some are necessary and others are hard to justify against business outcomes. So, identifying the ‘right’ value streams, (those that address customer pain points, for example), planning around them, and building continued value around them via well-managed release trains, is going to contribute towards a successful, on-time, and relevant project.

However, that depends on building value stream maps (VSMs) to ensure scaled and synchronised product development builds on top of each stream with high velocity and quality. The potential benefits are reduced lead time, faster releases, and continuous improvement of software release trains, ensuring that the identified value streams meet the delivery date expected by the customer.

The theory is fairly straightforward, but what does it look like in practice? I agree with Mike Jones, delivery lead and scrum master at AGL Energy, who has previously cited the importance of the conversations that are held when VSMs are being created. These conversations promote useful interaction among all stakeholders. This should eventually lead to building the right software and reducing risk and waste from the overall SDLC process. These conversations usually — and should — involve conversations from all the feature teams and their managers and typically take the form of a workshop.

After this initial session, a visualisation of the entire software development is usually created, from A to Z. This will help expose areas of waste or inaccuracies in critical activities. It also helps identify delays, constraints, and duplication of efforts. It also provides visibility into the entire tool stack used in the process, which can benefit the entire team.

A great VSM workshop’s output should be able to show the team everything in a very clear way, such as backlog sizes per team, manual versus automated activities and their dependencies, new versus legacy components within the process, utilisation of the tool stack, time estimates per feature team, or functionality. Ultimately, this can contribute to a more efficient SDLC.

TIMWOOD

In the DevOps lexicon, there is a name for the pitfalls that cause wasted time and slow down release trains: TIMWOOD. Each of the seen letters of TIMWOOD stands for a type of waste caused either by a tactical or a strategic inefficiency. In most cases, tactical wastes can – and should – be solved within the feature teams, while strategic inefficiencies are more complex and require cross-team collaboration to resolve.

There is a lot of information available online, together with process-based tools, that can be used to help handle the tactical waste VSMs identify.

Here are each of the seven wastes identified by TIMWOOD:

Transfer or handoff between teams (strategic)
Inventory — backlog of any partially-done work (shelved requirements, code, documentation) (strategic)
Motion — task switching, interruptions, distractions within a process (tactical)
Waiting — mostly for approval or decision making (strategic)
Over-Processing — re-learning, forgotten knowledge, legacy and undocumented code (Ttctical)
Over-Production — creation of more features than needed (strategic)
Defects/Rework — quality issues during the process (tactical).

For dealing with the tactical waste VSM identifies, there is a lot of information online. There are also many process-based tools to handle the tactical waste. For strategic waste, having the main stakeholders in the same room when creating the VSM is a good opportunity to float and address issues such as approval processes, tool stack matching, resources, legacy code maintenance, and re-use.

VSM at scale

As is the case across so many software environments today, success at team-level is one thing. Achieving it at scale, in large or highly-complex situations, is quite another. Some of the steps are the same as those already mentioned, while there are some additional recommendations for VSMs at larger scale.

For example, it’s important to follow the processes already mentioned: identify the counterparts, software tools, potential wastes, key high-value features to be developed, overall software architecture (Monolith vs. Microservices), legacy code re-use, source control management for the project, plus other technical tactical and strategic considerations.

Running a VSM workshop with all of the teams and managers would be required as a kickoff to the project, and the outcome as shown above would be an end-to-end VSM that visualises everything regarding the project lifecycle, time estimates, and more. In addition, creating a solid plan with metrics is highly recommended. Such plans would look at the current, target and future, desired state of the project.

As the project grows, cross-team collaboration and visibility into how teams are making progress, compared to the initial timeline and plan, becomes a must. Project waste across the teams also needs to be examined, monitored, and improved, either through tooling or processes.

Furthermore, large projects create huge amounts of artifacts and resources, hence the right tool stack — one that can require a lot of different file or asset types — is essential. The stack should cover software configuration management (or version control), data management, tests, staging and production, databases, backups, service virtualisation, API management, and more.

Using Kanban boards to act on VSM

Once what needs to be done has been defined with the help of a VSM, and the resulting tasks are visualised and agreed upon, next up is tracking, managing, and fine-tuning progress of those tasks. While not the only way to do this, Kanban boards are a good fit and are already familiar to many development teams. They often find these boards make it easier to track the entire work landscape both daily and on-demand, as well as to break tasks into digestible components.

Kanban boards can be a lighthouse for DevOps teams to see how resources are being utilised and how they compare to end goals and time schedules. In other words, Kanban boards are great for pinpointing the two extremes of continuous-value delivery and waste. Teams can then address any problems or make changes as early as possible.

Yet again, correct execution is everything. Steps towards creating effective and accurate Kanban boards include:

Basing the board on the simple and common task stages: ‘to do’, ‘work in progress’, and ‘done’.
Include only important and agreed-upon tasks.
Don’t include too far away, detached, and not-agreed-on tasks.
Set work-in-progress limits to not overwhelm your team members.
Continuously review and correct the board through data cards.
Clearly prioritise the work items according to business objectives and continuously align the priorities.

Value stream mapping has huge potential to help software teams make their work more streamlined, keep it on track, reduce wasted effort, and in general, engender a more collaborative and transparent working environment, which after all is all integral to good Agile and DevOps.

The beauty of VSM is that it is an elegant and relatively simple concept — one that has clearly defined steps and components with an increasing wealth of information and best practice available. All of this contributes to a powerful argument why organisations of all sizes should be looking at value streaming mapping.