Plutora Blog - DevOps, Release Management, Test Environment Management, Value Stream Management
Value Stream MappingReading time 26 minutes
A few years back, a large mortgage company was struggling. Their mortgage application process was taking an average of more than three weeks to come to an approval decision. Their customers were growing more and more frustrated. Many were simply leaving and going to competitors. The application approval process passed through a dozen teams and several dozen servers that were supposedly each “critical” to the process. They knew they needed to expedite their application process, but had no idea of how or where to start.
After years of numerous failed attempts, it was determined they needed help, so they hired a consultant. The first thing the consultant did was visit each of the teams and observe firsthand their role in the application process. With help from IT, the consultant was able to identify each of the servers in the process and what their role was. Then, with firsthand knowledge of what was happening at each step of the mortgage application process and with input from the leadership of each of the respective teams in the process, the consultant was able to develop a value stream map to intelligently determine where the real value was being added in the process, what steps could be better addressed elsewhere in the process, and what steps were simply unnecessary and taking up valuable time.
For the first time, this enabled intelligent holistic discussions about the process. The consultant was able to develop a plan with the company’s leadership to consolidate the process from over three weeks to less than two days and from 64 different servers down to just two servers. With this plan, there were now several teams that were no longer needed for this application process. However, after some thoughtful discussion with the leadership, each team was successfully reassigned to other tasks that would further increase product value to the customer.
These improvements have since saved the company tens of millions of dollars annually, improved customer retention, and have positively impacted several other areas of the business. All of this was simply the result of a consultant that understood the application of value stream mapping.
1. What is Value Stream Mapping?
To understand value stream mapping, we need to first understand what a “value stream” is. Simply put, a value stream is a series of steps that occur to provide the product or service that their customers want or need. In order to provide the product or service that the customers desire, every company has a set of steps that are required. Value stream mapping enables us to better understand what these steps are, where the value is added, where it’s not, and more importantly, how to improve upon the collective process. Value stream mapping (VSM) provides us with a structured visualization of the key steps and corresponding data needed to understand and intelligently make improvements that optimize the entire process, not just one section at the expense of another.
Value stream mapping is defined on iSixSigma.com:
“Value stream mapping is a lean manufacturing or lean enterprise technique used to document, analyze and improve the flow of information or materials required to produce a product or service for a customer.”
The book “Value Stream Mapping”, written by Karen Martin and Mike Osterling, explains, “Value stream maps offer a holistic view of how work flows through entire systems.”
VSM can be a tremendous tool to help determine how to improve on product delivery that require complex processes. If you have a highly complex process, VSM can be used to create a comprehensive view and understanding of the entire process, or it can be as focused as needed on a segment of the process to address specific objectives.
It’s important to note that the start and end points of the mapping exercise, known as fenceposts, can differ depending on your goals and objectives. You will also find that a single company may have several different value streams. Value stream maps can be created for every individual product and service for every type of business. However, for the purpose of this discussion and so you can better understand how to apply this in the real world, we will focus on VSM as it relates to feature development for enterprise software solutions utilizing a simplified waterfall methodology. We will refer to software features as the “product” being developed in this process.
Unlike process maps, or flow charts, that show only the steps involved in the process, a VSM shows significantly more information and uses a very different, more linear format. The VSM enables leadership to see where the actual value is being added in the process, allowing them to improve on the overall efficiency associated with the delivery of a software product or feature request, not just the number of steps.
Using the example of the mortgage company above, their process flow chart showed 64 different servers with dozens more actual steps in the application process. However, this flow chart didn’t show that only a few of those steps actually added value to the application process. This is where VSM has great value. It not only mapped the key process steps, but also showed which of those steps actually applied any real value to the mortgage application process. This type of chart can be an invaluable tool to enable quality process improvement discussions with other team members and stakeholders. Without it, there’s just no efficient way to convey this information.
2. Terminology and symbols and what they mean
With so much information packed into a VSM, it’s no surprise that there are terms and features that may need some explanation. However, while we will provide an explanation of some of the standardized VSM features, keep in mind that they may be modified to help achieve specific objectives. As such, each VSM may have elements that are unique.
To start, each VSM typically has three key sections. For example, Figure 1 above shows a simplified VSM for a software development lifecycle. Notice the three main colored sections. The colors were added to highlight the different sections of a VSM. These sections show Information Flow, Product Flow, and a Time Ladder or Lead Time Ladder.
Information Flow – This section shows the communication of process-related information and the transmission of data. In this simplified example, the release manager takes in all customer requests and submits only the approved requests into the development process, notifying the customer in the process. Depending on the objective or goal of the mapping exercise, information collection and distribution points shown here as SharePoint and Excel can include many levels of detail and many other integrated systems.
Product Flow – This section maps the steps of the development lifecycle from concept to delivery. However, depending on your objectives, this can be refocused on specific sections of the process, making it as granular, or as high level, as needed. It typically shows both the task being performed and the person or team performing the task. Below those boxes, you will notice smaller fields that show key process data. For the sake of simplification in this example we’ve chosen to show only a couple data figures. C/T represents “Cycle Time” and S/T represents “Set Up Time.” In practical use however, VSMs can include any number of data points in this section, highlighting pertinent information.
Time Ladder – The Time Ladder provides a somewhat simplistic visual representation of the value stream timeline. The upper portion of the time ladder represents the average amount of time that a feature spends in queue or waiting at each stage or gate in the process. The lower portion of the time ladder shows the average amount of time that each feature was actively being worked on, or more specifically, when value is actually being added to the feature/product during that specific stage.
Cycle time (C/T) is the frequency of units/features produced, or the average time between the completed production of one unit/feature to the completed production of the next. Using our scenario of feature development for an enterprise software solution, cycle time is the average amount of time it takes from the completion/deployment of one feature request to the completion/deployment of the next.
Setup Time (S/T) is the amount of time needed to prepare for a given step. For application to software development, depending on the step, this can indicate the amount of time needed to understand what specifically is being requested or the time needed to configure, spin up or allocate a test environment.
Uptime (%) gives you an idea of the percentage of the time the process or systems are actually active. For our scenario, this can show system uptime or employee availability time.
Lead Time is the measurement of the average amount of time needed for one feature request to make it through the entire development cycle concept to delivery, or from the beginning to ending fence post.
Takt Time is a term that is commonly used with value stream mapping. It refers to the rate in which you need to produce your products in order to meet customer demand. Figure 2 shows an example of how takt time is calculated and applied.
3. How will value stream mapping help?
Business is growing more competitive every day. In order to keep up with customer demand and expectations, development teams are having to work faster and be more efficient than ever before. However, it’s not just the development teams that are impacted by these increased demands. A VSM activity can help to identify and better coordinate other impacted operational teams and process segments that are integral to the overall development process.
This mapping activity can be immensely helpful in providing leaders, stakeholders and team members with a unified view. This new view enables them to step out of their information silos and gain a more holistic understanding of the overall process and their respective roles and contributions to the finished product. This added perspective helps them each to see their individual contributions as more significant, valued and essential to the product delivery process. Without this, team members often lose perspective, distort and/or discount the value of their role. Participating in a VSM activity is a great way for team members to gain clarity and understand of the value of their respective roles. Of course, this goes a long way to improve individual and team morale.
While we’d like to believe that every team member follows the team’s prescribed processes, the reality is typically far different. While there may be a prescribed process for a given segment of the process, it’s common for these processes to be further modified or simplified by individuals or teams. Those processes can also vary greatly from day-to-day depending on who shows up to work, their mood, workload, and a number of other factors. Without a unified and holistic view, total alignment from each of the teams and their team members on a consistent basis is nearly impossible. Granted, there will continue to be variations in the prescribed processes, but at least with the holistic view of the entire process, the end result will likely be better aligned with the needs of subsequent steps.
Without the holistic understanding that VSM provides, any improvements made to the life cycle typically benefit one segment, often at the expense of another. A simplified example would show that if you simply speed up the development process, it will likely increase the backlog for testing and also result in more quality issues that can find their way to the production environment.
The VSM is also the most efficient way to record the current state of things. When making changes to the development cycle, creating a baseline VSM for future comparison is the best way to go. This enables easy before-and-after comparisons of the performance data to determine if the changes made had the intended impact.
4. Who benefits from value stream mapping?
The VSM exercise can be used to meet a variety of objectives. For example, it can have a very tactical function when developed and applied at the practitioner/specialist level. On the other hand, it can have a high-level strategic function when developed and applied by leadership.
When creating the VSM, it’s critical to know from the beginning what the key objectives are and who should be present in the mapping sessions to have the desired impact. If the objective is for strategic changes, the mapping session needs to be made up of the appropriate level of leadership who can directly affect and make the necessary strategic changes. Likewise, if your objective is more tactical, you’ll need to have the appropriate team members who can execute those types of tactical changes.
While there are a number of benefits that will be realized from the various team members, stakeholders, executives and even shareholders, the real benefit to VSM is realized by the customer. The customer will experience a better-quality product, it will be delivered faster, and it will better meet their needs and expectations.
5. History of Value Stream Mapping?
Value stream mapping has been growing in popularity in recent years and is still considered by many to be a relatively new tool in the effort to improve business efficiency. Despite still having that relatively new feeling, it has been around for quite a while and has seen a number of refinements.
Value stream mapping can be traced back to more than 30 years ago, to the visual mapping technique used at the Toyota Motor Corporation. It was then known as the “material and information flow”. It came about as the company’s focus shifted to gain a better understanding of the material and information flow throughout their organization. Popularity of this mapping technique grew as American companies observed and studied the efficiency and consistency of Toyotas’ operations.
The term “value stream” was first used in a book called “The Machine that Changed the World” (1990) written by James Womack, Daniel Jones and Daniel Roos. It was then further popularized by another book, “Lean Thinking,” (1996) which was also authored by James Womack and Daniel Jones. These books essentially launched the Lean movement. They defined the value stream as “the sequence of activities an organization undertakes to deliver on a customer request.”
As the Lean movement took off, so did this mapping technique that Toyota had developed. It has continued to evolved to become what we now know as value stream mapping, which is much more applicable and useful for businesses and value streams of all types.
6. How to map your first value stream of software development
There are some key steps to creating a VSM for your organization.
- Define your focus – This is probably the most important step of the entire VSM exercise. Start with clearly defining the objective. With a clear objective in mind, identify the appropriate focus, scope and process to be mapped. Typical objectives for software development value streams can include speed or velocity, improved quality, improved governance and compliance and improved efficiency.Next, determine your fence posts, or the start and end points of your mapping exercise. For example, will the starting point be the creation of a customer feature request, or will you start with the receipt of an approved request? This might seem somewhat trivial, but it will matter in your VSM team selection and mapping details. Will you end with a delivered product to production, or will you end with production side customer sign-off? These are things that need to be determined up front before the VSM team meets. The reason for this is explained in the next step.Keep in mind that a value stream map is not a process flow chart. That said, it doesn’t need to map every possible inflow, or outflow of the process. By maintaining focus on the predetermined objectives and fenceposts, the mapping activity is far more likely to stay on track and focused.Another thing to keep in mind is that value stream mapping is not tied to a specific methodology. It will work equally well with waterfall, Agile, DevOps, CI/CD or anything else. VSM can also be used as a tool to help in the migration from one of these methodologies to another.
- VSM team selection – You will need to make sure that the appropriate team is assembled to meet the objectives of the value stream mapping activity. The team needs to be those individuals that are directly able to make the changes that might come from the activity. For example, you don’t want to have your team be comprised of only developers and testers if it’s determined that changes are needed that require support from operations, or if the determined changes are organizational and require senior leadership. Likewise, you don’t want to have a group of senior leadership tied up in the activity if the goal is to improve low level tactical processes.When selecting the team, it’s important to not make the mapping team too large. If you get too many people involved, you could suffer from analysis paralysis. Having a group of 6-10 people is a good goal. Using our example of software development, a mapping team could consist of a product owner, scrum master, pipeline engineer, architect, development manager, test manager, test environment manager and the release manager.
- Go to Gemba (Walk the Process) – “Gemba” is a Japanese term meaning “the actual place.” “Go to Gemba” means go to the place where the work is being done. Visit the customer where the software is being used and understand why they need the features they are requesting. Visit the release manager, the developers, the testers, the test environment managers, etc. See what it is they do, how they do it, understand their process, what does and doesn’t work for them. By doing this, you will develop a much more holistic perspective of the process. Value stream mapping should never be done from behind a desk. Resist the urge to jump into the weeds and make changes before you understand the entire value stream. This mistake is the key contributor to sub-optimized processes in one area at the expense of another. Depending on the team and the process, it is recommended, and can be very beneficial, to have the entire team “Go to Gemba” with you. This will help everyone to be on the same page with the same perspective and understanding. Ideally, the team mapping activity should take place at a location that will have the entire process nearby and accessible for additional walk-throughs if needed. This will come in handy as they meet and come up with additional questions that may require additional visits to one or more segments of the process.
- Define the basic Value Stream – Start with a rudimentary VSM to give your team a starting point. This helps to jump start the activity when you first meet as a team. The key thing here is to outline only the process basics. Then, as a team, add the additional detail together. Doing this skips the mind-numbing activity of discovering the obvious. It also shows a rough example of how it looks and works, and it also moves the activity quickly along to higher quality discussions, inputs and discoveries.
- Team mapping activity – Value stream mapping is an activity that needs to be developed by a team. Each of the team members is an expert in their respective segments of the process, which leads to different perspectives of needed changes and how to apply them. Changes made in isolation from your VSM team members will almost always result in flawed attempts that do little more than waste time and money. The mapping activity is a collaborative discussion to develop the VSM. Depending on the process being mapped, this activity can take anywhere from several hours to several days to complete. Each of the team members should come prepared with or be able to quickly access the data needed to complete their respective segments of the VSM.
- Develop your current state value stream map – Starting with your basic VSM (from step 4), add the additional processes and their corresponding data, including current cycle times, lead times, up times, takt times, SLA’s, etc. This should reflect all numbers as they currently are. This is known as your “Current State” VSM. This current state version will be immensely important to keep and use as your process baseline.From this current state, the mapping team will be able to better understand the entire process. This enables the team to discuss productive what-if’s and to develop better solutions to identified hot points. This current state VSM will also come in handy in the future after you’ve implemented changes. It enables you to provide a before and after comparison of the process and its performance figures to know if the changes had the desired impact.
- Develop your Future State Value Stream Map – Using your current state VSM, identify the areas that are hot points, bottle necks, backlogs, strengths, weaknesses, etc. Once these areas are identified, the team can begin working on holistic improvements to the process.As improvements to the process are planned, they will often require a phased approach to introduce necessary changes to achieve the target state. To do this, a future state VSM should be created for each phase, and should reflect the expected data, times, volume, etc. This allows you to validate your assumptions at each stage, to make sure the changes are having the desired impact and moving the process performance in the right direction. This enables the VSM team to make changes as needed to keep them on track to reach the desired future state performance objectives. The future state VSM gives you and your team members a unified view of the overall process as well as targeted objectives to work toward.
7. Working through the What-if Scenario
There are many ways to work through and identify the challenges in your value stream. Many Lean experts will start with current state data and look for hot points, bottle necks or issues that can be easily resolved. This method typically looks for the low hanging fruit and prioritizes changes to the process accordingly.
Others will start with the end in mind. For example, if they know that they need to have the Takt Time under a certain threshold, they will start with that and work their way back, squeezing the process down until they reach their target.
Using the sample Current State VSM shown below in Figure 3, we can see there are a number of hot points to work through with the VSM team to make improvements. Here are a few examples:
Example #1: Notice that in the “Information Flow” section, the U/I Design and Development teams both use SharePoint, and Excel is used by the testing and build teams.
Possible Solution: Upon discussion, the VSM team determines that a unified information sharing solution like Plutora would likely increase the transition speed from one team to the next and create pipeline visibility. Note that isolated information silos, like those shown here, cause process inefficiencies, bottle necks and poor interdepartmental communication and workflow.
Example #2: In the “Time Ladder” section, we see that feature requests sits for an average of three days before the U/I Design team works on them. This would be a great place to start process improvement discussions with the VSM team.
Possible Solution: The VSM team determines that they can temporarily reassign one of their team members to help work through the three-day backlog to help get things caught up. That temporary assignment can be reapplied as needed to help out when someone on the U/I team misses work.
Example #3: In the “Product Flow” section, we see that the test team has an average setup time of 45 minutes for each feature. VSM team discussions discover that this is caused by manually reconfiguring the test environment each time.
Possible Solution: The VSM team discusses this and determines that the Plutora test environment management solution would resolve this issue, and also help reduce the two-day backlog shown in the time ladder between the Dev Team and the Test team.
Finally, the VSM team develops a Future State VSM shown in Figure 4 and determines that by implementing these three changes, the Production Lead Time is shortened from 12.5 to 8 days, which is well within the desired range.
8. Measuring the Results
Efficiency can be measured through a wide variety of metrics depending on the organization and the level of detail that is being tracked. However, with anything that is being tracked, it’s always important to have an established baseline that shows your starting point. For example, if the original VSM was created in January and now, in April, all the changes have been made and are running smoothly, a comparison of your original current state map from January with an updated current state map from April will provide you with an apples-to-apples comparison of all changes in the performance data. This provides an all-inclusive view of not only how the changes impacted the changed area, but also the entire process.
9. Continuous Improvement and what that looks like
Using the above example, we can determine that the new changes increased the overall process performance by 36%. However, because the industry is so competitive, it’s quickly determined that we need to continue efforts to improve the development lifecycle performance. Value stream mapping provides a great way to make changes and improvements to the process without doing so at the expense of other process segments.
Depending on the organization, the value stream mapping activity should be held as often as needed for each process. If your project value stream uses a Waterfall methodology that might be a couple times a year. But if you use an Agile methodology, that could be for each cycle. It can also be used to focus in on smaller segments of the process, enabling a deeper dive into those process specifics. Using the above example, we could hold a VSM activity with all the test engineers to focus specifically on the testing process, or do the same with the Dev or U/I team.
The goal is to make continual improvements to the process. Those improvements can take multiple forms, such as changes in procedures, incorporating automation, adding new tools, increasing head counts, etc. It’s also important to note that not all improvements are centered on time or process efficiency. Some identified improvements might focus on improving team morale, team or cross-team unification, trainings, improving team focus, or inter-department process and workflow transparency.
10. Visualizations in the Real World
Staying competitive in business requires consistent process improvement and monitoring. It’s not enough to get updated performance numbers only when a VSM team is assembled. These metrics need to be tracked regularly, some even daily or hourly. So how are these numbers tracked in the real world? Most organizations will establish a report, or series of reports, that show the data points of interest. Dashboards are also a great way to display current figures. The example shown in Figure 5 is an example of a dashboard from Lean Teams USA.
There are, of course, a wide variety of tools that can be employed to track and report the necessary value stream data points throughout the entire mapped process. A few will even provide support for other development lifecycle management functions. For example, in looking at the enterprise scale development process, Plutora Continuous Delivery Management solution has the ability to track and provide detailed reporting and analytics on the entire development process from concept to delivery. This type of dashboard can be a powerful tool to show current state value stream data in near real time. This dashboard also gives the viewer the ability to easily drill down into data hotspots to identify specific issues and bottlenecks. They have an interactive demo of this titled “Visualize Your Value Stream”. It also integrates with tools like ServiceNow to further expand the tracking and reporting capability to include production system uptime, production side release tracking, feature requests and more.
Tools like Plutora are designed to track and report on data of all types, including the data used in the value stream maps. These tools are ideal for providing dashboards, reports and analytics that track the performance of the entire mapped process in nearly real time. They provide amazing transparency and clarity of current state throughout the entire lifecycle. They also enable the user to drill down into the data to identify and address problem areas.
Whatever tool you end up using for your current state tracking of metrics, you will need to make sure it’s readily available to those teams and team members along the entire process, so that it continues to provide that holistic perspective for every team that is part of the value stream.
At the end of the day, the goal is to develop a corporate culture that provides the best possible product to meet or exceed customer needs and expectations. This is ultimately done by making continual improvements to the value stream. As our customers’ needs and expectations evolve, so also will our value streams need to change and constantly evolve.
Dan is an Industry Specialist at Plutora. Dan got his first taste of programming in high school, coding games in Basic. Since then, he has been directly involved with nearly every aspect of the Development and Release lifecycle — coding, testing, project management, team management, architecture, database, web & graphics designer, and much more. He has implemented development lifecycle methodologies for companies like Sears Financial, Novell, Sprint, Daimler-Benz Financial, Sabre, Centex and T-Mobile. He has founded multiple companies, and continues to work as a business and technology advisor on various projects. In total Dan has managed and orchestrated literally hundreds of deployments, development initiatives and thousands of iterative code enhancements.
Jeff is the Director of Product Marketing at Plutora. He got his first programming contract while still in high school building relational database applications. He has been involved in almost every aspect of the software development lifecycle including development, architecture, product management, development management, application delivery, and consulting. He has also helped transition organizations from Waterfall to Continuous Delivery methodologies. Outside of 6 years at Microsoft, he has both founded and worked exclusively in startup companies. By moving into product marketing, he was able to follow his passion to set and evangelize product messaging. Jeff holds a BA in Electrical Engineering from the University of Washington.