Tempo 2.0 - Section 3.3 Value Streams and Process Flows

 

…that the greatest prosperity can exist only as the result of the greatest possible productivity of the men and machines of the establishments— that is, when each man and each machine are turning out the largest possible output.

— The Principles of Scientific Management, by Frederick Taylor, 1911.

The 20th century was a century of economic growth and technological development never seen before in the history of humanity. A significant part of the credit for this has to go to Frederick Taylor, whose book The Principles of Scientific Management, was published in 1911.

Taylor laid down the basic principles of mass production. The ideas worked well for many years, but there were hidden problems.

One thing that happened, because the idea was that each worker and each machine should produce as much as possible as much of the time as possible, was that parts tended to pile up, everywhere. Different people, and different machines, doing different things, produce things at different rates. If you produce a lot of different parts that will eventually be fitted together, you will inevitably end up with too many parts of some things, and too few of other things.

Having big piles of unused parts laying around didn’t bother people much in the early 20th century. One reason was that the economy overall was expanding, except for the occasional depression, and most of the time, the parts in those big piles would eventually be used and sold. Another reason was that the prevalent accounting model, Cost Accounting[Cost Accounting is still the prevalent accounting model. It is still a model with problems, but today there are several alternatives, who have their own pros and cons.], regarded those big piles as assets. At the time, it was a reasonable assumption that whatever you produced would eventually be sold.

“Reasonable” does not always mean correct. Those piles of parts were actually a huge risk. Having capital tied up in parts meant a company had less cash on hand. If something happened, like a depression, or just a change in what the market wanted, the parts might become worthless, and the company stuck with them would suffer a huge loss.

Using an inherently wasteful production system also meant huge economic barriers to entry for new companies…unless someone could figure out how to make a small number of products with a much smaller investment.

Eventually, someone did.

The quality guru W. Edwards Deming is considered one of the greatest management experts of the 20th century. Deming traveled from the US to Japan in the early 1950’s. He taught both managers and engineers statistical methods to improve quality. However, there was something that Deming considered even more important.

Deming taught how to view a company, and the environment it operates in, as a system. He summarized what he taught in a simple sketch.



Figure: Deming’s view of manufacturing organizations as systems.

Deming’s simple sketch was the start of a revolution. Deming described a flow of materials, a value stream. He also described feedback. Information is retrieved from customers, and fed back into the process.

In 1950 Japan was a country in a deep economic crisis. The industry was obliterated during World War II. Nobody knew how to rebuild the country again.

Deming’s sketch held the key to the Japanese economic miracle. In the West, mass production based on Frederick Taylor’s Principles of Scientific Management reigned supreme. There was no way that a poor country like Japan could make the investments necessary to build an industry based on mass production.

The Japanese decided to change the rules, and play a different game. They would outmaneuver their stronger opponents. While Western companies were built around the functions needed for manufacturing, Japanese companies like Toyota and Honda decided to organize around the process flows companies need.

Value Stream became a central concept. The idea was to look at value streams from the perspective of the customer:

What does the customer want to get out of the process?

Looking at the process flow, the value stream, from the perspective of the customer made it possible to divide the flow into value adding time and non-value adding time. An astonishing discovery was that in most processes, only a small part of the time was value adding time. Most of the process time was non-value adding time, and the Japanese companies worked hard to get rid of it.

Getting rid of non-value adding time made it possible to produce things in much smaller volumes than mass production systems, with much smaller investments, and still make a profit. The feedback loop from customers meant that initially shoddy products would be improved over time. Eventually, they became good enough to turn quality into an additional competitive advantage.

Deming’s sketch represents the smartest business strategic move of the 20th century. To be clear, Deming did not, on his own, save Japan’s industry. Nor was he the only one who had bright ideas. The Japanese economic miracle was a lot more complex than that. Still, Deming’s sketch sums up the basic idea in a way that is easy to understand, even if it is a challenge to implement it.

In the West, we never really got it. For a long time, we continued to base our industry on the outdated mass production model. Scientific Management is so integral to how we think that most people who use it don’t even know its name. It’s the only way we know, so there is no need to distinguish it from anything else.

Our terminology has changed. Talking about value streams is popular today, but if you look closely at organizations and processes, they are often built around the old way of thinking. Many companies have redesigned their factories, but even then, the administrative processes, distribution networks, and management paradigms, are often based on Taylor’s ideas.

