Value stream mapping as a tool for launching changes

Hello! I’m Vika Pedchenko, delivery manager at Tinkoff. I set up processes along the end-to-end value stream: from the moment the idea to implement a new functionality arises to how the client can use it.

The delivery management profession is closely associated with change, and most often it happens because there is a request or problem where you work. In this article I will tell you what problems I encountered in my work, and you can share yours in the comments

Three problems I encountered with the product

It is not clear what the stages are when selling a product. The product I worked with started out as a startup, but at some point the small team turned into a department of a hundred people. As we grew and our processes evolved, the tools also evolved and new people arrived. But only the founders had knowledge of how the product was created – a few people, and then only in their heads.

Misunderstanding between business and IT. Each side believed that it was doing well, and all the problems were on the other side. For example, business said that IT was doing something slowly, and IT was worried that business wanted to do a lot at the same time.

No involvement in change. Perhaps someone has encountered a situation where you come to talk about a problem, it is super obvious to you, and the answer is nothing. Moreover, some even believe that there is no problem.

There are different ways to solve these problems – conduct one-to-one, surveys, STATIK, value stream mapping and much more. We decided to go with the value stream mapping tool because we had three hypotheses about how it would help us:

— It will reflect all stages of product creation, and we will be able to look at all our problems systematically, rather than solve them locally.

— It will show that business and IT have related problems.

— Identifies problems for the participants in the process themselves. When we pronounce them ourselves, this is the first step towards their awareness.

To simplify, value stream mapping is a way to visualize the process of selling a product. Google suggests that VSM originates from Lean practices and even has its own annotation.

Let's imagine, for example, that our company produces lemonade, that is, our product is lemonade. For production, we go through several stages: purchasing ingredients, preparing the drink and delivering it to the client. The product creation map will look like this:

This is a simplified example, all stages can be enriched with data: adding problems, participants, time to complete each step, and so on

How we did value stream mapping

I looked at different VSM representations and decided to simplify it to fit our context:

Blue stickers are participants, green stickers are active stages of work, yellow are buffer stages or waiting stages, and pink we marked problems that may appear at any time

I then scheduled a meeting to build the VSM. Before constructing the map, it was important to determine the boundaries along which it would be built. For us, these were the stages from formulating an idea for implementation to analyzing the results of the released idea.

The participants included representatives from business and IT products. This composition is due to the fact that they were all experts at different stages of the product, which could allow us to gather a complete picture of its implementation. Plus, already at the first meeting we wanted to start solving interaction problems.

The facilitators were two delivery managers, and if I had been there alone, it would have been very difficult. The meeting took place offline and lasted six hours – this is a bunch of stickers, flipcharts, paper, tape. It was fun 🙂

The result is our value stream:

We divided everything into three parts. The first is an analysis of everything that is needed to take the task into development. The stage turned out to be detailed and the largest. The second part is development. The third is exploitation: everything that happens after the release. Pink stickers are problems, there were a lot of them, they exist at almost every stage

We analyzed each problem in turn and realized that we didn’t just want to fix them, but we wanted to change the process, because all the stages and problems are interconnected. A lot of processes were tied to the product manager, this is explained by the long analysis stage – he is involved in many steps of the process.

After the first meeting we received good feedback from the participants. Everyone noted that we really have a lot of problems, but we were able to talk about them and even find a solution somewhere.

Looking back, I understand that building VSM is 30% of the way, because it needs to be developed further.

From plans to reality

After we created the VSM, I drew the to be option, since we were going to change the stages:

Yellow stickers are potential changes, and hot pink stickers are problems that could be solved by introducing those changes.

We gathered with the same team as the first time, and I showed the participants everything that I had done. After several adjustments, we focused on the analysis phase because it is very complex and lengthy and required a lot of changes.

We planned changes to the analysis stage with deadlines and responsibilities for each item in the plan. We agreed to change the role model, describe it and make changes in the organizational structure. We talked about how we will track our ideas and where, what descriptions should be, what is at the input and output. Scheduled a weekly change status meeting and presented it to the team.

Results after all the innovations:

VSM is now publicly available so everyone can see what our process looks like. You can leave a comment if there is something wrong in the process. At general meetings, we told the entire product team about the process, and an understanding of how our product was created began to emerge.
The hypothesis was justified, and after the first meeting, IT and business saw that we had common problems. I even received feedback that the meeting helped me find a common language for further interaction.
People wanted to be part of the change, and that's the best part for me. Colleagues came and asked for help, to change something in their process, or brought their own ideas. I attribute this to the fact that people realized that they could find support and that we could really make a difference.

Life after changes

After we told the team about all the changes, we implemented them, lived with them for a while and collected feedback on these changes. Then we got into this cycle: we did something → collected feedback → corrected it again.

Over time, participants in the process began to be involved. If initially VSM was top-level, there could be large points: design, development, marketing – but now we are meeting with the participants in these processes and describing them in more detail.

Additionally, we set up the collection of metrics, in particular time to market. Due to the fact that there was no general understanding of how the product was created, and there was no visualization of all stages, time to market was considered incorrectly. We could only roughly estimate how long it would take to implement new functionality for the product. Once the data accumulates, we will see how the changes affect the metrics.

Conclusions and insights

I realized that we need to use VSM when we want to visualize our process, figure out what stages it consists of, and find problems and limitations. To build a VSM you need:

Identify problems which are in your context, and set a goal.
Set the boundaries of a product or process, according to which it is planned to build VSM. This will allow us to focus on a specific area and understand who to involve in building the map.

Determine the composition of participants. These will not necessarily be C-level people, it depends on the context. It is worth calling participants in those areas that are planned to be examined.
Plot and analyze the resulting VSMif necessary, build a process TO BE what an improved process might look like.
Make changes and collect feedback. If necessary, repeat the fourth and fifth steps.

Another insight is that VSM can be applied to any process. For example, we compiled a VSM for the complete product implementation process. There is a “design” step in this stream, but design is not just about making wireframes. A design step can be described in detail and problems in it can be identified, how to solve them can be figured out, and some system improvements can be introduced.

What else I would advise you to pay attention to:

Reasons for change are needed. If we simply build a VSM and look at how the process goes, it will not give us anything. Most likely, we will look and forget. We need reasons why we want to change something, the “inconveniences” that the current situation causes. There must be something that will allow you to move forward.
Management support is needed. Many of our changes come from the top, and this helps a lot in carrying them out. Most likely, we would not have been able to change the organizational structure without the support of management.
We need someone responsible for supporting and developing maps of the current process. In our team this is the delivery manager. I facilitate meetings, keep VSM up to date, organize and help drive change. If no one does this, there is a risk that collective responsibility will turn into collective irresponsibility.

I leave a link to the telegram channel of delivery managers IT's Tinkoff Process Improvementwhere we gather as a community, share experiences and tell you what other tools we use in our work – join us.