Extending Value Stream Mapping Notation For Value Creation Networks

..

Extending Value Stream Mapping Notation For Value Creation Networks

When I first started reading about and using lean in a context for helping improve software delivery performance, the tools I used were either classic lean techniques (e.g. value Stream mapping) or agile practices in a slightly rebranded way (i.e. my scrum board is a kanban). This was in large part due to the fact that most of the literature I was exposed to was material straight out of the manufacturing world, or the various Poppendick books based on lean software delivery, which are in my opinion great reads, but primarily focused on explaining why agile works using a lean vocabulary, rather than providing ideas around how lean can be used to extend some of the practices already in agile.

Over the last several years I’ve had the opportunity to interact with some great minds within the lean systems and software community. Obvious names like David J. Anderson, Don Reinersten, and Alan Shalloway come to mind, but more importantly the general discussion around the lean for systems and software community has really reshaped the way I think about building systems of work to support the delivery of high-quality software.

One tool that has fallen out of favor with a significant number of the community is value stream mapping. Interestingly, this is a tool I continually reach for when trying to define either the current state of the software delivery process, or to help various stakeholders come up with what the various handoffs, activities, and order of work should be for future project, future program, or to support a future organizational design. That being said, I tend to agree with those in the community that feel that the value stream. mapping notation as it exists right now contains some significant flaws. The notation is really meant for stable, serial/linear processes. There is no real way to describe different strategies to handle variability, or the non-homogenous nature of the work entering the system.

I’ve since come up with a notation to extend value stream. mapping with some simple notations that allow me to model what I perceive to be a value creation network. The notation is certainly in its alpha form, I’m sure I’ve missed a whole bunch of concepts. I’m sure they’ll be others out there that also think that the notation still leads to defining processes that are to serial in nature, I’m hoping to post some example diagrams showing popular methods and approaches that are nonlinear in nature (e.g. extreme programming) and I’ll tweak the notation as I go.

If anybody wants a stencil that I created for Omnigraffle, you can find it here. This will allow you to leverage the value creation network notation to build your own diagrams using your Mac or iPad.

Classical Value Stream Mapping Notation

the icons below represent classical value Stream mapping. This should be familiar to anybody that has done value Stream mapping before, I have limited myself to only a couple of essential artifacts. key

Explicit Activity that needs to be completed for value to be created

one of my favorites, the need for multiple activities to be completed by a co-located team, in order to deliver value

of course activities need people to get things done, color-coded for different specialties.

When people work, artifacts are created, and inventory builds up (unfortunately).

Ye old push model. Build a bunch of stuff, when it’s finished push it to the next team, hopefully they have capacity because your top-down upfront plan was so perfect :-)

or we could always allow downstream teams to pull work when they have capacity to do so, triggering that an upstream team can start work

people don’t just move inventory around, they also pass along information, this is probably even more critical to knowledge work in this for manufacturing

Extending Value Stream Mapping to Handle Non-Homogenous Work

Of course one big difference between knowledge work in manufacturing is the number of different sources of work, and how the risk, size, and knowledge required to do the work can change dynamically. Work also can break up and merge repetitively, and work can be be completed in parallel.

Here are some notations that I’ve used to try to capture some of these concepts

All knowledge work stems from a good idea

hopefully most work delivers business value, work will often come in different sizes...

occasionally there will be emergencies, let’s hope that these emergencies are small in size

business reality will dictate that some work will have a fixed date, this also varies in size quite often

any optimal system should also spend a certain portion of its work on fine-tuning/optimizing itself, keeping technologies up to date, rThis Work Can Get Really Big (and Platform Upgrades)latform upgrades)

work can become blocked, which requires management intervention

hopefully do system will also generate ideas on how to improve the work , not just generate work itself

knowledge work will frequently start as a very large concept, scatter into finer grained projects, and further scatter into releases/stories/features/use cases/etc. so that it can be completed in small atomic units

likewise knowledge work will aggregate from discrete specific units into something of business value, think of how individual user stories can merge into a business release that the customer wants

describing worked in terms of features has become increasingly popular in the lean/kanban world

a minimum marketable feature set represents the smallest collection of features that could be deployed as a unit giving meaningful business value

Notations for Knowledge Worker Interaction Patterns

Here are some patterns that I’ve observed using various different delivery models, with some thrown in from my readings of kanban and flow

an agile favorite, let’s get a dedicated team, hopefully cross functional, definitely co-located, and have that teams swarm on the various activities necessary to create value

