Thinking about VSMs and Knowledge Work

There’s decades of evidence about the usefulness of value stream mapping and VSMs have provided significant benefits in manufacturing and business process improvements. Continuously improving flow (of raw materials being transformed into a finished product) and driving out waste (primarily delays due to waiting, defects, and overburden) has allowed lean companies to gain considerable advantages over their less efficient competitors. I’ve personally relied on VSMs in diverse industries — from slot machine manufacturing, to mail center processing, to foreign bond pricing — and seen the benefits firsthand.

However, recently, while conducting a VSM workshop I started getting this notion that VSMs may not be all they are made out to be in knowledge work. I haven’t taken enough time to deliberate and succinctly make the case, therefore, these notions aren’t solid enough to be called an idea yet.

Value Stream — Differences Between Manufacturing and Software Development

In lean manufacturing, a value stream depicts the ongoing refinement of raw materials into a finished product that is shipped to customers; however, in software development a finished product only takes shape and emerges in the late-stage “Build” activity.

  • The VSM depicts what happens in response to customer initiated demand — how raw materials are released into the manufacturing system and transformed and how information flows upstream from customers. In software development, however, most ideas do not originate from customers; instead, teams and stakeholders leverage insight from big data to come up with novel ideas of what may be of value. In software development, there is also little to no customer pull — as in you make one when the customer asks for one. More realistically, work is pushed into the development value stream as part of a periodic budgeting process.
  • Unlike manufacturing (where a customer initiates and drives the lean manufacturing process), software teams often work simultaneously on several products (and versions) with several stakeholders (internal or external). You ignore these stakeholders at great peril.
  • There is also no “done” or final end game in software development. Code, once written, has to be maintained till the product’s end-of-life — operation and support continue while the system is being tweaked or further enhanced due to evolving customer and stakeholder needs.

What flows through the value stream?

Flow here is not used in the sense of being in a state where time flies by, where you’re “in the zone” completely absorbed in a challenging but doable task. A “desirable flow” is one that allows steady, predictable, and uninterrupted movement of work through a system; a “poor flow” system, on the other hand, is characterized by fits and starts.

  • Throughout the software development cycle, stakeholders and product managers make a series of decisions about what the eventual product should be and what it should do and for whom. The process begins when someone has an initial, sometimes vague, idea. This idea is subsequently shaped, refined, and elaborated by a series of decisions made by stakeholders, PMs, POs, and teams.
    • Some of these idea-shaping decisions deal with: what to develop, when to develop, how much to develop, how to design, how to develop, how to verify, how to validate, how to deploy, and how to support.
    • Many of these decisions are made in response to experiments conducted to validate identified assumptions (think hypothesis-driven product-development). Multiple pathways/opportunities for achieving the desired outcome are potentially available. Product teams conduct experiments, evaluate the results, and determine which opportunities to pursue further — thereby potentially changing the product direction. This then begs the question, “Isn’t the efficacy of the decisions made appreciably more important than the speed at which the product is produced (i.e., the customer lead time)?” Or put another way, “the speed at which we build something is of far less importance that making sure that we build the right thing.”
  • In software development, the only thing that seems to flow, from one step to another, is the continuously refined idea together with the information used to refine it. A decision maker processes the available information (input) to make a timely decision. The output of that decision (and any associated information) then becomes one of the inputs for the next decision maker in line and so on and so forth. For example, a Scrum Product Owner makes decisions about what to build and in what order to build. The tangible result (the output) of the decision is an ordered backlog. The development team then decides on how to implement the backlog items — i.e., the output from the previous decision (the ordered backlog) serves as one of the inputs into the team’s decision making.
    • It might, therefore, be appropriate to claim that there is no flow of product in the end-to-end software development cycle. Neither is there a flow of value. Value is in the eye of the beholder — the customer does not realize any value until the final product is made available, purchased, and actually put to use (they usually don’t pay for unrealized ideas); the business does not incrementally accumulate value, either, just because some decisions have been made (prior to any build activity).
    • The software product/service is simply a tool — it has no inherent value; however its value lies in its ability to solve a customer problem or meet an unmet need. Not understanding the customer need often results in the creation of products with no value to customers.
  • Manufacturing value stream maps depict a rather simple flow of information. But knowledge work is far more complex — ideas and information flows don’t proceed unidirectionally; it is messy and more like a network of streams that influence each other and are dependent on each other. Additionally, backflows can and do exist as well.
    • You can visualize the information flow thusly. Think about all the people in your company. Then imagine that you send them all outside into a giant parking lot and ask each of them to tie a string from themselves to everyone else they interact with as part of doing their work. Remember that people can play different roles so they will likely have even more threads emanating out. Also, people often get/send information to machines (automated systems) and those repositories should be represented as well.
    • At first glance, the resulting output may look like an incoherent jumble. However, it will be the true representation of the information flows within the company — unfortunately, it will definitely not resemble the neat, clean, flow of information depicted in most VSMs.

What’s the product we’re producing?