In the same manner, there is a lot of talk about the “customer”, but what is meant is often the next step in the value stream, not the customer who will use the product or service. This twists the whole idea of thinking in terms of value streams.

The tendency to adopt new terminology, without really changing anything, means a lot of good opportunities are lost. The purpose of this book is not to convince you that any particular idea is better than everything else. I do want you to appreciate the importance of new ideas, and I want to emphasize the importance of understanding ideas, rather than blindly following recipes. The reason is that implementing a good idea requires adapting it to your situation. To do that, you need to understand both the idea, and your situation. Blindly following a recipe for success, is actually a recipe for failure.

Takeaways

• Optimizing each part of a process often leads to sub-optimization of the whole.
• If you do not know which management paradigm you are using, you are almost certainly using Scientific Management.
• Scientific Management will get you, and your company into trouble, unless you have a deep understanding of its merits and limitations. It is safest to assume that you don’t.
• Understanding value streams is a key to understanding production systems. Do not make the mistake of believing it is the only key!
• Building organizations around value streams makes it easier to optimize processes than building organizations around functions.
• Process flows can be divided into value added time and non-value added time. Non-value added time is bad, so try to get rid of it.
• The customer is the user of the product, not someone in the production process.
• Adopting value stream terminology does not make your organization focused on value streams. Building, or rebuilding, your organization around value streams does…but watch out for innovative ways of screwing things up.
• Learn to appreciate the value of new ideas, but don’t be so open to new ideas that your brain falls out.
• Implementing ideas requires adapting them to your situation, and that requires understanding both the ideas and your situation.
• Following recipes for success, is a recipe for failure.

Tempo 2.0 - Chapter 3.2 Properties of Systems

This is a draft version of a section in Tempo 2.0. Please do comment.

Even simple systems can be difficult to understand. It is not because systems are inherently difficult to wrap your head around. The problem is our brains are trained the wrong way. Fortunately, it is not all that difficult to re-learn. When we do that, many problems that have looked utterly incomprehensible before, are suddenly fairly easy to understand. Doing something about them may still be difficult, but at least we have got a start.

For starters, we will define what a system is:

• A system is a set of connected parts, real or abstract, that form an integrated whole.
• Systems have some interesting properties. For example:
• Systems consists of parts, that are also systems.
• Systems always belong to larger systems.
• Systems have properties that do not exist when you examine the parts separately.
• You cannot understand a system just by studying the parts.
• When you do something with a part of a system, other parts will nearly always be affected.
• When you improve part of a system, the system as a whole may get worse.
• Systems with many connected parts usually have only a few degrees of freedom.
• Cause and effect in a system can be separated in time. When we talk about organizations, time delays can be years, decades, or even centuries.
• Cause and effects can be separated in space. It is common that a problem in one part of an organization is caused by a solution to a problem in a different part of an organization.
• Systems that are not continuously improved, will degrade on their own. Organizations often find that the world around them changes faster than themselves. The organization therefore becomes less, and less, adapted to the world around it. When the gap between the organization and the world around it becomes too large, the organization dies.
• Things can happen without having identifiable causes. Events can also have effects that are not predictable. Instead, the relationships between parts are statistical trends and dispositions. This is a biggie, because when you are dealing with this kind of a problem, almost everything you have learned in traditional management courses and training, will push you into doing the wrong thing. Though this sounds frightening at first, you are in no way helpless. There are things you can do, and those things can be highly effective.

Leading or managing a system as if the parts are independent of each other does not work well! When we improve part of a system, the system as a whole can get worse!

For example, if your company increases its manufacturing capacity without selling more, you may suddenly find that you have tied up too much capital in stock. Sometimes that gets you into a lot of trouble. Goodbye company!

Figure: Management thought they would increase capacity by increasing the number of people in the project team. Instead, capacity dropped like a rock.

Sometimes, it is less obvious what will happen. A mistake I see over and over again, is when management adds people to late software development projects. What often happens, is that the production capacity goes down instead of up.

The picture above is from production velocity measurements I made in a project several years ago. Both before and after, I have seen the same thing happen in many different projects. It is a problem that can be easily predicted, and prevented, or, if it has already happened, it can be fixed. Fixing it afterwards, is more difficult though.

Right now, you are probably thinking “That can’t be true! If it was, no project should have more than one person”. The answer is that it is not an either or situation. Adding more people has very different effects depending on the situation, and on how you add them. Sometimes velocity goes up. Sometimes velocity goes down. Sometimes, you will notice no difference.

