Complex systems are characterized by dynamic relationships between their related components. It is not enough to look at individual components alone. A system is not merely the sum of its components; instead, it is an integration of its components, their relationships, and the interconnections between them. Systems thinkers start with this holistic view.
It is precisely because we respect people that we must strive for good systems. It is no good telling people to improve when it is the system causing much of the failures and especially if the people don’t have any control over their system.
Consider these two examples of coding and testing.
- In one case, a programmer works side by side with a tester. As the programmer writes code, she runs her own tests, and the tester runs additional tests. Together, they develop an understanding of what to do. Their teamwork enables coding and testing to happen virtually simultaneously. Discovering and fixing bugs could be done quickly.
- In another case, there is a group of programmers who have a group of testers to validate their work. Testers do their testing one week after the code is written. This means at least a one-week delay before bugs are discovered. This makes it both harder and more time consuming and expensive to fix bugs. It leads to longer delays and more miscommunication.
What accounts for the difference in productivity and code quality? The system.
Management must make system improvement a priority. They must work with the people doing the work, who typically know more about how it affects them than anyone else, to see how to improve it.
Jack Clemons, vice-president of Lockheed Martin Corporation, observed, “The system always votes last.”
Systems thinking does not say to attend to the whole system all at once. Look for delays. As a coach, we can work with people to ask, “Which parts of the system do I need to attend to at the beginning?” And make steps incrementally.
Starting a Transition
The decision of how to start requires us to acknowledge the following reality:
- People want a well-defined place to start.
- We are finite: we can’t do everything.
- Some things will change the environment within which people work which will make other things easier to change.
- We must attend to the nature of our work.
- We must respect our culture and where we are.
- Our best starting point is likely somewhere between doing nothing at first to jumping to a predetermined solution.
The first step is to look at which layer at which to start: business stakeholder, program or team? It is useful to see what starting at each of these levels would look like and then see which starting point would be most effective.
The mostly places to start will center around delay in the workflow and in feedback cycles. These types of delays are caused primarily by:
- Too many things being introduced into development.
- What is being introduced into development is too large.
- Colocated, cross-functional teams do not exist forcing people to wait on others.
- There are too many things in play at any one time.
- Teams are not coordinating well so that they work on related things at different times causing integration errors later.
- Developers and testers are not coordinating well.
What To Do After Starting
After teams get started, they face new challenges. One of them is that if they are successful, much of the motivation will be lost since the pain which got them started will be reduced. But this gives a clue as to how we need to guide the transition. It is not about getting better and better at our practices. It is about getting better and better in our outcomes such as.
- Deliver more value faster
- Improve as a learning organization
By focusing on value, we remove the need for pain to drive us. We always strive to get continuously better from where we are, yet we can be proud of what we’ve achieved. Our shift at this point goes from practices to the outcomes we need to achieve. This enables us to explore different practices to achieve better results.