Skip to main content

Value Chains and Value Streams: Strategic Maps Are Better For Project Inception

I was working on some training materials this week, and I needed to whip up as-is and to-be business process maps.  These would be used to help trainees visualize how the software they were going to build in an agile way during the training would transform the fictional business for which it was being written.

I got completely mired down in this seemingly simple task, and I realized it is because the more you think about it, the more the business process mapping for the purpose of planning a software project is just not simple.

BPMN 2.0

If you're like me, you are probably thinking, "well gee, just throw together some circles, rectangles, and arrows, and you're done, what's the big deal?"  Indeed, I started down this track, and in the name of being professional, I spent an afternoon this week familiarizing myself with Business Process Modeling Notation (BPMN, currently at version 2.0).  I became fairly adept at BPMN, which is very nice for creating process flowcharts, and tried out a very cool tool, Lombardi Blueprint, which keeps track of all the arrows for you (as MS-Visio and OmniGraffle do not).  Blueprint also ensures that you create "legal" process flows, which means that each process has a single starting point and a single ending point, and within the process, each box has one or more entering arrows, and only one exit arrow.

Armed with a new knowledge of circles, rectangles, arrows, and a very nice "clock" widget, I quickly mapped all of the business processes relevant to the software process, and thought how handy the flow charts were going to be when planning scenarios and stories for the software
But that's when it hit me--what had I done?!  My "business analysis" was predisposed to think of the business process as a set of manipulations of database objects which could potentially be automated, and the moment I had chosen the BPMN flow-chart as the tool I wanted to use to map the business, I lost focus on the actual business problems which were spurring the need for new software in the first place.  I was describing "as-is" and "to-be" from a systems perspective without providing any particular way to notate why "to be" was going to be better than "as is," except perhaps by showing some rectangles being eliminated through software creation.

Here's where I entered the world Dan Woods describes aptly as "Stalking and Capturing a Business Process."  I didn't want to start with procedural details--I wanted to understand in plain words what the company was trying to do, and where the pain points were.  I wanted to talk about value and strategy.  For this fictional widget company, it turns out, there's an inventory problem customers run into when trying to buy widgets.  You might guess that when you see the clock in the diagram, but the problem doesn't leap out at you.  I wondered whether other maps might do a better job at visualizing pain points.  I found two, which I'll race through here--I think I might need to write something longer one day, to do this topic justice.  (who knew?  I need to write a book!)

Value Stream Mapping

Mary and Tom Poppendieck lay out Value Stream Mapping in Chapter 4 of their awesome book, Implementing Lean Software Development.  For their purposes, mapping should start with a customer demand, and work back from there to show all the steps that lead the company to meet the customer demand.  A business process map looks something like this, and can be developed with a process the Poppendiecks describe, and which is also nicely laid out step-by-step in Ron Periera's Lean Six Sigma blog:

Note that this value stream map focuses on things which occur which impact the cost and timing of delivering goods or services to the customer, focusing on the customer.  Although it may be necessary, in Periera's example, to eventually create and describe an object model which includes customers and peanut butter sandwiches, creation of a flowchart which traces the movement of those objects is secondary to this first business process map, which looks primarily at strategic value and what may be getting in the company's way in delivering it.

Value Chain Mapping

Value Chain Mapping was first developed by a Harvard professor, Michael Porter (and in fact you can find out a lot about it by doing an internet search on "Porter Value Chain." )  Value Chain Mapping provides a more rigorous checklist of topics to evaluate in mapping business processes, and is likely appropriate when looking at a larger company than my widget store or Periera's peanut butter sandwich factory.  Porter formalizes the different areas which come into play with any company of size, in delivering a product or service to a customer.  Like value stream modeling, value chain modeling looks at the process that takes raw materials and converts them into something beyond what the customer could build for himself without help, and evaluates where and how value is added.  Here's Porter's scheme:

There's quite a good free web site describing value chain analysis here.

The Bottom Line

I apologize for flying through this quickly, but I wanted to put a bit of an outline out for people who are interested--the bottom line is that the type of mapping you do will heavily impact the way you think about problems.  As usual, I'm pushing tools which may help us to think more about strategic business value, at least at first, during project inception, and less about the systematic steps to improve it.

Author's note:  It's no coincidence that BPMN is embraced first and foremost by software engineering companies like Oracle who can handily map it to Business Process Engineering Language (BPEL), and thereby create the framework for a Service Oriented Architecture (SOA) software solution.  Further, it's no coincidence that the BPEL created this way is generally described as "not human readible," and that nobody has come up with a way to map BACK from BPEL to BPMN.  I would like to think that it simply stands to reason that the governing body which owns BPEL and BPMN (and UML, for that matter) has the acronym OMG.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…