teams can be formed as necessary from a greater pool of similarly skilled resources

there are situations (and I will argue this to death with the agile purists folks) where a cross functional team can leverage the help of external specialists for specific tasks. Think of security/vulnerability specialists, legacy subject matter experts, or masters in a very esoteric business domain. In this situation teams can pull from a pool of specialist resources for the duration require, after which the specialists go back into the pool. this is a great pattern to handle need for resources that do not have enough stable demand within any specific team to be a full-time member of that team, book still need to work closely enough at that team t that creating a downstream specialist team doesn’t make sense

a certain portion of the work requires differentiated knowledge because of business or application concerns, or there is a reasonable amount of variability in demand across numerous business channels. It may make sense to create channel specific entry points for each business client, but to back the people representing the multiple entry points with a common pool that possesses common skill sets necessary to handle the different channels of demand. This only makes sense if the multiple entry points are supported by some kind of common/cross cutting set of skills

Notation That Described Various Strategies to Handle Variability in Demand

Again reading the works of Reinersten and Anderson have helped me to articulate many of the strategies that we knowledge workers use to handle variability, having these explicitly described I think is very helpful for all the obvious reasons

if there’s one thing that lean and agile thinking teaches us, it’s not to underestimate the value of slack time. Smart agile teams reserve capacity explicitly by limiting how many hours in the day are reserved to code. The greater the cost of delay is for a particular piece of work, the more critical it is that capacity be reserved to handle variability

if work is coming into a system with various risk/priority profiles, then it makes sense to have an understanding of this demand and to load balance it. This will allow knowledge workers to drop low priority work for higher priority work whenever it comes into the system. I really like this pattern as it allows knowledge workers to reserve capacity for high priority work by making themselves busy doing lower priority work that is still essential for improvA ent

A T shape resource is a resource who takes the time to make sure he is competent in both upstream and downstream processes. Not he gets more senior the T not only gets better at his core responsibilities , he also makes sure that he can contribute in other areas as well. Creating these kinds of people cost money, and causes them to be less effective on their core capability than if they practiced at their primary concern . This however is a worthwhile economic trade-off in almost all aspects of knowledge work, due to the high degree of variability. It is very hard to predict the fact amount of work required for each skill set, requiring more senior people to have a balanced set of skills is one of the best strategies out there for dealing with fluctuations demand.

supporting 2 or more different teams with a part-time expert is another excellent strategy for handling variability. The part-time expert spends enough time with two teams to understand the context of both to make himself useful as a part timer. When one of the teams faces a spike in demand, the part timer switches to full time (plus overtime if necessary) and significantly increases the teens capacity until things get under control

Some Other Symbols that I wasn’t sure How to Categorize¶

unfortunately some work has to get done through meetings, would it be nice if this is never so...

and the evil stage gate never seems to completely go away...

decision rules are great ways for constraining the environment so that not every decision needs to be made over and over again. Of course great care needs to be taken that decision rules do not become inflexible and permanent. I I find that a organization need to be relatively sophisticated and mature to approach this concept in an appropriate way.

Some of the best thinking from the agile world revolves around how to create automatic signaling that kicks off a automated activity based on certain events, think of continuous integration, test driven development and the like

here is a picture of the entire stencil

........

..

Value Stream Mapping Session Gone Awry

During one of our lean client engagements, we conducted half a dozen value stream mapping sessions with various groups and project teams from the client organization and this session was an interesting exercise. The session involved a large cross-functional team responsible for maintaining a very large-scale system and we wanted to get representatives involved from each stream / discipline (PM, BA, Dev, Test, Training, Architecture, Service Management, Infrastructure) to get the holistic picture. We ended up with a group of ~20 people and one of our facilitators (i.e. Jeff Anderson) decided to facilitate using a decentralized approach and handed out stickies to everyone and asked everyone to come to the wall and map out their specific processes in the value stream. This is what we ended up with:

Needless to say, I am having a "fun" time transcribing this into a visio diagram (we promised the client we would capture the value stream and give it back to them as a deliverable). Next time we have such a large group, I think I will use a different approach (lesson learned).

An Overview on Value Stream Mapping for Software Delivery

Value Stream Mapping (VSM) is a Lean process tool that can help teams to get an understanding of where some of their biggest problems are. When done correctly, value stream maps are produced by collaborative, high touch, low ceremony session that can lightly apply a structured method to identifying organizational waste and potential areas for improvement.

