Value Stream Mapping SIPOC

I was this week in a workshop where we were introduced to a nice set of lean tools. 5 x why, fishbone and kano model were visited briefly, but most of the time we concentrated on value stream mapping. To share the knowledge I will tell you about it in more detail.

We used SIPOC model. The abbreviation comes from the words

• Suppliers
• Inputs
• Process
• Outputs
• Customer

In this example we were creating a breakfast toast for one of our family members. So customers in this case were husband/wife or child.

Outputs can differ if the different customers (or customer segments) have different needs. In our case the child wanted a toast with jam and special attention that the toast isn't burnt. Spouse wanted a cheese sandwich and all the facilities need to be cleaned. No crumbs.

Inputs are all the things we need in the beginning. In the toast example we need a plate, knife, jam, cheese, butter, bread (two different types) and heat.

All the inputs have a supplier. In this case we were thinking where in our kitchen they are located. Not really who made the knife. But the knife is in drawer, butter and jam in the fridge. Heat is provided by the toaster and plate in the cupboard.

Finally, when these pretty evident things are covered we can start to think about the process. WHAT activities are needed in order to create the desired outcomes? We first make a line of post-it notes that define the activities. We can label the different activities with different colors. In our case we used green for processing, yellow for transportation, blue for storage and red for inspection.

Each WHAT phase is broken down into HOW parts. For example toasting phase can be broken down into activities of setting the temperature, putting the bread into the toaster, setting the toaster on and the bread being heated.

We used heart shaped post-its to mark all the value adding phases. In any process there are activities that add value, activities that are necessary but not value adding and thirdly activities that are waste. By identifying these we can measure how much of our activities actually are value adding compared to the whole time used. This performance indicator is known as Value Added Ratio (VAR) or Process Cycle Efficiency (PCE).

PCE = Customer Value added time / Process Cycle Time

As in our example the spouse explicitly wanted to have no crumbs, we tracked all the parts where crumbs could be produced. These phases were connected with a string. This way we can only concentrate on improving those parts to minimize the amount of crumbs.

Finally it makes sense to identify your customer touchpoints. You can goof off in many parts (well, better not to too much..) but you should make sure that you handle the customer touchpoints with care. Think about what happens before, during and after the touchpoint. How does the customer feel?

There you go. A crash course to value stream mapping using SIPOC method. If you want to learn more, I encourage you to find a lean consultant or simply try it out. I know I will.

How Epics Flow Through Our Value Chain

If you are familiar with my previous posts, you probably know that I'm a Release Train Engineer. But as I've told, that's not all I do. Nowadays I'm not anymore Product Owner, but instead I try to concentrate more on being an owner for the value chain. So let me next try to describe the flow from idea to implementation.

When new (big) ideas are introduced, there are first a few prerequisites. There must be a business case. When we plan few years ahead, the idea must be profitable. Forecasted amount of revenue must exceed the direct development costs and the future maintenance costs. We also need to analyze roughly the size of the effort and amount of resources needed. Checking the time criticality and whether we have the capacity to squeeze the job through our pipeline in time are essential factors. It's also practical to check if the idea is in line with our strategy in general.

When all necessary groundwork analysis is done, our Portfolio Managemenent Team will make either a Go or No-Go decision. If the idea is approved, it will be added to a product Roadmap and scheduled for development. At this stage the idea is called Roadmap Theme. In SAFe the corresponding term is Epic.

The Roadmap Themes enter development through Release Planning (PI Planning). They are broken down into pieces that can be implemented within our release cycles and formed into JIRA Epics. After that the Scrum teams will further refine the Epics into Stories and tasks. Then they will work on them in an iterative and incremental fashion in Sprints.

Then comes the part that SAFe (to my knowledge) doesn't answer anymore. As in Scrum, there are lots of activities left for the organization to figure out. Also for releasing, there's usually a lot more than creating the software package. Even if you have managed to get your act so well together that you are practicing Continuous Delivery or Deployment (which we are not), you still need to communicate with your customers. People don't like surprises. Even if the changes are improvements, many times people will get pissed if they didn't know about the changes or asked for those.

For me the final touch for releasing are the accompanying activities. Do we have the marketing materials ready? What do we tell the customers? How do we sell them, whats the story? Sometimes we might need to train people. Or the very least we need to let the customers know about what they will get. And we need to distribute the same information internally. Otherwise communicating the new added value might be really difficult.

Product or solution might be only one layer inside a big onion. For some companies it's even relatively tiny compared to all other things. For example Supercell uses over 400 M$ on marketing. I don't think the budget for game development was anywhere near that sum.

In practice (in our setup) all these different activies for an Epic should be lead by Product Manager. S/he isn't the one who should do everything, but make sure they happen. As a Release Train Engineer and Value Chain Owner I try to ensure this happens. It is maybe worth mentioning that through SAFe, the activities related to writing software are rather well formulated and established. The cadence based thinking still needs to be implemented for these other activities.

Knitting Processes Together

Interfacing is hard. Even if you take a simple example, (well, maybe not really that simple) a software development team and think about how the information flows from the original customer requirement to an implemented feature. Here I'm assuming that there is one Scrum Team developing one product.

First there is an interface between the customer and the Product Owner. The Product Owner interprets the requirements and maybe writes them down as a User Story in the Backlog. Then the Development Team starts working with the requirements and refine them with the Product Owner's assistance. Finally they implement a new piece of functionality. Something that is hopefully close to what the customer originally wanted.

Probably many have experienced cases where everything didn't go according to the customer's plans. Product or service did not meet the expectations. Fortunately this earlier mentioned development process can be improved by collaborating and working closely with the customer. But still, things tend to get a bit harder when you scale.

Depending on how you (or some others) choose to shape your organization, you might have a set of small start-ups where every team can do pretty much everything. But quite often your operations are modelled by separating different functions and processes. And I don't think it's always bad. I'm not really that into accounting, so I prefer someone else doing that for me. Or even thought I like interacting with customers, I'm perfectly fine with someone else closing the deals and me just providing some cool new functionality.

In addition to the different functional roles, there are processes applied in these functions. And these processes interact. In sales function there's the sales process and in R&D the software development process. One of the most common pitfalls in process oriented companies are the interfaces.

Even if you apply the idea of Continuous Improvement, you are usually just optimizing one process. And even if you have a state-of-the-art software development machinery it makes no difference if you cannot get the products to customers. Or if your sales or marketing cannot find your customers and make them aware of your superb new products.

The approach I have recently been involved with is the so called Value Chains. Instead of concentrating only on the individual processes, you take a helicopter view and think about the whole chain of actions from customer need to customer satisfaction. And then examine closely also the interfaces between the processes.

Of course this approach requires a healthy amount of collaboration between the functions. And maybe someone to pay attention to the whole. Quite often we tend to just stay in our little silos and see everyone outside as, well, outsiders. But get past that! Go to lunch with your buddies at sales or go have a cup of coffee with some people working in customer service. Or if you don't know anyone there yet, go and make some new friends!