Systems and traditional thinkers?
Systems thinking is a fundamental part for Lean software development. Having a systemic view and understanding of your organization enables you to improve it in ways you never thought. Systems thinking helps you deal with complex systems, for example a system containing humans 🙂
A systems thinker acknowledges that most of the problems we have in software development are due to the system in which people work. The problems are systemic in nature!
“95% of the problems in business are system driven and only 5% are people driven.”
It suggests that the best thing to do with a problem is to make sure it cannot occur again by redesigning the system i.e. the way we interact and work together. It also means that if you focus on improving people and the way they do their work you are probably working on the wrong thing.
But what is a system? R.L. Ackoff has the best characterization I ever heard and it goes like this:
“A system is a whole composed of many interdependent parts. Every system is part of a larger system and its role or function in that system is what defines it. Its properties derive out of the interaction of its parts and not the actions of its parts taken separately.”
What the heck does this mean!? For one thing it means that in order to improve the system that we work in we cannot simply optimize its parts. Optimizing its parts will lead to a worse system performance. We therefore improve or worsen the performance of a part only if it contributes to a better performance or purpose of the system as a whole. So, in order to improve the system we must understand the purpose of the system and identify what the parts do and what functions they perform or should perform in the containing whole.
It also means that a system cannot be divided into independent parts. If you do divide a system into independent parts the system as a whole as well as its parts will lose its essential properties and as a result can no longer perform or fulfill its purpose.
Hmmm… so what? how can you use systems thinking in software development?
Testers improve testing, Coders improves coding, Scrum masters improve Scrum and so on. Well who improves the whole?… traditional thinkers?
How do these local optimizations help? These look like improving the parts taken separately to me!
How many times did you ‘improve’ things but it lasted only a short amount of time? What about quick fixes that backfired at a later time! and when was the last time you took action to improve things beyond your expertise, team or department?
A traditional thinker and a systems thinker differ in the way they think and act. Again Prof. R.L. Ackoff writes about analytical and synthetic thinking. He suggests that traditional thinking is analytical. If there is a problem to understand, divide the problem into smaller parts, study these smaller parts, aggregate the understanding of the parts into a understanding of the whole problem. and act on it.
Systems thinking is synthetic. If there is a problem to understand, find out how the part where the problem occurs interacts with the other parts in its containing whole, study how the interactions among the different parts led to the problem and finally act on the interactions and function of the parts so that the problem cannot occur again.
Let me illustrate this with an example.
Given that an organization is having to many bugs and change requests coming in from their customers and given that the handling of the bugs and change requests takes up a big portion of the organization’s development capacity.
A traditional thinker will specialize the work and optimize the parts. Focus will be on the how the work is done and on the people themselves. Bug fix teams will be introduced for handling the bugs (specialize the work). Better tools for processing and handling the work will be bought and new processes will be invented for better prioritizing and deciding on what to do and what not to do (optimize the parts).
A systems thinker will look for the root causes and optimize the whole. Focus will be on the interactions of the departments, teams and people. Incoming bugs and change requests will be studied to understand what their nature is and why they occur (root cause analysis). The interactions between marketing, development and sales departments are considered with the focus on removing the root causes even at the expense of the performance of the individual departments themselves (optimize the whole).
Software development is a system! It is part of larger system that could be a product organization, a service organization or another form of organization. We therefore need to treat software development as a system in itself and as a part of the larger system. Only then can we solve root causes and achieve lasting improvement in the organization.
I’ll end this post with, you guessed it, the inspiring R.L. Ackoff.
“Most of the time there is a cyclical rather than a linear cause and effect in problems. As a result over 90% of problems in a corporation are better solved somewhere else then where they appear.”