Value stream has become a part of the application development lexicon, having first gained uptake as a manufacturing exercise and now being applied to the process of delivering value to customers through software.
It’s been evaluated by analysts and increasingly written about in the industry press — including the SD Times Jan. 1 cover declaring this The Year of the Value Stream — so people are starting to wrap their heads around the concept of finding where bottlenecks in your process are, and finding which bit of work is just not productive and eliminating it.
But creating a value stream takes work. Although there are tools that can help organizations map their own value streams and gain visibility into their processes, there is no cookie-cutter approach to getting it right, and no silver bullet tool to do the heavy lifting for you.
RELATED CONTENT:
Creating a value stream map
How does your solution help organizations on their value stream journey?
A guide to VSM tools
Losing command and control…and living with it!
That being said, the rewards that a well-structured value stream management program can provide include the frequent delivery of software that your customers like and use, and the elimination of waste from your workflow that can save money and time. It’s a way to ensure you are always getting better at what you do.
“We’ve been using the terminology, but it’s just now starting to take hold,” said Lance Knight, senior vice president at ConnectALL, an Orasi company. “I can go in and solve my release process and improve my release time, but if I don’t look at how long it takes for that idea to go all the way through, then I miss time to market. Time to market and visual transformations right now is very, very important.”
As organizations should with any relatively new concept, we’ll step back to the beginning, and start with the question: What exactly IS value stream management?
Eric Robertson, vice president of product management and strategy execution at CollabNet VersionOne, defines it this way: “Value stream management is an improvement strategy that links the needs of top management with the needs of the operations group. It is a combination of people, process and technology. It is mapping, measuring, visualizing, and then being able to understand from your planning, your epics, your stories, your work items, through these heterogeneous tools all the way through your enterprise software delivery lines, being able to understand that what you’re delivering aligns with the business objectives, and you’re being effective there.”
For sure, there is still some misunderstanding. ConnectALL’s Knight said, “Go to a conference and say, do you know what value stream is? I bet you most of them aren’t really going to understand, because values stream management is, it’s about all that Lean [manufacturing] stuff. There’s something that I think is missing in aligning knowledge and people. Value stream mapping is a tool to identify waste. But software itself could be part of the tools you use to identify waste. There’s no one tool that’s going to map and remove all your waste. So, that’s the reality, where people are taking point tools, and doing point things, but they’re not taking a holistic value stream look, end to end.”
On a manufacturing floor, where the production design and method of a particular widget doesn’t change often, it’s easier to understand the process and product flow. The challenge of bringing value streams to software development is that software is a constantly changing intangible. “You have to account for that when you’re looking at value stream and software,” Knight said. “What’s really important when you look at it as a company, and why value stream should be implemented, is you need to handle two major forces. That is, time to market needs to be better than your competitors, bar none, and a good customer experience at the local branch of the bank isn’t it anymore; it is all digital focused.”
Alex Tacho, product manager at CloudBees, said, “The manufacturing process is pretty linear, with clear dependencies — steps that have to be completed before moving that product or widget upstream to the next phase. This is where the value stream concept in software development is interesting to define, since the steps to produce a feature or even fix a bug may not have clear dependencies. … However, like manufacturing, software delivery and continuous delivery is made up of linear processes, too, with dependencies that must be passed before software is deployed to production. What’s really amazing, when you think about it, is that we haven’t been as organized around value streams and automation as manufacturing has been for decades, now — maybe as much as a century — value streams really are a concept that also applies to software. Identifying waste in the process and streamlining the flow of software through to production is all good.”
Where to begin?
So you’ve done your evaluation, decided creating value streams will greatly benefit your company, and you’re ready
to go. But where do you start? As always, opinions vary.
Some say it is important to define what you want to accomplish. Others say a value stream begins at the ideation stage, when products are conceived. Still others say the first step is to create a value stream map, which looks at all assets and properties to help organizations see where bottlenecks and waste are in their processes. Yet all agree it is a journey of continuous improvement that never ends.
Carmen DeArdo, senior VSM strategist at Tasktop, said value stream creation and management starts in the ideate space. He explained, “We set up teams and we say, ‘How do things start? Let’s just talk about features and defects.’ Features don’t just start in Jira, or whatever your Agile management tool of choice is to understand really the wait states, because almost all of flow time is around wait states, and chances are it’s not in creative release. It’s probably in connecting ideate to create, or connecting operate to create, but almost everyone in the industry is doubling down on creative release, which is fine, you have to start somewhere. But it’s just the beginning of the journey and you have to continue that journey.”
Once your organization has bought in, it is important to first understand what your current operation looks like, and then to map that, to make your processes as visible as possible.
“The first step in value stream mapping is really about understanding your current state, and then really start looking at removing waste, bottlenecks, and understanding the activities that are being performed,” CollabNet VersionOne’s Robertson said. “And then, how can I streamline that, because you can’t improve what you don’t know. It’s really about understanding that current state, that process, that flow of value, understanding how it’s being delivered, and then looking at how that can be optimized.”
He said it is not uncommon for organizations to lack an understanding of all the activities that are involved in how products and services are created and delivered. “There’s a big disconnect there,” Robertson said. “Understanding state, your process, how people interact with that, and the tooling, and then going from there.”
Jeff Keyes, director of product marketing at Plutora, agreed that value stream mapping is the place to start, to gain that end-to-end visibility into the operation. “The first thing that you want to do is to map your value stream. In whatever methodology you want to talk, you have to understand what you’re starting with, so that you can understand what needs to be improved and where. It might make the most sense to automate; that might be your very next step, because you can improve quality and so forth. It might make more sense to figure out a better way of handling governance, because that’s where your bottleneck is. It might make more sense to become more product oriented versus project-oriented. All those things and those discoveries will come out of the process of evaluating the value stream as a system.
“The whole point is, do value stream first. Map your value stream so you at least understand what you’re doing. If you do Agile, what you’re saying is, great, let me break down my features into smaller buckets. That’s good. But it may not be where your constraints are. If you’re doing DevOps, you’re saying let me automate as fast as possible from check-in on to deployment. That’s great, but that may not be where your bottlenecks are.”
CloudBees’ Tacho said it is important for organizations to first define what they want to accomplish — whether that’s improving quality, delivering software faster, working more efficiently, or some other goal — what some are calling the “true north” of the organization. After defining the goal, he suggests finding the start and end points, and defining what it is you want to measure and improve.
Next, he said, you must assemble the team of all the roles that are involved in delivering a new feature: developers, UX, operations, security, testers and so forth. “The important thing is the people making up the team should be relevant to the end goal and empowered to act on the steps in the value stream to move the value (product, feature) to the next phase and ultimately to completion,” Tacho said. “But they should also be able to make changes to the process in their domain to make it more efficient or to fill a gap — which is the whole idea of this exercise in the first place.”
Once the correct team is assembled, Tacho said it should walk through the flow as it exists today, by analyzing the steps and documenting them in chronological order. “Now,” he said, “you have the beginnings of a value stream.”
In order to be successful, though, Plutora’s Keyes said, “they’re going to have to address some of the culture and the governance from the command and control, and how to incorporate all that governance, and audit and compliance and security requirements all as part of the life cycle, even though it may not all be automated. Oh.. Scary thought. Wait a minute, we’re talking about Agile and DevOps without a hundred percent automation? Yeah, you still can do that really effectively, and the way to get there, people are starting to look at value stream management to shine light on things and have orchestration to move things along faster.”
The people factor
An important step in getting to value stream thinking is changing the culture at work. Teams have to be given more autonomy to innovate and create, and organizations have to understand the role of leaders in their organizations.
Tasktop’s DeArdo acknowledged that many in the organization will be cynical about value stream — especially those who have been working for many years and have heard many promises regarding how things can be made better, only to see them fail. But he said culture change begins with stories of success that workers can relate to. “What’s powerful in a culture are the stories that people can relate to that are happening at their company. Not at Netflix, not at Amazon. What really changes is when people in the company had success and they could tell their own story. That’s what motivated people. If you can take a team that’s notorious, and that has the street credibility and you can turn them into an advocate for what you’re doing, you know you’re on the right track. That’s going to drive more loyalty than anything else … people wanting to be a part of something.”
Another factor for successfully implementing value stream methodologies is making sure the leaders understand their roles in making it happen.
Knight sees leadership as being responsible for visibility into the system, and gaining knowledge from that visibility. “Too often, the CIO, will go, ‘The business has asked for this. When can you give it me?’” Knight explained. “And the next thing you know, four years down the road, they say, ‘You promised me this a year and half ago.’ And that happens a lot in IT. If we frame this about being more predictable, increasing velocity and actually knowing when you put something into the system you’re going to get it, that is the message everyone will align to.”
Yet companies always want to measure themselves against competitors in their industry, to see where they fall on the path. This is especially difficult in value stream management, because each organization’s “true north” and values are different. So how can an organization tell if it’s being successful in implementing and utilizing a value stream?
CloudBees’ Tacho said it doesn’t matter how organizations define value. “If that value is driving revenue, solves customer or user needs, creates efficiencies or saves on costs and has a number of process steps that can be visualized, then it can be modeled into a value stream. Benchmarks available as a baseline to start measuring performance against and where to improve will be driven based on the industry you are in. But from a software delivery and DevOps perspective, we can tap into several years of research by the DevOps Research and Assessment (DORA) group that shows statistical data on how organizations have been progressing towards DevOps performance for software delivery.”
According to CollabNet VersionOne’s Robertson, “The measurement component is where you differentiate from value stream mapping and head into management. When you start to understand metrics, when you start measuring material movement and flows of information, and start looking at metrics like duration, delay against activities … these are very key metrics that are utilized to be able to understand and very quickly identify value vs. non value-add activities — waste — in terms of delay, including handoffs to a point, and all those kinds of things. So having a clear understanding and a good foundation around these measurements and KPIs, that is very reusable, add that’s where a lot of the folks are struggling.”
For organizations on a value stream journey, it is important to know that it is a winding path that crosses other methodology streams along the way. As Robertson explained, “It is evolving. But you’re not going to see a value stream transformation. You’ll see a DevOps transformation, you’ll see an Agile transformation, you’ll see business agility transformation. You won’t see a value stream initiative on the books. But what they’ll learn very quickly is you need value streams in order to be able to enable that business agility, to enable that successful DevOps transformation, to enable that scaling Agile initiative that you’re undertaking.”
Why now?
A few years ago, when the concept of value stream was first being discussed in development organizations, the response often was a quizzical look. But the conversation was about a way to describe end-to-end development and planning all the way — what CollabNet’s Eric Robertson calls “that concept to cash aspect.”
“In the Lean/Agile type of world, folks were utilizing methodologies like Agile, Kanban, Scrum, and so they started applying these Lean concepts and techniques around development, and that offshooted into DevOps, because delivery had to be more agile to catch up to development and accommodate that methodology,” Robertson said. “But it was still very technical-centric. It was about your DevOps tool chains, and we saw customers that invested in a lot of the Agile and DevOps tools — CI/CD — and they were about to automate things around workflows. But it was still very disconnected; they weren’t able to track that work in progress, all the activities and touch points. They could do it technically, so they can can tell you, ‘We delivered five releases this week,’ but really the business was saying, ‘What does that really mean to us? What does that mean to my initiatives and objectives that I’m trying to drive?’ My objective is enhanced digital footprint, one of my initiatives is support for credit-card processing, and in that last release, what capabilities did we deliver to align with that? That was the gap. They couldn’t really master that question. They could tell you all the technical aspects around it, but really around how this matches back up to the business, and the value you’re delivering, was that missing gap.”
Matching up development to company objectives and initiatives has been difficult to do. Plutora’s chief marketing officer Bob Davis said, “We get the value of Agile and DevOps, but look what’s happened. We have distributed organizations, it’s difficult to collaborate, to sync up across multiple methodologies. I’ve got a mobile banking application, and I’ve got a new feature coming out that depends on something going on in a more mainframe-oriented, waterfall-oriented methodology, and how do I make sure those get synced up and the dependencies are met, and things are tested correctly with the proper builds and the proper features? All that stuff is what we’re seeing now.”
And that’s what value stream management is trying to provide.
Project to Product… What does that even mean??
In value stream management, a change in perspective is required. Proponents of the methodology say you have to take a product view, rather than a project view, of the work you’re doing.
Isn’t a project merely a part of a product? It is, but there is so much more to a software product than the code.
Tasktop founder and CEO Mik Kersten titled his book on value stream management ‘Project to Product.’ As Tasktop’s senior strategist Carmen DeArdo explained: “I was at Bell Labs before I went to Nationwide Insurance. We were in a product model but I didn’t really know it. There are characteristics of a model of a product that I think lack in terms of a project. Projects are temporal, projects come and go. Products are things that you live with. Products are the things that continue to sustain you.
“When you’re looking at it from a product perspective, you’re looking at it across its entire life cycle and cost of ownership, and you’re looking at all aspects of work. Projects almost always focus on features. Project managers are focused on features. If it’s defects, it’s defects that are affecting the scope of the project. If it’s risk, it’s risk that is affecting the scope of the project. When you’re dealing with a product, you’re talking about everything that’s affecting that. If you have a vulnerability in a Struts library that may have nothing to do with a specific feature, you’re going to consider that as part of your product because it’s one of the systems that’s supporting your product. You don’t do that in a project model. You don’t look at flow distribution, you don’t have conversations around how much do you want to invest in features, defects and risk, and you almost never talk about debt, because debt is not something that’s going to help you now; it’s an investment in the future. It makes the next thing go faster. None of those things are in play in a project world.”
DeArdo also pointed out that the amount of churn you’re doing internally should be proportional to how much your company is changing. “The world doesn’t end of December 31st and recreate itself on January 1st,” he said. “I used to say, if you look at a company on January 1st, they’re selling pretty much the same thing they sold on December 31st. But if you look at what happened internally, they probably have a whole new set of projects, a whole new set of project teams, a whole new set of activities…what benefit are you getting from that? What benefit are you getting from doing all that reorganization? Your company may have some strategic changes; you may be launching a new line. BMW may be coming up with a new car. But fundamentally most of your products aren’t changing. That gets completely lost in this whole translation. I just think it’s a fundamentally different way of how work gets done and managed.”
