Sunday, January 24, 2021

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.

Friday, December 04, 2020

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.


Wednesday, December 02, 2020

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.



Saturday, August 15, 2020

Tempo 2.0 - Chapter 3: Your company is a system and section 3.1: The Monty Hall Problem

To manage a system effectively, you might focus on the interactions of the parts rather than their behavior taken separately.

— Dr. Russel Ackoff

Companies and other organizations are systems. All systems have some properties in common. As you will soon see, these properties can be counter-intuitive. If we rely only on intuition, we will make the wrong decision, even when we have all the information we need to make better ones.

The Monty Hall problem

We are used to solve problems through analysis. To analyze means to split a problem into parts, and trying to understand the whole by understanding each part separately. The idea is that understanding the parts enables us to understand the whole. This way of viewing the world is called reductionism, and it has been the dominating way of viewing the world in Western culture for hundreds of years.

Analysis is indeed a powerful tool, but it has limits. When we try to understand a system by examining its parts, we loose the full picture. This can lead us to making bad decisions. Here is a classic example, the Monty Hall problem:1

You are a contestant in a game show. The game show host, Monty, puts three cards on a table. All cards are face down. Monty tells you that one of the cards is a winning card, the other two are blanks.

Monty asks you to pick a card, but keep it face down on the table. Then, Monty flips one of the two remaining cards over. It’s a blank.

Now you get to choose: You can either stick with the card you have, or you throw it away and pick the remaining card on the table.

Think it over before you turn the page and read the answer. What would you do, and why? Does it matter what you choose?


Figure: A Future Reality Tree with the solution to the Monty Hall problem.

The diagram above has the solution. Read the diagram in the direction of the arrows, from the bottom, and up, to the top.

The diagram is called a Future Reality Tree (FRT) and it is one of the tools you will learn from this book. It is fairly easy to read the diagram even if you have never seen a Future Reality Tree before.

Boxes with rounded corners contain text describing reality as it is right now. Boxes with straight corners describe things we do to change reality. The ellipses mean and. No ellipsis means the content of any one box can cause the effect on its own. Note that in a complete tree, all the boxes must describe things that actually do exist. Speculation and guesswork should not be present in the diagram itself.

The four boxes at the bottom of the diagram are read like this:

If there are three cards on the table face down and only one of the cards is a winning card, and I pick a card, but I do not look at the face side, then there is a 1/3 chance I have picked a winning card.

Analysis can easily lead you astray when you are dealing with anything even slightly complicated. If you break the problem down in separate parts, you end up in a situation where you have two cards to pick from, the one in your hand and the only remaining card on the table. It is easy to conclude that there is a 50-50 chance of winning, regardless of whether you switch cards or not. Because of this, most people choose to keep the card they picked at the start.

If you follow the diagram all the way to the top, you will see that after Monty has flipped a blank card, there is a 2/3 chance that the remaining card on the table is the winning card!

Really! Please do not take my word for it, after all, I could be wrong, or even trying to trick you. Walk through the diagram yourself. Even better, go get a deck of cards, and try it out a couple of times.

The Future Reality Tree helps us combine two different ways of thinking, analysis, and synthesis:

  Analysis is breaking down the problem into parts. That is what I did when I split the problem up in little boxes.

  Synthesis means putting different ideas together to form a whole. I did that when I organized the boxes, and drew arrows and ellipses.

You can think of it as laying a puzzle. Analysis is when you look at the shape and color of each piece. Synthesis is when you put the pieces together, so we can see the entire picture.

In this book, I use one of the best methods I know to understand complicated problems, The Logical Thinking Process (TLTP). I explain how you can use The Logical Thinking Process to solve problems and develop both strategies and tactics in Part C: Navigation.

It is fairly easy to read TLTP diagrams even if you do not yet know how to create them, so I’ll use them whenever I want to be extra careful to show cause and effect, and to build logical arguments.

Like all other tools, TLTP diagrams are based on certain assumptions of how things work, and that means they have certain limitations. We will have a look at those limitations later on, when we get to complexity theory and Cynefin. The reason I mention the limitations now, is I do not want you to believe that just because I show you a really great hammer, all problems are nails. We will deal with both nail-shaped, and not-nail-shaped problems and solutions in this book.

Takeaways

  Analysis is when you break a problem into smaller pieces to try to understand each piece.

  Synthesis is when you organize and connect pieces of a problem, so you get an understanding of the whole.

  We need analysis and synthesis together to understand and solve complicated problems.

  Visual methods, like The Logical Thinking Process can be a great help when analyzing and synthesizing problems and solutions.

  Just because you have a hammer, not every problem will be a nail. The tools in this book has limitations, and to use them well, you must understand not just how and when they work, but also when they do not work.



1 The Monty Hall problem got its name from Maurice “Monty Hall” Halperin, who led the game show Let’s Make a Deal in the sixties and seventies.

Wednesday, August 12, 2020

Tempo 2.0 - Chapter 2: Strategy, tactics, and maneuver

 

This is the second draft chapter in Tempo 2.0.
Link to the previous chapter.


“We must be able to examine the world from a number of perspectives so that we can generate mental images or impressions that correspond to that world.”

