Tempo 2.0 - Section 3.4 Value Stream Maps

Mapping a Value Stream is an adventure, a bit like exploring an uncharted landscape.

If you are serious about improving the way your organization works… Let me rephrase that: If you are serious about improving any process, for an organization, for yourself, or for a friend, you will sooner or later need information about what the relevant value streams look like. You also need a simple, yet useful, way to map the information. Having that enables you to figure out where to focus your efforts.

A value stream map is easy to learn, yet very useful, tool for mapping value streams.

The purpose of a value stream map is to help you identify waste in a value stream. A value stream map tells you how much of the time that a goal unit[1] spends in the value stream that is value adding time and how much is non-value adding time.

Waste, schock, and incredulity

Schock and incredulity are common reactions the first time someone sees a value stream map. Does it really take that much time to produce a single goal unit? Do we really have that much wasted time?

The harsh reality is that in most value streams, goal units spend a lot of time waiting. Often, the non-value adding time is 99% of the total time, or more.

How can you have 99% waste in a process without anyone complaining about it?

I once worked as an interface designer for a very large enterprise software system. Designing and constructing an interface took about a week, and each connection between two subsystems had its own custom-designed interface. There were many, many subsystems, and two subsystems could have several different connections.

Interfaces were deployed once per year. The project had been ongoing for about seven years.

That meant an interface spent on average six months either in a requirements queue before it was designed, or after design and construction, in another queue waiting to be deployed. Thus, for a week of value-adding time (design and construction), we had about 25 weeks of non-value adding time.

A ratio of 1:25, means we have 4% value adding time, and thus, 96% non-value adding time.

But wait, there is more! I wasn’t the only interface designer. We produced about 60 interfaces per year. In seven years, that is about 420 interface designs.

How many interface designs did we need? One! We could have built the whole thing with one standardized interface, for example HTTPS[2], which is used for the vast majority of computer connections on the Internet. Instead of making a custom data format for each interface, we could have managed with about five standardized data formats.

Sticking to just the interfaces, we need to divide those 4% value-adding time by 420. That means we are down to 0.0095% value adding time, and 99.99% non-value adding time.

Note that we had two different types of waste:

One type was caused by having partially finished work laying around, instead of finishing the work and deploying it, so it could be used. Assuming that there was good economic reasons for building each connection, there was an economic cost attached to not having the connection.

The other type of waste was building things that should not have been built in the first place.

Of course, if you have 420 times as many designs as you ought to have, then you will need quite a lot of people to build the stuff, which means you will need more administrative personnel. The costs do not stop there, because you will need extra people maintaining all the extra stuff the project built, and there will be delays in maintenance too, which will cost even more…

A company can easily create cost cascades that plague them for decades, and the funny thing is, identifying such costs, and stopping the bleeding, is usually a low priority.

Identifying and fixing problems like the ones in the story, requires a lot more than knowing how to make a value stream map, but value stream maps are a good place to start. Sooner or later, you will have to present your findings to other people, and value stream maps are very helpful there too.

Value Stream Map Example


Figure: Value Stream Map

The figure above shows a value stream map for a software development company. It shows how a single goal unit, a user story, travels from requirements gathering to the point where customers start paying for it.

The greatest delay, 3,200 hours, is between the initial Profit & Loss estimate, and the monthly meeting where work is prioritized. The queueing time is about two years. This means the greatest delay is in an administrative process that is executed before a development team even knows there is a requirement.

It is very common in software development that the greatest delays occur before, or after, the software development team is working on a user story. And yet, most companies would, in this situation, focus on improving the way developers work.

The mistake happens because no one examines what the value stream looks like before the improvement work begins.

Reducing waste with a Value Stream Map

Some years ago, I worked with a software development team that had not released anything to production for 3-4 months. We set about fixing a number of things that kept the team from delivering, and got to the point where the team released software once every two weeks, and could release more often than that, if they were asked to.

After the improvements, how long was our lead time? It was still 3-4 months!

I mapped out what happened to a user story after the team was done implementing it. It turned out it went on to a team that both trained users, and tested the software.

The problem was that when a new piece of functionality had been implemented, they tested it, wrote training materials, and held a course in a single batch, before approving a user story for release. We very politely asked them if they could test and approve user stories before writing the training material and holding the courses.

They said, “No, problem!”

From then on, we could release software as often as the business side wanted.

The reason it was so easy to make such a major improvement, was that the team’s Product Owner was an employee at the company, and knew the people in the training and testing department really well.

I contributed my theoretical knowledge about how processes and queues ought to work, he contributed both detailed knowledge about how the processes actually worked at his company, and his power to influence processes via his network of contacts, and friends, at the company.

Neither of us could have done it alone, and that illustrates an important point: When you try to fix something, you must work with people at the company, and you must do it all the way through the change. Handing off a change plan and expecting someone who hasn’t been a part of developing it, does not work! It does not work if you are a consultant like me, and it does not work if you are a manager, or leader.

It is often difficult to get an overview of a process. Most companies are still divided into function-oriented parts, where each part is interested in its own little piece of the value stream, and little or nothing else. Most of the time, like in the story above, the greatest delays occur where there are organizational borders.

Worth mentioning that “organizational borders” does not mean just departmental borders. For example, when you have multi-team projects or programs, borders between teams can be, and often are, a major source of delays.

If you are mapping a value stream across organizational borders, you will not always be able to find someone who is responsible for the whole value stream. If so, you will have to follow a goal unit as it travels through the organization, without having approval from a senior manager. Technically, this is easy to do, but you might want to have your CV prepared, in case you find out where someone has buried a skeleton or two.

If you find someone who is responsible for the whole process, it is likely that that person does not know in detail how the process works, or where the delays are.

If you are lucky, as I have been on several occasions, you will find a friend, someone who is as curious about what is going on as you are. You might get a bit of support, but do not expect that person to take personal risks for you, especially if you are a consultant. Even if it looks to you that they could just magically whisk you out of trouble when you have found something sensitive, that is probably not the case in reality.

By the way, do not mistake the organization chart for the reality. You are liable to find that goal units travel weird and mysterious ways before arriving at their destination. I have, on occasion, found that some work items do not actually have a destination. That is, they are still produced, but the intended recipient may have disappeared in a re-organization frenzy years before.

It is part of what makes value stream mapping such an adventure.

Takeaways

●  The purpose of a value stream map is to help you identify waste in a value stream.

●   In most value streams, goal units spend a lot of time waiting. Often, the non-value adding time is 99% of the total time, or more.

●  There is more than one type of waste in processes. For example: Partially finished work waiting in queues, and building things you do not need.

●  To find waste, you need to look at the whole value stream, across team and departmental borders.

●  You need theoretical knowledge, a good understanding of actual processes, and a strong network of people willing to help you in the organization.

●  Involve people from the start! If you hand over a plan to someone who has not been involved in creating it, execution will often fail.

●  Get a sponsor within the organization if you can, but do not expect them to work miracles if you get in trouble investigating a value stream. At best, they can advice you where to be careful, and what to steer clear of.

●  Value stream mapping is a lot of fun.

●  There is a lot more to value stream mapping than this introduction. Be aware that there is a lot more to learn.


[1] A goal unit is the unit of measure you use to measure your goal. In agile software development, user stories, features, and epics are common goal units. For a car factory value stream, the unit might be a car. For an accounting system, the goal units are money.

[2] HTTPS has been around since 1994, so, even though the project was many years ago, no cutting edge technology was required.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta
Read more