Create Value Stream Maps
After completing this unit, you’ll be able to:
- Explain how Lean concepts translate to software development.
- Get started mapping your team’s value stream.
- Use the theory of constraints to target improvement areas for your team.
Applying Lean Concepts to Our Work
Joan is a new manager of the Salesforce development team at Perpetual Learning, an adult education and career training company. The team struggles to deliver functionality as well and as quickly as the business needs. There are work inefficiencies, interpersonal conflicts, and confusion about how to improve.
But the biggest challenges can be the biggest opportunities, so Joan is ready to work hard to help the team. She’s recently learned about DevOps and wants to see how it can be useful for her team.
Identifying Your Customer, Your Product, and Its Value
DevOps evolved from the Lean movement. According to the Lean Enterprise Institute, “The core idea of Lean is to maximize customer value while minimizing waste. Lean means creating more value for customers with fewer resources.” Lean concepts have revolutionized industries like manufacturing and healthcare, and are increasingly influencing the world of IT.
Lean can be summarized in five principles.
- Identify value.
- Map the value stream.
- Create flow.
- Establish pull.
- Seek perfection.
The first Lean principle is to specify the value of each product, as defined by the customer.
But who is the customer for Joan’s team? The team customizes Service Cloud for the company’s support agents. They never interact directly with the company’s customers; they don’t create any physical product; and no one “buys” the work they do. So how can you specify the value of their work?
Joan realizes that for her team, the “customer” is actually her company’s support agents. They are simply internal customers instead of external customers. The “products” Joan’s team produces aren’t physical products but are the customizations they make to serve the support agents.
It’s important to think carefully about the value Joan’s team is delivering. Seeing this value from the customer’s point of view allows you to distinguish which activities really matter, and which activities may be waste.
Not every change the team delivers brings the same value. Some bring great value, some only a small benefit, and some changes can even make things worse. Support agents receive value only when customizations help them do their job better, serve more customers, or work more easily.
The support agents rely on Joan’s team to keep making customizations for them as their processes evolve. A simple change that reduces average case resolution time by one minute can save hundreds of hours per year and improve the experience for both support agents and customers.
The second Lean principle is to map the value stream for each product and eliminate unnecessary steps wherever possible. What’s a value stream? Value streams are the sequence of processes needed to deliver value. In software, a value stream is the process of turning an idea into a product or service with the help of technology.
Joan realizes that her team’s value stream begins with receiving requests from the support department. Then her team plans work, builds features, and then tests, deploys, and releases them to users.
This value stream is invisible, meaning it’s hard for people to see how their work fits together. But instead of just thinking of members of her team as people who do particular jobs, Joan realizes she can see them as part of this value stream.
Flow, Establishing Pull, and Seeking Perfection
Lean originated with the Toyota Production System that revolutionized manufacturing. The name Lean describes the emphasis on finding and removing waste from the system. The goal is to get value to flow to customers at a steady pace. Flow is achieved by performing value-creating steps in tight sequence, and through techniques like limiting work in progress. This is the third principle of Lean.
The fourth principle of Lean is that as flow is established, work should be “pulled” by customers rather than pushed through the system. In the case of software, that can mean not delivering features unless there is a clear need or request from customers.
The fifth and final characteristic of Lean is its most powerful, and what really distinguishes it: the continuous pursuit of perfection in this process. We discuss continuous improvement in the Continuous Innovation with Copado module.
The State of DevOps Report found that Lean software practices lead to lower burnout, improved culture and work environment, and improved team performance.
Mapping the Value Stream
Visualizing the Process
One challenge in improving the process of software development, or any knowledge work, is that you can’t see it. It’s easier to understand Lean practices in manufacturing, since you can actually see raw materials coming in, an assembly line transforming them, and finished products going out.
So before we can improve our development process, we need to make it visible. The most important thing to visualize is the value stream itself.
Everyone on Joan’s team works hard at what they do. But the team struggles to deliver quality work on time. They decide to adopt Copado as their Salesforce delivery management platform so they can coordinate better, save time, and build applications more effectively.
Joan wants to understand the team’s workflow better so she asks her release manager, Tony, and architect, Praveen, to map out their value stream. Copado includes a Value Stream Mapping tool that lets them visualize and measure the process of delivering features and fixes.
Tony and Praveen begin by mapping out each stage from the time a request is received: planning, architect review, development, testing, change approval, and release. Mapping out these stages is like visualizing an assembly line in manufacturing.
Every department in the modern enterprise has multiple value streams. Teams such as sales and service have developed standard processes for managing their work, such as opportunity pipelines and case resolution processes. IT departments are increasingly adopting value stream mapping as a way to manage for throughput.
Estimating Time in Each Stage
When making a value stream map, it’s critical to gather metrics on time and quality at each stage. These numbers can illuminate parts of the process that waste time or energy. Getting these metrics can take some digging unless you have a tool like Copado Value Stream Maps designed for that process.
The first thing to note is how many pieces of work are in progress in each stage, and how many people are working on each stage.
Then estimate how much time a typical piece of work spends in each stage. These times are called the lead time for each stage.
Lead time is important, but it doesn’t tell the whole story. You should also estimate processing time, or how long it takes to complete each stage of work if the worker isn’t doing anything else. Processing time is the theoretical fastest time a piece of work can be completed.
Lead time is typically much longer than processing time for two reasons: People multitask, and work sits idle. The more we multitask, the more lead time grows. If you work on 10 things at once, they all take 10 times as long. Often there is also a period where work sits in an inbox before being started, or sits in an outbox waiting for the next phase.
Estimating Quality in Each Stage
After she estimates the times for each process, Joan wants to capture metrics about quality. She knows that some work the team does is defective or isn’t used. And some team members report quality issues with other members’ work.
Joan asks the team to estimate how often they receive work that is defective, missing information, or inaccurate, and when in the process the defect is introduced. She finds that some stages are more reliable than others, but work from most stages is only about 75% complete and accurate.
Summarizing the Metrics
Gathering these metrics allows teams to see the bigger picture by summarizing the numbers across all stages. Total lead time is how long it takes to process a piece of work, and total processing time is the theoretical minimum amount of time it takes to do that work.
When summarizing the quality metrics, we ask what proportion of work items suffer from quality issues along the way. Ideally, every piece of work sails through the process. But if each stage is only 75% complete and accurate, after six stages only 18% of the pieces will have passed through without having quality issues.
It took some work to find these numbers, but Joan’s glad she did. Now she wonders what the team is going to do about it.
Looking at the value stream map and metrics can seem complicated, but it’s no more complicated than looking at your personal finances. Money comes in and goes out; we have assets, and we have debts. With practice, looking at a value stream map becomes just as straightforward. Optimizing your team’s ability to deliver valuable work with minimal effort is like optimizing your income, expenses, and investments.
Sometimes creating a value stream map gives you ideas about how to simplify your process, just like looking at your finances can reveal that you have more credit cards than you need.
Joan's first impression is that every part of the process can use improvement: The quality of planning and development are low; testing and release management can go faster; and the change approval process takes too long.
But Joan learns about another idea that originally came from manufacturing, the theory of constraints (ToC). ToC says that at any given time there’s only one part of the system that is the main constraint or bottleneck.
It’s natural to want to improve everything all at once. But value streams are interdependent systems, and you can’t optimize a system by focusing on parts in isolation. The key to improving a flow is finding the one part of the system that constrains the flow.
The following units share the approach Joan and her team use to systematically improve their processes. Their goal is to optimize the overall flow and work smarter, not harder. They approach each challenge by trying to identify the underlying constraint, so they can make improvements that are targeted and effective.