I have just started writing a new book and there is a section in the introduction that I thought would be interesting to people. It's called "Systems Thinking and Complex Systems." Here is an early version.
I keep hearing that because we are working on complex systems we cannot have full coverage of what to look for. I think it is just the opposite. Because we are working on complex systems we must have complete coverage.
Complex systems are characterized by dynamic relationships between their related components. One cannot understand the system by individually looking at any one or two or three components alone. The system is not merely the sum of the components but rather it is the integration of the components, their relationships and the interconnections between them. Systems thinking starts with understanding this. You must recognize that you cannot investigate or learn about a system by decomposing it into its components. Rather, to learn how the system behaves, and more importantly, how to improve it, you must take an holistic view of the system. A system thinker can investigate components of a system, recognizing that the sum of the components aren’t the system and that investigating the system while ignoring certain components that make it up will leave a faulty understanding of the system.
One of the salient characteristics of systems thinking is that it is the system within which people find themselves contributes greatly to their success or failure. While we respect people, attention to the system is paramount. In fact, it is precisely because we respect the people that we must strive for good systems. Management must make this a priority and the people in the system, who typically know more about how it effects them than anyone else, need to be looking to continuously improve it.
The validity of this is easy to confirm. Consider the job of a programmer who works side by side with a tester. Further suppose the two of them work with their product owner doing acceptance test driven development. As the programmer writes code, he not only can run his own tests, but the tester can run any additional tests he created. The synergy improves understanding of what to do and the teamwork enables coding and testing to happen virtually simultaneously.
Now let’s look at a more prevalent system for coding and testing – a group of programmers who have a group of testers validate their work. Let’s further suppose the test team tests the programmers’ code a week after it is written. Whereas before, within a system of virtual simultaneous code and test, fixing discovered bugs is very quick, it will now be much harder and more time consuming. Yet the programmer is the same. Why the lower productivity and lower quality of resulting code. The answer is obvious – the system.
Once we recognize the importance of systems, we understand that to achieve improvement of our methods we must improve the system we operate in. But, if we remember that complex systems are interrelated, we must attend to all aspects of the system. We cannot just say “create teams” while ignoring flow (or vice versa). When we start we won’t be able to attend to every aspect in detail. And we don’t need to. Part of our attention should be to ask – “which parts of the system do I need to attend to at the beginning?”
We appear to be in a dilemma. Systems thinking requires us to look at the whole, while our limitations on beginning new things means we can’t look at everything. So what do we do? We need to be at least aware of the forces present to attend to. There really aren’t that many and most of the ones we need to start looking at center around delays in the workflow and in feedback cycles. These types of delays are caused primarily by:
Note how these interact with each other. It’s important to note that the common practice of limiting WIP directly only addresses two of the above. It's a bit naive (dogmatic?) to suggest we should always start by addressing one particular issue. Virtually every one of the above issues will have an adverse effect on the others - making for a downward spiral. Instead we must look at a variety of potential solutions (these relate to the prior list):
We don’t need to address all of these issues at the beginning, of course. But we should be aware that they exist. We can ask a series of questions to see where we should start (these relate to the prior list):
By recognizing we need to consider all aspects of the system yet knowing we must phase them in, we start at a high level and drill down only when there appears to be benefit.
 Thanks to David Snowden for his insights in this area.