Thoughts on value stream mapping in IT and software development
Migrated from my old blog (2011).
—
What is now commonly known as “Value Stream Mapping” was originally called “Material and Information Flow Analysis”, that is, the idea is to understand how material moves through a system, what information is provided to support that movement, and how that information is provided. The act of creating this map, which requires observation and investigation, exposes opportunities for improvement.
Is value stream mapping a useful tool for the IT / software development world?
Is it useful to understand and visualise, through observation and investigation, how IT / software development work (i.e., change requests, product features, etc.) flows as well as how and what information is provided to support and manage that work?
Would it expose opportunities for improvement that would not otherwise be easily seen?
Answers: Yes, Yes.
But isn’t software development more like a network than a stream?
One advantage of the original phrase, Material and Information Flow Analysis, is that there is no implication of a single linear stream of activity. Using the phrase “value stream” or “value chain” does create this implication which is why the concept of “value network” comes up.
In object-oriented (OO) software development, many novices believe that object models are about modeling the world exactly. Experienced OO designers though, understand that what we are actually trying to do is represent the world in such a way that allows us to deal with our systems effectively.
So, if we want to judge a mapping approach, instead of asking…
“Is this a more precise map of what’s happening?”
… more useful questions would be…
“Does this highlight a certain type of problem more clearly than if we map this differently?”
“Does this map (with its realistic complexity) highlight problems better than a simpler map or even no map at all?”
Value stream mapping is not intended to highlight every type of problem.
Understanding and visualising work and information flow is quite effective in highlighting problems with unnecessary delays and some forms of quality problems.
There are other techniques to highlight other types of problems. For example:
- Do we have problems with skills and/or skills development? Use a skills matrix.
- What is the experience of all the stakeholders? Use an experience map.
