Value Stream Mapping in Software Development

0
1096
Value Stream Mapping

Lean principles of software development have gained popularity in recent years. Many modern planning frameworks promote the use of lean principles or even directly integrate them into their design. Today I want to focus more drastically on one of the tools of lean software development that became a point of attention to many companies practicing agile. This tool is called Value Stream Mapping. It gained a lot of attention last year; however, it often correlates with a lot of controversy and confusion since not everyone knows how to use it correctly. So, let’s take a deeper look and try to find out.

Let’s take a step back first and define context. As I mentioned earlier, it all starts with Lean Software Development. This is an agile toolkit, as defined by its authors (in the book “Lean Software Development“) that outlines a set of principles for project managers, team leaders, and technology managers. It borrowed and adapted the best practices of project management from the automobile industry.

One of the principles in the toolkit is called “Eliminating Waste“. The main idea behind this principle is to adjust the software development process to eliminate everything that does not add value to a product. For example, a waste in the process could be considered moving product requirements between departments, gathering requirements into a documentation that nobody reads, or developing and maintaining a feature that nobody uses.  Eliminating waste is a process of getting rid of these burdens and adjusting the development process to the level where only things are performed that are actually adding value – that is (like authors define it) analysis and coding.

Along with providing principles the authors of Lean Software Development also provide practical tools to implement the principles in real life. Tools for Eliminating Waste should provide one with an instrument to clean up the flow from unnecessary and burden processes using a specific algorithm.  One of these tools that we look at today is called “Value Stream Mapping”. So, what is that tool?

Value Stream is a timeline of all activities necessary to fulfill a customer request. Customer request in this context could be a product feature, new deployment, customer signoff or any other result that would convert into a significant value for a company. One could define it as a key delivery for company leaders and stakeholders.

Mapping of value stream means creating that timeline and first drawing it into a piece of paper or canvas to oversee the activities necessary to satisfy the customer request. It should start with the request itself and end with a delivery of the results to the customer. In between it should contain all activities necessary to execute the request along with timing specified that it takes to perform each activity. In this way it helps one to map and evaluate the full picture in its current state.

Once the mapping is complete it’s time to make adjustments. One should ask the following questions:

  1. Which activity causes the biggest delay?
  2. Which activities can be considered bottlenecks?
  3. Can I eliminate any activities on the map?
  4. Can I group the activities the way that it reduces time and adds value faster? 

Many of these questions correlate with methods and techniques used in other tools of the Lean Development Framework. For example concurrent development helps to reduce time of development activities by executing them in parallel by multiple teams. This is an example of grouping that could benefit the process.

A lot of other techniques and methods exist. The idea is to review the map, find opportunities for improvement and make adjustments. Once this is done the map could be now considered more effective and optimized.

Authors state that this exercise although sounds trivial can actually expose a lot of problems and unnecessary burdens that could be easily fixed and thus effectively improve the timeline.

Now let’s talk about the pitfalls. First of all we need to mention that often different requests can have slightly or drastically different flows depending on the nature of the request. For example, let’s say we have a customer request as a feature that implies development. Company can have multiple teams with different specializations and depending on a feature customer request can go to one or multiple departments for development. Some would be tempted to present it as a single activity like “development“ but it is important to not make such oversimplifications and outline these departments as separate map items. This will help avoid misunderstanding and confusion in future.

Another thing to mention. Many managers can be tempted to outline value stream mapping into one single map for the whole company to streamline everything. Basically, confusing this tool with creating an ultimate software development lifecycle. However, this is not what this tool is designed for. It’s better to take a request or two and focus on improving a particular area where the gains could be substantial. In this way the processes will be much easier and will face much less pushback from the participating parties.

If you want to discover this topic in full depth, please also check out the video version of this article. it is available here:

More Information about Planning and Helpful Insights

To subscribe to new content use links in About Us page. Also check out this blog for other articles related to Software Development planning!

LEAVE A REPLY

Please enter your comment!
Please enter your name here