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.