If you know the basic principles involved, and if you know a little bit about the situation the team is in, and how the team is organized, figuring out what will happen is quite easy. It is also easy to measure the results of actions you take, to see if you found the right solution. Easy, that is, if you know how to do it. That, among many other things, you can learn from this book. We’ll take it one step at a time though, so back to basic properties of systems.

Because every part in a system is connected to one or more other parts, it follows that we cannot optimize one part without affecting other parts. As we saw in the graph above, the effects of optimizing a part can be a bit counter-intuitive.

Most of the time, cause and effect are easier to understand, but we keep shooting ourselves in our feet anyway. In software development, we often track how long it takes to finish each piece of work. We then push software developers to finish each piece of work faster. When we do that, quality goes down. The code gets more complicated, and there are a lot of bugs. Working with complicated code takes a lot of time, and fixing errors in complicated code also takes a long time. As a result the entire project slows down, because someone pushed the developers to speed up.

How much can you speed projects up by optimizing the whole? Back in 2010, when I wrote the original version of Tempo! I wrote that optimizing the whole instead of the parts could lead to delivering 500% faster than with waterfall methodologies. Since then, a lot has happened.

The original assessment by Jeff Sutherland was based on a single team producing software. Nowadays, I mostly work with programs where many teams collaborate. That makes the effects of sub-optimization much greater. I have seen multi-team programs where an estimated two weeks of work takes two years, or more.

You might think that is an extreme case, but no, it isn’t. What is even worse, when it happens, entire organizations go into denial. You hear people, otherwise very smart people, claim that a two year lead time is perfectly normal. They claim that even if it is a long lead time for a single piece of work, it does not matter, because they are going to deliver everything at once.

As a result, companies lose the revenues they would have had from early partial deliveries. Risk increases, because nobody knows if that big batch of software that will be delivered all at once, will work, or if it was what the customers wanted.

The more complicated our companies, their environments, and their products become, the worse traditional methods for managing them become. Traditional methods of leading companies, and planning what they do, are quickly becoming obsolete.

There are fields of science that helps us understand complicated and complex systems: Systems Thinking, and Complexity Thinking. You will encounter both of them in this book. I will do my best to present them in ways that are practically useful, and as easy to understand as possible, without being dumbed down.

One thing we have learned, often very painfully, is that there are no “best practices” that always work. Most of the problems you are facing today, are caused by the solutions of yesterday. You can be pretty sure that many of the problems you will be facing tomorrow, will be caused by the solutions you create and implement today.

Complexity Thinking and Systems Thinking help you to understand the causes of the problems you are facing, and make it easier to find solutions. They also give you a little bit of insight into what problems your solutions might cause in the future, and can help you reduce risks, and create opportunities.

Strategic Navigation, the business strategy framework this book is about, is based on a military strategic framework, Maneuver Conflict, created by Colonel John Boyd. It is an open system, based on systems and complexity thinking, that works well with several other frameworks and methods. You will encounter the ones I use in this book.

There is one thing I would like to encourage you to do:

I will introduce several frameworks and methods in this book. That means, I have picked and chosen parts I believe are useful to you, but by necessity, there is a lot I have left out. Do go look at the sources!

This book is a starting point. It is not the management book to end all management books. There is much more in-depth knowledge that you will almost certainly find useful, so embark on a journey of your own to find it. You will have to learn for the rest of your life, so make it interesting and fun.

It will be worth the effort.

Takeaways

• A system is a set of connected parts, real or abstract, that form an integrated whole.
• Systems always belong to larger systems.
• Systems have properties that do not exist when you examine the parts separately.
• You cannot understand a system just by studying the parts.
• When you do something with a part of a system, other parts will nearly always be affected.
• When you improve part of a system, the system as a whole may get worse.
• Systems with many connected parts usually have only a few degrees of freedom.
• Cause and effect in a system can be separated in time.
• Cause and effects can be separated in space.
• Systems that are not continuously improved, will degrade on their own.
• Things can happen without having identifiable causes.
• Events can have effects that are not predictable.
• You, your family, your team, your department, your company, the location where you live, your country, and the world, are all systems, and they are connected, and can and do affect each other. You cannot control or accurately predict how they interact, but you can influence, and make educated guesses.
• This book is a starting point for learning.
• You will have to learn for the rest of your life, so make it interesting and fun.