Saturday, July 15, 2006

Systems Thinking

Systems thinking is a theory that argues that social systems must be studied as a whole. It is impossible to predict the effects of the whole system by studying its parts in isolation. A "social system" can be anything from a family unit, to a system of interacting economic units (companies, countries, etc.), or even an ecological system.

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 Diagrams

Systems 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.

Thursday, July 06, 2006

A Manager's Mind is a Strange Place

A while ago (in another company than the one I work for now) I worked for a company that did not believe in making things easy for their developers. Everyone had to work in an open landscape. The landscape was divided into rectangular cells. Developers sat at corner desks, so that developers in a cell faced away from each other. To make communication between developers even more difficult, people working on the same project were usually located in different cells.

A new and very complicated project began. We developers realized that the seating arrangements would never work. There was no way we could succeed if we could not talk to each other. We decided to ask our department manager for a project room of our own.

The department manager realized that we needed to work close by to have the slightest chance of success. "OK," he said, "you'll get the room, for this project, because it is an unusually difficult one, but of course you can't get one every time you need it."

Read the previous paragraph again. What do you think went on in the manager's head?

Tuesday, July 04, 2006

The Variance Trap Images and Animations are Back

A couple of people have emailed me about missing images and animations in my Variance Trap series of postings. The broken links were due to a reorganization of my web site. I have finally fixed the problem. You can view the postings here: Part 1, Part 2, Part 3, Part 4, Part 5.