Systems thinking is an important part of the theoretical foundation for agile software development methodologies. I got interested in it some years ago because I kept stumbling on references to the systems thinking bible, The Fifth Discipline, by Peter M. Senge, in books about agile methodologies. Somehow, there was always one more programming book to buy first, but then I spied a copy at my parents-in-law's house, and borrowed it. After a few pages, I was hooked. Since then, I have worked systems thinking into the way I work. I have found it to be a valuable tool when trying to figure out what is really happening in different situations. With systems thinking I can answer questions like "why is the project careening out of control?" and "what can be done about it?"
I won't go into details about systems theory. Instead I'll point you to some introductory material. What I will do over the next few months is to blog about Systems Archetypes. A Systems Archetype is a pattern describing a frequently occuring system configuration.
Systems Archetypes are the business world counterparts to design patterns in software development and architecture. A manager who knows her systems archetypes has a considerable advantage when creating business strategies.
Systems Archetype DiagramsSystems Archetypes can be described using simple diagrams. The diagrams have four symbols:
From left to right, a Balancing Process is a process where a condition or an action causes a response that tends to slow or cancel out the initial action.
A Reinforcing Process is a process where actions cause a reinforcing loop that causes a snowballing effect.
An Influence Arrow simply indicates that one action or process has an influence on another part of the process.
A Delay is a time delay between cause and effect. Time delays are tricky, because they make it hard to see the relationship between an action and an effect. They also make it hard to judge how much of an action that is appropriate.
Let's diagram a simple process: adjusting the water temperature when taking a shower. This is a balancing process. If the water is too cold, you increase the flow of hot water until the temperature is right. If the water is to hot, you reduce the flow of hot water.
I have started by diagramming a situation where the water temperature is too cold. The response is of course to increase the flow of hot water (or reduce the flow of cold water, but we´ll ignore that in this simple model). The complicating factor in this simple system is the delay. The response when we increase the hot water flow is not immediate. The natural tendency when nothing happens at once is to turn up the hot water flow a bit more. If the delay is great, you might try turning it up again, or even decide that you may have turned the knob the wrong way, and reverse directions.
Adjusting the shower temperature is a specific case of the Balancing Process With Delay archetype. You can see this archetype everywhere where there is a long delay between action and reaction, for example in the job and stock markets, and when companies expand, or downsize, too much.
I hope this is enough of an introduction. I'll follow up with complete descriptions of Balancing Process With Delay and other systems archetypes.
As Systems Thinking apprentice I really look forward to seeing what System Archetypes you see when implementing Agile.
Coincidentaly, I just blogged about the importance of taking a Systems approach when evaluating Agile instead of the "practice by practice" approach to evaluation Agile that our community seems to be taking today.
Check out my blog post here.
Post a Comment