A quick history
Although Toyota first popularized this visual tool, there's reason to believe that it was invented much earlier. Similar diagrams and notes outlining information flow have been found in a 1918 book called "Installing Efficiency Methods" by Charles E. Knoeppel. Toyota certainly adapted the concept effectively so people often credit the company with the invention of this technique.
Fun fact: In 2013, instead of writing a check, Toyota decided to donate efficiency to The Food Bank of New York City, the country's largest anti-huger charity. Toyota's engineers cut down the wait time for dinner from 90 minutes to 18 at a soup kitchen in Harlem. They reduced the time spent on filling supply bags from 11 minutes to 6 at a food pantry in Staten Island. When volunteers were packing boxes of supplies for Hurricane Sandy's victims at a warehouse in Brooklyn, the time it took to pack one box was brought down from 3 minutes to 11 seconds!
Why do you need value stream mapping?
Value stream maps provide a holistic way to look at a process holistically. This can bring to light hidden segments or energy-drains in your process. Mapping out a process which spans across teams is a challenge, but the payoff is generous because small gaps in efficiency can scale when you put all the parts together.
The main goal of a value stream map is to eliminate waste, identify the critical steps in your process, increase the value your customer is receiving, and continuously improve the efficiency of your process.
Value stream mapping in software development
Naturally, VSM is tweaked when it's applied to different industries. While it's used to eliminate wastes like overproduction, overprocessing, and waiting in the enterprise manufacturing industry, it focuses on different types of waste in the software world.
There are sevent types of waste in software development.
Partially done work
For many teams, the WIP bucket is a pit from which some tasks never emerge. Sometimes we abandon tasks because more urgent ones come up, or because we were waiting on a dependency and forgot to follow up. The effort we've already invested in them goes to waste. Incomplete work can mean any feature that has been developed but hasn't been pushed live yet. Unless a feature is live, it isn't adding value. By limiting the number of work-in-progress items, you can ensure none of your efforts get wasted.
Whenever you go beyond the requirements, that extra effort is a form of waste. For example, when you're building a login page and you have a field for email address. You want to ensure none of the email addresses you receive are invalid, so you add verification to your backend. However, based on the average traffic of your site, if 99% of email addresses were going to be valid anyway, you just hard coded a solution for a non-existent problem. Over-engineering is trying to optimize for possible situations that may not materialize.
Needing to get reacquainted with how something works because you haven't engaged with a certain part of your code, or because someone else worked on it, is a form of waste. Proper internal documentation and knowledge sharing go a long way in trimming the overall time you spend on development.
This type of waste occurs when a task has to be handed over from one person to another in the process. Software development has multiple phases, so handoffs naturally cannot be eliminated completely. However, if DRIs are changed excessively either due to resource allocation or employee turnover, that is an example of handoff waste. For example some critical information could be getting lost because of too many handoffs in the communication pipeline. The number of handoffs in a process needs to be optimized in order to eliminate waste.
Have you ever had to interrupt your work to take care of an urgent bug fix or to attend a meeting? You might have noticed that it takes a while for you to regain the context of your work and continue with it. This is the waste we generate from context switching. We' try to be efficient and responsive, but you expend mental effort every time you break away from your work to address something that comes your way. Keeping away all non-critical interruptions is a great way to use the optimum mental pace of a developer.
This is another type of waste that is inevitable in most processes. Software development has multiple phases, and delays occur when one phase ends and the next one can't begin right away. If you have a common designer for two projects, and both need something, one of them would have to wait. This waste is usually balanced against the cost of hiring a second full-time designer.
Defects are bugs that get pushed live. They could be because of a misunderstood requirement, insufficient specification, missed test cases, or a human error. Defects are often reported by your customers and trigger another process of bug-fixing. Many organizations spend a great deal of time and money to reduce the number of bugs in their product since it directly affects the credibility and reliability of their software.
VSM aims to increase value by eliminating these seven different types of waste. Continuous Delivery pipelines in software development rely on processes running seamlessly. Value stream mapping fosters a culture of continuous improvement, which is what agility is all about.
How to get started with VSM
Similar to any other tool, it's always wise to start small. Select a singular goal that you want to achieve, perhaps a single type of waste you aim to eliminate. Pick a process, collect process data, and try to map it. You could start it as an experiment within your team although VSM is usually done by a dedicated team. With allocated budget and resources, VSM is undertaken as an org-level activity to increase efficiency within a company.
Value stream mapping is a perfect example of the whole being bigger than the sum of its parts. Small changes in a process cascade into enormous ramifications for its efficiency.
If you continually eliminate waste from your process, you're left only with the parts that directly provide value.