When conducting these sessions, I tend to focus on 3 lean tools. (It should be noted that Alexis Hui created all these fancy graphics

• Value stream maps


• 7 wastes as identified by Mary Poppendick


• 5Ys approach to root cause analysis

Value Stream Mapping

Value stream maps can be used to map the flow of work from the start of the delivery process (ex: client request) to the end of the delivery process (ex: system delivered to the client). They are similar to process diagrams, but meant to be much less detailed, but getting things into process areas.

There is lots of advice from the manufacturing world discussing how to do Value Stream Mapping in non-IT delivery context. Many of the examples have complex notations, lots of symbols and icons that may, or may not apply to the software delivery context. Folks like Mary Poppendick, Alan Shalloway, and even Kent Back recommend taking a much lighter approach, using a much simpler notation. During our session we focused on using for simple icons preprinted on sticky notes. We also asked the group to focus on giving their opinion on a couple of key metrics for each of the icons

7 Wastes of Solution Delivery
While value stream maps are being drawn, very as participants in the session will recognize obvious inefficiencies relating to bureaucracy, delays, people being too far away from each other etc. As these wastes are recognized participants can apply them to the various process boxes or inventory pieces. Shown below are the 7 wastes as identified by Mary Poppendick her book Implementing Lean Software Development: From Concept to Cash

5 Whys

As errors are identified by participants in the value stream mapping sessions it’s important to reflect on the underlying issues of these problems. In his book, Agile Software Development: Achieving Enterprise Agility, Alan Shalloway recommends using a simple but powerful tool known as the 5 whys to do root cause analysis.
While our experience has been that strictly following the five whys is not necessary to get the heart of all problems, it’s A good way to kickstart conversations when progress is stalled, and it can help apply some structure to participants who sometimes can descend into too much detail or go off topic.

Structuring the Facilitation

while the sessions are meant to be applied with an open approach, we have found that lightly applying some structure to the value stream mapping sessions makes it much easier to get newcomers who have never done by Stream mapping before the start.
The process that we used involve the following steps:

• identifying and categorizing various families of value streams


• mapping the various identified value streams into various process areas and inventories


• measuring things such as cycle time, value generation time, and waste for the various value streams


• performing root cause analysis on the areas with the worst ratio of value to non-value-added activities, performing the five whys as necessary


• developing homework for members in the sessions to immediately act upon

Categorizing the Value Stream Product Families

We asked participants in the sessions to come up with unique value streams based on attributes like

• solution size


• new builds versus enhancements


• legacy versus more modern platforms such as.net


• distinct business lines

it should be noted that in this organization these attributes cause very different processes to kick in, certainly not an ideal situation but an obvious candidate for improvement, i.e. simple standardization where appropriate.

Developing the Current State Value Maps

During our session we asked participants to map out the value streams, and I have to say despite assertions from noted and respected experts in this field, this was by no means a simple 10 to 15 minute exercise! While we tried to keeping high-level there was significant redundant processes and activities that could only be discovered by going into a reasonable level of detail.
We try to make sure that we are holistic and covering the end and process flow, from business goal setting all the way to operations and support and everything in between.

Measuring the Value Streams

After mapping the value streams, we then solicited participants to put simple measurements where they knew them, writing down on sticky notes things like cycle time, actual effort and size of different inventories. We then flagged areas where there could be significant problem areas. Problem areas could be identified by looking at things such as large backlogs, and long lifetime of inventories, processes were the wait time was large, and really large/complex process flows.

Analyzing Potential Problem Areas

We then used a combination of the seven wastes and the five whys to identify problem areas and do root cause analysis on potential solutions.

Looking at Tactical ways to Implement Improvements

At the end of the session we took a overall look at all the different various value streams, and started identifying common problems across all of these value streams. What was interesting is that even though individual value streams used very different processes, they all suffer from the same pattern of problems. These were

• an architecture gating process that was perceived to be bureaucratic, cumbersome and contained a lot of duplication


• infrastructure group that had very high turnaround times for what was perceived to be very simple requests


• an extremely long project charter/project initiation timeline, which value activities being measured in hours or days, and delays and waste being measured in weeks and months

Conclusions
the sessions were IMHO fantastically successful. Participants were eager to point out new solutions, and the opportunity allowed individuals from different organizational departments to actually collaborate together to come up with new ways of working together. I think the big differentiator between lean continuous improvement tools versus other approaches is that lean encourages the use of approaches that anybody can learn in a couple of hours or days. "Sophisticated" techniques are replaced with mechanisms that allow workers to look at and improve their own processes.

.