— The Strategic Game of ? and ?, by Col. John Boyd

There are lots of books about business strategy. If you look closely at them, you will find that they are about many different things. Tempo 2.0 isn’t just about strategy, but strategy is an important part. Therefore, it is important to define what strategy means in this book. Strategic Navigation defines strategy likes this:

A strategy is the answer to the question: What is my ultimate objective, and what intermediate objectives do I need to achieve in order to achieve my ultimate objective?1

Thus, a strategy is a set of linked objectives, but that alone won’t get us far. If we want things to happen, we also need to do things in a purposeful manner. For that, we use tactics:

A tactic is the answer to the question: How do we achieve a strategic objective?

Strategy and tactics together allows us to make plans and execute them2.

Fig. 2-1: Strategic goals can be organized as hierarchies.

For example, one of your strategic intermediate objectives may be to deliver value earlier, so you can get paid sooner. There are many ways to do this. One tactic could be to reduce the amount of work done in each delivery cycle. Another tactic could be to do work in parallel, rather than sequentially. A third tactic could be to eliminate work that does not add value.

I decided to use this book itself to demonstrate how to deliver value early, in a manner that you as a reader can easily verify: I publish the first draft of each chapter on my blog, as I write them. You get value early, I get early feedback.

Of course, publishing all the material on my blog might undercut sales, but making a lot of money from book sales is not my goal. I am more interested in spreading useful knowledge, and I happen to like to write.

For those of you who believe there absolutely, positively, has to be a financial goal, yes, there is: So far, my books haven’t generated much money through sales. They are too specialized for that. However, they have contributed to me getting work I might otherwise have missed, so indirectly, they have been profitable.

A strategic goal and its corresponding tactics can be broken down into its own set of intermediate strategies and tactics. This book will teach you how to do that.

Sometimes the problem is that you don’t know what the problem is. All you know is that something hurts, and you want to hurt less, or something feels good, and you want more of it. You will learn how to get a handle on those situations too.

This book emphasizes merging strategic planning and implementation into a unified whole. Most strategy methods separate thinking and acting. That is a mistake I want to avoid, because just as the way you think will influence the way you act, the way you act will influence the way you think. Separate thinking and acting, and you will neither think, nor act, very well.

Strategic Navigation, the framework for thinking and doing in this book, is intended to support you all the way, with methods for how to think and how to do. What you think, and what you do, is up to you though.

The methods you will find in this book emphasize short planning and execution cycles, fast learning, and the ability to change quickly. In short: Agility!

You will learn visual planning, how to implement what you plan, how to make use of serendipitous events, and also how to tip the scale in your favor, so that serendipitous events occur a bit more often.

Strategic Navigation is a civilian adaptation of ideas from Maneuver Conflict, a military strategic framework created by Col. John Boyd, of the U.S. air force. His ideas have become very important both to military and business strategy. The ideas have also, over the past decade or so, become an increasingly important influence on agile software development, as well as the business agility movement.

In Strategic Navigation, the strategic framework, is combined with a powerful planning and problem solving tool, The Logical Thinking Process.

The original Thinking Process was developed by Dr. Eliyahu Goldratt, and is a part of the Theory Of Constraints. The version in this book is based on further developments of the method by Bill Dettmer, and to top it off, some ideas of my own.

The name Strategic Navigation is a homage to Bill Dettmer’s book of the same name. Over the years, my way of working has diverged a bit from what Bill Dettmer originally wrote, but if you read his book, which I recommend, you will recognize The Logical Thinking Process in Part C: Navigation.

Each organization is different, and that makes recipes for how to do things of limited value. Recipes will not fit your situation, and while trying to follow them might work, it can also lead to painful failure.

Your chances of success will improve if you understand how things work, why they work, when they work, and very importantly, when they don’t work. Thus, throughout the book, I will emphasize understanding, not just route doing. What you will need, is a good understanding of your organization, and the people in it, as a system, that is, a whole composed of interconnected parts.

Most of the time, how the parts connect is way more important than what the parts are, so we will spend a lot of effort on how to visualize and understand those connections.

A bunch of connected parts, that influence each other through their connections, is a system. The entire first part of this book is devoted to building a basic understanding of systems.

Takeaways

  A strategy answers the question What is my ultimate objective, and what intermediate objectives do I need to achieve in order to achieve my ultimate objective?

  A tactic is the answer to the question: How do we achieve a strategic objective?

  Strategic objectives can be hierarchically organized.

  There must be at least one tactic for each strategic objective.

  Strategic planning and execution must be an organic whole! Split thinking and acting up, and you will neither think, nor act, very well.

  Your chances of success will improve if you understand how things work, why they work, when they work, and very importantly, when they don’t work.

         In a system, how the parts connect is way more important than what the parts are.

         Your organization is a system.



1 In the first edition of Tempo, strategy was defined as “the means and methods required to fulfill the conditions necessary to achieve the ultimate goal of a system”. However, this definition conflates strategy and tactics. It is better to separate the two.

2 The definitions of strategy and tactics used here borrows heavily from the Theory of Constraints. It is one of the few definitions of business strategy and tactics that is consistent with strategy and tactics in other contexts, such as war, game theory, and games.