In knowledge work, we are not creating similar widgets over and over again. Every pass through the product development system results in the creation of something new and unique. Not only that, as you learn about the customer, their needs, their desires, etc. you may at any point in the process decide to pivot and end up in a place very different from what you had originally envisioned. Experimentation enables us to discover important information that leads to the creation of new emergent solutions. The problems encountered are often unpredictable and hindsight can only tell us if there is a right answer as we explore the problem. Our ability to probe (explore/experiment), sense (inspect) and respond (adapt) is critical and serves as a crucial base for subsequent decisions.

The question begs to be asked: “Are we mistakenly treating software development (a complex issue) as lying in the ordered (clear/obvious or complicated) domain where the final product is known and standardized components/product flow in one direction to a defined end state?”

Relevancy of VSM and Lean Metrics

All of this, then, calls into question the accuracy and relevance of VSM related metrics for software development efforts. The key goal for successful product managers is to adequately meet the demands of consumers, customers, and stakeholders by solving their problems and addressing their unmet needs, wants, and desires. Maximizing the speed of development is a less important secondary goal. If utility trumps speed then what do some of the traditional VSM metrics mean in knowledge work?

  • In software development, making the right decision about what to build (next) is far more important to the success of a product (and the company) than the speed of the decision making.
    • VSMs highlight and emphasize improvement in speed related measures like cycle time or lead time. Such a focus can encourage you to rush through the decision making process, not take the time to validate (the leap of faith) assumptions, and make the wrong moves. Because we aren’t producing the same widgets over-and-over again, I’m not even sure that cycle time is a meaningful measure.
    • Changes to a product should only occur at a rate and at times that can be safely absorbed by the users. In some situations customers will be put off if you keep releasing newer versions frequently. Again, utility trumps speed.
  • Customer lead time implies that requests are coming in from customers and we try to fulfill them as fast as possible. But, today, most innovative ideas do not originate from customers; they come from development teams and data analytics — the customers only reap the benefits of such thinking.
  • Lean differentiates value-add work from “non-value add but necessary work” and pure waste. These activities are relatively easy to see and classify in manufacturing. But knowledge work is abstract, hard to see, and pinpoint. Most activities are opaque (or maybe translucent) and occur between a person’s ears.
    • In software development, critical cognitive work (i.e., thinking) may appear as idle time with no visible work taking place on an item. Yet this thinking is crucial to making the right decisions and determining appropriate next moves. Within a processing step, this “think time” is indistinguishable from “wait time.”
    • Non-value add but necessary work is often value-add work as it allows the company to stay in business. Remember, customers are important but external stakeholders matter a lot too — think government agencies and their regulations, for example. If you don’t provide these stakeholders what they want, you’re liable to be fined (sometimes severely) or even shut down.
  • Most people and companies do not track information shown on a VSM. For example:
    • Percentage of time spent on value-add activities: Not only do most people believe that the work they do is value-add work, and will naturally feel unsafe (about their job and paycheck) stating that most of their time is spent waiting or not adding value.
    • Percent Complete and Accurate: This measure reflects the quality of each step’s output and is gathered by asking each downstream consumer what percentage of the time they receive work, from an upstream supplier, that is usable as is without having to correct it, clarify the information provided, or add missing information. These interviews will not only just surface low confidence guesses but they also have the potential of giving rise to negative consequences — if people feel threatened by low scores they’ll compensate by over-documenting every deliverable (in order to minimize missing information).
  • Lastly, if people are multitasking it makes it extremely difficult to determine the touch time for any single activity.

There are other questions that should pop in mind when looking at and interpreting lean and VSM metrics. Think about the following, for example:

  • If we reduce overall lead time, does that translate into more sales and revenue and higher earnings? If not, then aren’t these just phantom improvements that don’t positively move the needle on business desired outcomes. We can claim a relationship between some operational improvement and the eventual change in a desired customer or business outcome; however, it is important to keep in mind the uncertainty in the hypothesis lattice.
  • Due to efficiency gains at any step, if we reduce the need for headcount do we lay off people or keep them around and save nothing (as Operational Expense remains unchanged)?
  • Just because the speed of a process step has increased twofold, does it mean that it is now twice as fast all the time? Or put another way, is that step actually producing twice as much during the given time period (hour/day/week/…)? Or is it idle for longer now? And does the improvement even matter if it is not the process constraint?
  • None of the measures has anything to say about whether we are building the right product to begin with.

For knowledge work, if you really want to use a VSM, create a quick back of the napkin sketch to get to a directionally correct (70-80% accurate) answer; you don’t have to spend days in a VSM workshop trying to come up with “accurate” measures.

To sum up, when it comes to Value Stream Mapping for knowledge work, the evidence for its usefulness is neither clear nor compelling. We are led to believe that speed is of the essence and that flow of material matters significantly. But what truly matters, for a company, is the ability to make the right decisions and to continuously improve its decision making capability.

We, in knowledge work, need to move beyond simplistic systems thinking — thinking about closed systems that produce the same output repeatedly — to thinking about complex and open (with ill-defined and permeable boundaries) systems with many diverse influencing factors; factors that, furthermore, affect each other and are also impacted by the systems they operate on.

One comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s