Understanding Value Stream Management
As a software professional you need to think about value streams
“Whenever there is a product for a customer, there is a value stream.” (Mike Rother and John Shook, Learning to See1)
Every company today is a software company, and the role of Chief Information Officer (CIO) has never been more important. But keeping the job has become much harder.
The Business demands better software, delivered faster, with zero tolerance for outages or security breaches. A CIO’s performance is no longer measured by operational efficiency, but rather by great customer experiences, digital products and revenue generation.
A successful CIO is one who masters innovation and can accelerate delivery, so the business can achieve innovation velocity and break away from competition and disruptors.
Value stream management is a holistic solution for a CIO to create greater value for the business - and prove it. It provides the only systematic method to increase speed to delivery; increase team throughput; improve product quality; and optimize for business outcomes.
What is a value stream in software delivery?
“If you can’t describe what you are doing as a value stream, you don’t know what you’re doing.” (Karen Martin and Mike Osterling, Value Stream Mapping2)
The term ‘value stream’ was born of the Lean movement to describe the material and information flow to create value. A value stream is the sequence of activities an organization undertakes to deliver on a customer need3. Customers may be external (customer-facing value streams) or internal (value-enabling value streams).
Software delivery organizations have a value stream per product, application or service.
Value streams put the customer at the center, which helps transition organizations from an internal focus to customer-focused thinking, a cornerstone of providing greater value.
Thinking in value streams also helps zoom out of the details and take a macro look at business processes in order to identify strategic ways to improve them.
Macro business process of software delivery illustrated in a value stream map
Value stream thinkers ask: How can we provide greater and greater value to our customers - through innovation - while eliminating delays, improving quality, and reducing cost, labor and employee frustration?
Lean and value stream thinking originated in manufacturing - Toyota car manufacturing, to be precise - but have become highly popularized in software delivery by the DevOps movement: With developers releasing code changes more frequently thanks to Agile practices, DevOps set its sights on getting those code changes running in production faster.
DevOps applies lean manufacturing principles to improve the deployment lead time, which “starts when an engineer checks a change in to version control and ends when that change is successfully running in production”4.
DevOps practices teach organizations to automate the repeatable and mostly linear tasks from code commit to production, similar to a car assembly line.
Lean manufacturing applied to deployment portion of the value stream
Enterprises and agencies that have implemented DevOps have reaped dramatic benefits. They’ve gone from taking weeks or months to release a new version to deploying changes multiple times per day.
However, by focusing on deployment lead time instead of on ‘time to value’, only part of the value stream is optimized, with the following consequence:
The end-to-end lead time, from customer request (or market need) to production, remains unpredictable, unmeasured and dangerously long.
Even after Agile and DevOps, organizations find themselves unable to accelerate delivery fast enough to preempt or react rapidly to disruptions from startups and competition.
So, why not just extend the lean manufacturing practices upstream? Because they simply do not apply in the same way to product development.
Jim Womack, author of the seminal Lean book, The Machine that Changed the World, famously gave this advice to Harley Davidson: "Don't try to bring lean manufacturing upstream to product development. The application of Lean in product development and manufacturing are different."
The differences between software delivery product development and deployment
Lean product development is a much less developed, researched and applied practice. It too aims to remove waste and reduce effort, but recognizes that the work during the design and implementation phase is very different from manufacturing:
At the core is the fact that you never produce the same work twice - each feature is different, presenting design, technical and economic choices at every step. Each output is unique, requiring the collaboration of a different set of practitioners to design, build and test it. And work goes through many iterations, which add value, not waste.
In contrast, the software work in the release pipeline strives to be predictable and mechanistic, with minimal output variation and no rework5.
If organizations applied lean manufacturing principles in product development, it would stymy innovation and prevent them from creating the delightful and compelling experiences customers demand.
How then can a software delivery organization optimize the end-to-end value stream, if it’s made up of two very different value stream segments?
By managing the network of activities, rather than treating it all like a production line.
Value Stream Management in Software Delivery
“There is nothing so useless as doing efficiently that which should not be done at all.”― Peter F. Drucker
It is nearly impossible to optimize a process, when there is a big misunderstanding of its mechanics. At the very macro level, the entire software delivery process may appear to be linear and therefore repeatable (to the point that there have been previous efforts to create “software factories”).
But in fact, one level deeper, the iterative creative process of software design reveals itself to be a complex flow network of planning, design and engineering communication. Work moves back and forth between contributors as it progresses through each phase, morphing, changing, and converging in a highly creative process.
The software delivery value stream characteristics
For example, during the release process additional testing is executed (security, static/dynamic analysis), and if issues are found during that stage, work will go back to Engineering.
In another common example, while breaking down the feature in the implementation process, a glaring omission in user experience is found, and work will go back to feature design.
An organization has one value stream for each customer-facing application, which in a large organization can be tens or hundreds. IT leadership understandably struggle to make sense of all that “messy” activity - to see it clearly and to extract insight from it.
To manage a value stream, there are three main practices:
Connecting the value stream
Automates the value stream
Visualizing the value stream
Illustrates the value stream
Measuring the value stream
Measures the flow of work through the value stream
There are two main challenges to managing software value streams:
- Software delivery work is invisible knowledge work. There are no physical materials to observe as they move through the value stream. It’s hard to comprehend something you cannot see, and even harder to manage it.
- Unless fully automated, transitions between work centers are informal and untraceable. Handoffs take place over email, phone, chat or face-to-face meetings. The value stream therefore exists, but only implicitly. It is not visible, palpable, tangible - and therefore incomprehensible.
The solution to seeing and managing the value stream is embedded in the tools - the platforms and applications that software delivery practitioners use daily to provision value to customers every day. The traces of the work in this latent value stream are held within these repositories. Once the tools are integrated and the flow of work between them is automated, organizations can reveal the value streams that already exist.
Examples of these tools include those used for portfolio and planning, roadmapping, requirements management, Agile planning, source control management, issue tracking, test management, release automation and IT Service Management - to name just a few.
The value stream is not explicit, visible and measurable until there is an automated information flow between the tools used by each work center.
Therefore, the IT toolchain needs to be fully integrated if you want to realize the full benefits of value stream management.
- 1. Rother, M. & Shook, J. (1999). Learning to See. The Lean Institute, Introduction.
- 2. Martin, K. & Osterling, M. (2014). Value Stream Mapping. McGraw-Hill, p. 15.
- 3. Martin, K. & Osterling, M. (2014). Value Stream Mapping. McGraw-Hill, p. 2-3
- 4. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution, p. 8
- 5. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution, p. 9