Notes from Poppendieck “Value Stream Mapping”

Wow.  I went to Mary Poppendieck’s CodeMash Precompiler talk on Value Stream Mapping. That was great. It’s rare that I take 5 pages of notes during one conference session. To be fair, the precompiler sessions are three hours, but still, that’s much more value than I usually get out of a conference session.

I’ve condensed, but here are my notes: 

Value Stream Mapping comes from the Lean Business concepts. In most businesses, company value is measured using a balance sheet. Lean businesses think more about cash flow than balance sheet. That’s a major shift in thinking, and affects how you see everything.

Danger: major simplifications coming. I don’t want every MBA correcting my accounting analagy.

For example, your personal balance sheet is probably quite a bit better than your cash flow statement.  Your personal balance sheet will include assets like your home, cars, the future value of your education (which allows you to make more money), cash value of investments, and so on. Of course, it will also include the liabilities against any of those assets: mortgage liability, car loans, student loans, etc.

However, as you go through your daily life, you’re much more likely to think about cash flow: do you have enough cash to make the payments on those liabilities, and pay for other items you want to buy.

The problem (for you as an individual) is that many of the assets on your balance sheet are not fungible. For example, you cannot immediately exchange your home for cash. You can’t use your house to buy groceries.

The analogy works for software as well: partially done work has value (it’s more than not started software), but that value cannot be extracted until the value works its way through the stream to a customer that desires that value. Any value created but not unleashed represents waste.

Mary defined waste as “anything that depletes resources without adding customer value”. From a cash flow perspective, time wasted is a big problem. The longer it takes for value to move from concept to cash, the worse your organization is.

Look at that definition again. “Value” must be seen through the eyes of the customer. It’s not enough for you, internally, to see value. Customers must see the value, because it is customers that will pay for that value.

From this basis, Mary went on to discuss some of the most common forms of waste in software projects.

The biggest single waste is creating code that doesn’t get used.

According to a Standish Group study on custom software, 64% of specified features are rarely or never used. Only 20% are always or often used.

Therefore, the biggest possible savings in software projects is to write less code. However, we have to not write the code that doesn’t add value.

I asked how those statistics can be applied to product development. Mary explained that extra requests in product development usually comes from Lazy Marketing: people request features for dubious reasons: competitors have it, it looks cool, we need to stack up. Instead, marketing should be asked how much revenue those new features would actually produce. To be fair, asking marketing to predict revenue generated from future features is a difficult as asking developers to predict the cost of those features. But it is critically important to try. To address these conditions, developers need to be actively engaged in marketing. And, they need to push for more frequent deliveries of software. Delivery will change a customers perception of what’s important. More frequent delivery will more accurate identification of the most important issues.

The second most important waste is Work in Progress

• Features that have been requested, but not spec’ed out
• Features spec’ed, but not coded
• Features coded, but not tested
• Features tested, but not delivered.

Look at those four wastes noted above. All four of those items represent queues. Queues represent waste. They containing work in progress; items that hold value that cannot be delivered. More importantly, if the early activities can proceed faster than the later items, you quickly get into a state where your real expected delivery date for new features is “never”.  If you haven’t studied queuing theory, take a brief look here, and ponder it the next time you’re in a traffic jam.

From this, a Value Stream Map describes the flow of activities that starts with a customer need and ends when that need is satisfied.

Look at the emphasis there: It starts with the customer need and it ends when the customer need is satisfied. 

As developers, we too often sub-optimize our portion of the cycle: from feature request to build artifacts, or something similar. When you work with value stream maps, do not do that. You must work end to end in order to identify all the waste. If you don’t know how long a particular activity takes, you should make your best guess. As you present your results, others in the organization will correct any false assumptions and you’ll have a better map. However, if you don’t add some guess, those parts of the process will remain absent, and you won’t see any waste there. that means you won’t fix it. Later, as Mary reviewed our value stream maps, I found it very interesting that she spent much time on processes at either end of what was drawn. Sure enough, activities occurred before we thought the work started; other activities occurred after we thought we were done. Those activities also had waste in them.

After you map the activities, you assign average times to each activity, and each waiting state. The goal is to minimize the wasted time as a request rolls through the system (queues again). Some of the examples should significant opportunities for improvement: activities that had 3 weeks of useful value-added tasks actually took more than a year. That sounds silly, and yet, the map of the activities (without the times shown) looked completely reasonable. The act of writing down the map pointed to incredible waste that could be easily attacked, with incredible benefit.

I’m assuming that most of you reading this blog are engaged in software development activities. That means you may want to create three different value stream maps: one for product releases, one for feature requests, and one for emergency fixes. Mary said that you may find that the emergency fix is the least valuable: by the very nature of an emergency, you’ll find that process is already streamlined.

Mary closed with a very important takeaway for value stream mapping activities: The purpose of creating a value stream map is to identify the most significant source of waste in your process so that you can fix it. It is not to show how great you are. The big picture goal is to create “a reliable repeatable cycle time from need until that need is satisfied.” 

If the rest of CodeMash continues to live up to this, it will be time very well spent.