For the past couple of decades, companies have been trying to do process improvement in knowledge work through projects.
After all, a better process needed a better IT system designed to support it, and the primary way we delivered new IT systems has been through projects, right? But in practice it often didn’t work as well. A project-based approach to process improvement led us to business process reengineering, to expensive and failed redesigns of processes at a large scale, and away from methods such as Lean, Six Sigma, and Theory of Constraints, which had shown their effectiveness in manufacturing contexts.
It also led to a deep separation between business process management approaches and the technology used to implement and support those processes, to such an extent that professionals in business process management and business analysis had distinct job roles and functions, even though business analysts were spending most of their time automating processes! Nevertheless, the realities of implementation forced us in this direction.
In recent years, though, the basics of delivering technology in the enterprise has changed, but business process management and business analysis haven’t caught up to this new reality. In practical terms, we no longer need to develop custom applications to automate most of what a business does—purchases of off-the-shelf or SaaS applications do most of what we need, with the appropriate implementation.
Finally, when we do need to build custom applications to support the business, we no longer need to deliver them at the end of a multi-year project. Agile methods allow for software to be improved continuously and delivered to the business at the same pace that we can change business processes.
There’s no reason business process improvement should be done as large reengineering projects any more. The governance and technology supports are there for a genuine commitment to continuous improvement in knowledge work. In short, it’s time to combine business process management and agile to drive a new wave of process-centric improvement to business. This is what value stream management looks like: using lean, theory of constraints, and other methods designed to deliver process improvement in combination with story maps and other agile tools to improve the process and the technology together.
This isn’t a big stretch—agile thinking already borrows heavily from continuous process improvement, particularly Lean and TOC (in fact, it takes more from the process improvement concepts of those approaches than it does from the product development experience, but that’s another discussion for another time). We know, from experience, that continuous process improvement works. We also know that agile software development works. What we need is to integrate the two together to address the limitations of each.
Although you’ll find the term used widely in agile literature and in business architecture, the term “value stream” originates with lean process improvement. In lean, a value stream consists of all of the activities required to deliver a product or service to a customer (specifically, an external customer). It can include one or more business processes. The point of identifying something as a value stream is that we can assess all of the individual steps in the stream to determine whether they actually create value as judged by the customer. Any activity that doesn’t create customer value is considered to be waste, and should ideally be eliminated.
That “ideally” is an important caveat. In practice, there’s work that can’t easily be eliminated, even if it doesn’t provide significant value from a customer perspective. Much of it may be needed for other reasons, including regulatory compliance, or practice constraints. However, much of it really is unnecessary work, or what Lean terms “waste”. A review of a typical process will show that about 80% of activities are typically non-value added, and those are the steps you should work towards eliminating. While Lean methods aren’t specifically focused around business agility, removing waste will lower costs and make it easier to introduce improvements and deploy new products.
That’s the key business benefit of properly managing your value streams. A lean, well-managed value stream lowers costs to deliver products and services and is easier to change in response to shifting market conditions. In practice, one of the most significant constraints on improving your value streams is the technology companies use to support them. Old legacy systems tend to have substantial waste baked in. Even processes that might originally have been lean are now burdened with all sorts of workarounds to accommodate contingencies that weren’t anticipated when the systems were designed, and they become increasingly difficult to update.
To manage the modern value stream, we have to stop treating business technology as something that follows the process and work on deploying and modifying it as part of the process. That means the value stream manager must combine process thinking with technology expertise. We need to design value streams using and deploying commercial applications whenever possible, matching them to the process objectives such that it’s comparatively easy to modify through configuration options. We need to be able to guide operational workers and managers and help them understand when custom development is a viable option (in other words, learn when that development effort really does meaningfully affect customer value).
Value stream managers will also need to work closely with external and internal product teams. They support external teams by ensuring that the back-end processes deliver on the needed customer experience and that their value streams can respond quickly to new product demands. With internal teams, they need to help those teams understand the capabilities required by the value streams and help them build systems that are flexible and adaptable enough to support rapid change.
Value stream management represents a significant competitive advantage for companies that can implement it, but it’s going to require that we get past the existing process/technology divide and prepare for a future where they work in unison.