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.<\/p>\n
It\u2019s been evaluated by analysts and increasingly written about in the industry press \u2014 including the SD Times Jan. 1 cover declaring this The Year of the Value Stream<\/a> \u2014 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.<\/p>\n 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.<\/p>\n RELATED CONTENT:<\/strong> 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\u2019s a way to ensure you are always getting better at what you do.<\/p>\n \u201cWe\u2019ve been using the terminology, but it\u2019s just now starting to take hold,\u201d said Lance Knight, senior vice president at ConnectALL, an Orasi company. \u201cI can go in and solve my release process and improve my release time, but if I don\u2019t 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.\u201d<\/p>\n As organizations should with any relatively new concept, we\u2019ll step back to the beginning, and start with the question: What exactly IS value stream management?<\/p>\n Eric Robertson, vice president of product management and strategy execution at CollabNet VersionOne, defines it this way: \u201cValue 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\u2019re delivering aligns with the business objectives, and you\u2019re being effective there.\u201d<\/p>\n For sure, there is still some misunderstanding<\/a>. ConnectALL\u2019s Knight said, \u201cGo to a conference and say, do you know what value stream is? I bet you most of them aren\u2019t really going to understand, because values stream management is, it\u2019s about all that Lean [manufacturing] stuff. There\u2019s 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\u2019s no one tool that\u2019s going to map and remove all your waste. So, that\u2019s the reality, where people are taking point tools, and doing point things, but they\u2019re not taking a holistic value stream look, end to end.\u201d<\/p>\n On a manufacturing floor, where the production design and method of a particular widget doesn\u2019t change often, it\u2019s 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. \u201cYou have to account for that when you\u2019re looking at value stream and software,\u201d Knight said. \u201cWhat\u2019s 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\u2019t it anymore; it is all digital focused.\u201d<\/p>\n Alex Tacho, product manager at CloudBees, said, \u201cThe manufacturing process is pretty linear, with clear dependencies \u2014 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\u2019s 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 \u2014 maybe as much as a century \u2014 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.\u201d<\/p>\n Where to begin?<\/strong> 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.<\/p>\n Carmen DeArdo, senior VSM strategist at Tasktop, said value stream creation and management starts in the ideate space. He explained, \u201cWe set up teams and we say, \u2018How do things start? Let\u2019s just talk about features and defects.\u2019 Features don\u2019t 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\u2019s not in creative release. It\u2019s 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\u2019s just the beginning of the journey and you have to continue that journey.\u201d<\/p>\n 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.<\/p>\n \u201cThe 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,\u201d CollabNet VersionOne\u2019s Robertson said. \u201cAnd then, how can I streamline that, because you can\u2019t improve what you don\u2019t know. It\u2019s really about understanding that current state, that process, that flow of value, understanding how it\u2019s being delivered, and then looking at how that can be optimized.\u201d<\/p>\n 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. \u201cThere\u2019s a big disconnect there,\u201d Robertson said. \u201cUnderstanding state, your process, how people interact with that, and the tooling, and then going from there.\u201d<\/p>\n 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. \u201cThe 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\u2019re 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\u2019s 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.<\/p>\n \u201cThe whole point is, do value stream first. Map your value stream so you at least understand what you\u2019re doing. If you do Agile, what you\u2019re saying is, great, let me break down my features into smaller buckets. That\u2019s good. But it may not be where your constraints are. If you\u2019re doing DevOps, you\u2019re saying let me automate as fast as possible from check-in on to deployment. That\u2019s great, but that may not be where your bottlenecks are.\u201d<\/p>\n CloudBees\u2019 Tacho said it is important for organizations to first define what they want to accomplish \u2014 whether that\u2019s improving quality, delivering software faster, working more efficiently, or some other goal \u2014 what some are calling the \u201ctrue north\u201d 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.<\/p>\n 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. \u201cThe 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,\u201d Tacho said. \u201cBut they should also be able to make changes to the process in their domain to make it more efficient or to fill a gap \u2014 which is the whole idea of this exercise in the first place.\u201d<\/p>\n 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. \u201cNow,\u201d he said, \u201cyou have the beginnings of a value stream.\u201d<\/p>\n In order to be successful, though, Plutora\u2019s Keyes said, \u201cthey\u2019re 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\u2019re 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.\u201d<\/p>\n The people factor<\/strong> Tasktop\u2019s DeArdo acknowledged that many in the organization will be cynical about value stream \u2014 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. \u201cWhat\u2019s 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\u2019s what motivated people. If you can take a team that\u2019s notorious, and that has the street credibility and you can turn them into an advocate for what you\u2019re doing, you know you\u2019re on the right track. That\u2019s going to drive more loyalty than anything else … people wanting to be a part of something.\u201d<\/p>\n Another factor for successfully implementing value stream methodologies is making sure the leaders understand their roles in making it happen.<\/p>\n Knight sees leadership as being responsible for visibility into the system, and gaining knowledge from that visibility. \u201cToo often, the CIO, will go, \u2018The business has asked for this. When can you give it me?\u2019\u201d Knight explained. \u201cAnd the next thing you know, four years down the road, they say, \u2018You promised me this a year and half ago.\u2019 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\u2019re going to get it, that is the message everyone will align to.\u201d<\/p>\n 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\u2019s \u201ctrue north\u201d and values are different. So how can an organization tell if it\u2019s being successful in implementing and utilizing a value stream?<\/p>\n CloudBees\u2019 Tacho said it doesn\u2019t matter how organizations define value. \u201cIf 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.\u201d<\/p>\n According to CollabNet VersionOne\u2019s Robertson, \u201cThe 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 \u2014 waste \u2014 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\u2019s where a lot of the folks are struggling.\u201d<\/p>\n 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, \u201cIt is evolving. But you\u2019re not going to see a value stream transformation. You\u2019ll see a DevOps transformation, you\u2019ll see an Agile transformation, you\u2019ll see business agility transformation. You won\u2019t see a value stream initiative on the books. But what they\u2019ll 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\u2019re undertaking.\u201d<\/p>\n Why now?<\/strong> \u201cIn 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,\u201d Robertson said. \u201cBut 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 \u2014 CI\/CD \u2014 and they were about to automate things around workflows. But it was still very disconnected; they weren\u2019t able to track that work in progress, all the activities and touch points. They could do it technically, so they can can tell you, \u2018We delivered five releases this week,\u2019 but really the business was saying, \u2018What does that really mean to us? What does that mean to my initiatives and objectives that I\u2019m trying to drive?\u2019 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\u2019t 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\u2019re delivering, was that missing gap.\u201d<\/p>\n Matching up development to company objectives and initiatives has been difficult to do. Plutora\u2019s chief marketing officer Bob Davis said, \u201cWe get the value of Agile and DevOps, but look what\u2019s happened. We have distributed organizations, it\u2019s difficult to collaborate, to sync up across multiple methodologies. I\u2019ve got a mobile banking application, and I\u2019ve 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\u2019re seeing now.\u201d<\/p>\n And that\u2019s what value stream management is trying to provide.<\/p>\n Project to Product… What does that even mean??<\/strong> Isn\u2019t a project merely a part of a product? It is, but there is so much more to a software product than the code.<\/p>\n
\nCreating a value stream map<\/a>
\nHow does your solution help organizations on their value stream journey?<\/a>
\nA guide to VSM tools<\/a>
\nLosing command and control…and living with it!<\/a><\/p>\n
\nSo you\u2019ve done your evaluation, decided creating value streams will greatly benefit your company, and you\u2019re ready
\nto go. But where do you start<\/a>? As always, opinions vary.<\/p>\n
\nAn 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.<\/p>\n
\nA 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 \u2014 what CollabNet\u2019s Eric Robertson calls \u201cthat concept to cash aspect.\u201d<\/p>\n
\nIn 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\u2019re doing.<\/p>\n