January 2005

Reverse Engineering Reality Part 2: Creating Causal Loop Diagrams

Causal Loop Diagrams (CLDs) share several things with books: they both tell stories, they can be fact or fiction, and they're both easier to read than write. Keep reading to learn how to write CLDs.

The Buddy System

The first step in creating CLDs: find a buddy, friend or coworker with whom to share the diagram. When I started working with CLDs, I didn't pay attention to this. It's come to my attention lately that I add something to every diagram that comes my way, and every diagram I send out comes back with meaningful corrections or contributions. This happens because everyone's world view is slightly different. Most world views overlap enough that we can understand each other, but are different enough that other people will think of things you don't. If you'd like, you can send me your drawings for review and comment.

If one is necessary, two may be better. At some point adding people will create more "drag" on progress than contributing "thrust" towards completeness. In a work environment completeness counts more than speed, so make sure all view points get considered. For independent work, I prefer "mostly complete" and quickness.

When sharing with your buddy, consider how you're going to present the CLD. I worked with a friend on the phone on time and tried to draw the CLD as he described his drawing. Unless you enjoy lessons in miscommunication, skip this and at least send some sort of a drawing (JPEG, GIF, PNG) they can view, print and mark up. I've found sending the actual drawing works best. For Windows users, I typically use Visio. I have a template for CLDs (using Jerry Weinberg's notation) that my friend Brian Pioreck created. When I'm working with Mac users, I use Canvas to create the CLDs. In both cases, we can change the CLD and share the results via email.

Creating a CLD usually follows these steps:

1. Find some puzzling question.
2. Think about the question.
3. List some variables related to the question.
4. Connect the variables showing how one influences others.
5. Check the CLD by reading the story.
6. Repeat steps 2 - 5 as necessary and appropriate.

What was that?

This question usually starts my systems thinking mode. I recently read an email by an author who stated "I never sign a contract for a book until the book is written." Why not? What's bad about some "up front cash"? What might be true for him to feel that way?

Thinking

Sometimes when I think, things instantly pop into my mind. Sometimes I commit the problem to my subconscious and do something else. I have favorite activities that involve my body, but leave my mind free (like bush hogging). Other activities (like Aikido, hitting golf balls) occupy all of me. In the contract situation, I received the emial late in the evening. I fired off a "let me think about this" email and went to bed.

Thinking about question the hopefully leads to a deeper understanding of the situation. If it doesn't perhaps the question is too small or too big. Perhaps the question isn't clearly stated. Try changing the question and see how it changes your thinking.

As I thought about the question, I eventually centered on writing's financial and personal affects.

Variables

Now it's time to list the variables you've discovered in your thinking. Choose things that can change. I use a laptop and word processor when I write. This doesn't change, and doesn't influence anything else. "Writing Time" changes and does influence other variables. I like to use variable names that work with "As [insert name] goes up (or down), then [downstream name] goes down (or up)." This verifies some constant doesn't slip in, and starts the next step. For this example I chose the following variables:

• Writing Goal
• Pressure to write (added on second pass)
• Writing Completed
• Writing Time
• Work Time
• Money for bills
• Personal "pot" (how I feel about myself).

Getting all the variables in the first pass doesn't happen often. The point here involves looking for hidden structures that create the observed dynamics. As the drawing takes shape, new variables appear, and old variables may not be needed. It depends on your point of view.

Which Comes First?

Since all the variables are related, and you can start reading a CLD at any point, it doesn't matter which variable gets put in the drawing first. Pick one and get started telling the story. Once in a great while I do a hand sketch. Generally I head straight to the drawing package where I can cut, paste, drag and drop. When I finished, this is what my CLD for "Why not sign a publishing contract for an un-written book?" looks like:


And Back Through

As I draw the CLD, I find myself rethinking assumptions and conclusions. This restarts me iterating through the steps. Don't be surprised if it takes several iterations to become comfortable witht the CLD. Eventually, I declare "Good enough" and quit.

The Never Ending Cycle

If you take the same variables and create a CLD you probably won't get exactly the same drawing. That's OK. I see where I can make a couple of changes. But at this time, this drawing closely represents what I think about the question.

Causal Loop Diagrams give us a method for revealing hidden system structure. Being able to read and create CLDs provides another path for sharing our current understanding.

Reverse Engineering Reality Part 1: Reading Causal Loop Diagrams

Causal Loop Diagrams (CLDs) can help us understand complex interactions and events by revealing system structure. Unlike buildings, most systems don't have visible structure. We notice systems by observing events. When the events form a pattern (usually over time), there's indication that a system is working. We use CLDs to diagram the system and reveal the interactions that lead to events. In "Learning to Change", I used Casual Loop Diagrams (CLD) to show interrelationships involved in my learning process.

Causal Loop Anatomy

Causal Loop Diagrams have four basic parts:

• Nodes (usually ellipses or circle) that contain values that can change
• Lines with an arrow show influence direction
• An inversion indicator
• Time delay indicator

These look like
Using all the parts, we can build a simple diagram.

Reading a Causal Loop Diagram

You can start reading a CLD on any node. I once sent a CLD to a friend who responded, "Don, I don't understand what you're trying to show." I promptly started telling the story (via email), but noticed that I had to start at a specific node, and by the time I was 1/3 through the diagram, my explanation fell apart. I redrew the CLD, and got my point across.

We read the above figure as follows:

• As "B" gets bigger, after a time delay "A" gets bigger.
• As "A" gets bigger, "B" gets smaller.
• As "B" gets smaller, after a time delay "A" gets smaller.
• As "A" gets smaller, "B" gets larger.

This forms a balancing loop. The system may oscillate, but will stay within limits. Balancing loops provide stability in systems.

Suppose the influence between "A" and "B" wasn't inverse. As "A" goes, so goes "B". The above figure would then read:

• As "A" gets bigger, "B" gets bigger.
• As "B" gets bigger, after a time delay "A" gets bigger.

Or the in the opposite direction:

• As "B" gets smaller, after a time delay "A" gets smaller.
• As "A" gets smaller, "B" gets smaller.

Now we have a reinforcing loop. Reinforcing loops create growth (positive reinforcement) or decay (negative reinforcement). Some people refer to these as positive feedback and negative feedback loops. Since all loops in a CLD are feedback loops, I prefer the terms "balancing", "positive reinforcement", and "negative reinforcement".

The example we've been using a simple diagram. These same basic diagramming parts can build complex diagrams. At the AYE 2004 Conference, attendees in Session 11 created a CLD for credit cards. For those wondering, Causal Loop Diagram and Diagram of Effects are the same drawing type. A CLD for credit cards could resemble



Balance seems to be in the middle of the drawing, so let's "read" that part of the diagram.

• As Balance goes up, Fees & Charges go up
• As Fees & Charges go up, Balance goes up
• As Balance goes up, Available Credit goes down
• As Credit Card Purchases go up, Balance goes up
• As Payment goes up, Balance goes down

Take a minute to "read" the rest of the drawing. No wonder Albert Einstein said Compounding interest in the greatest mathematical discovery of all time."

Some things to remember:

1. You can start reading a CLD at any point.
2. It would be equally valid to say the opposite of our list. (As Balance goes down, Fees & Charges go down)
3. A CLD is a map and should "map to the territory". If the story you're reading doesn't match the events and patterns, the CLD needs to be changed.

Different notations exist for CLDs. Some notations use "+" and "-" at the line's arrow end to show "same" or "inverse" links. Occasionally you'll see a "B" or a "see-saw" in the middle of a loop indicating the loop balances. A "snowball" or "R" indicates a reinforcing loop. The variables may not be in an ellipse. These minor variations don't change how the CLD gets read. No "UML" exists for CLDs.

Jerry Weinberg developed additional CLD notations to help understand software project management and development. These components add some richness (by showing the human part) and are:


In Jerry's notation, these have the following meaning:

• A cloud indicates a subject measure. Something known and true, but unmeasurable (due to nature or expense)
• A white box means that a human intervention is making the receiving node move the same as the originating node
• A gray box means that a human intervention is making the receiving node move opposite from the originating node
• A half-white/half-gray box means that the receiving node may move same or opposite from the originating node base on the intervention

I recommend Jerry's Quality Software Management: Vol. 1: Systems Thinking. The book builds a systems foundation for understanding software development and uses CLDs throughout the book.

Causal Loop Diagrams provide a to describe what happens in the real world. While notations differ slightly, the basics don't change. Understanding how to read one notation enables us to understand other notations.

Context is everything

Today I had the opportunity to remember that "context is everything". Hurricane Frances continues her slow crawl up the eastern United States. It started raining here in North Carolina yesterday (Tuesday 2004.09.07). This morning my radio crackled with reports of accidents and emergencies. Fortunately, none were in our response area. Then the pager tones sounded. "Squad 86 respond with the local VFD to a one car roll over. One adult and two children confirmed entrapped."

I arrived just before the rescue truck. The SUV lay on its side in the ditch. The VFD had already set up traffic control and fire suppression. Using standard rescue techniques and tools, "Mom" and the kids shortly walked out of the SUV. Other than needing to by a new vehicle, this story ends happily. But what happened? The Highway Patrol report will include some phrase like "too fast for existing conditions". "Mom" has probably drven this road most of her life. It's rained before while "Mom" was driving. But today the amount of rain, the wash over the road and her speed created a new context that "Mom" couldn't cope with successfully.


Like this accident most "interesting events" happen because someone, somewhere, at sometime, loses track of the context. Context involves us and everything we're connected to. "Involves us" includes our mental models, our world view, and our actions. We started changing at conception. We continue to change until after we die. Along the way, we grow, we learn, we change. Accidents happen when we change, but the "everything else" hasn't. Learning may create an accident that leads to personal growth. Personal growth might make us uneasy with our current friends.


"Everything we're connected to" is the environment we exist in. Our family, our friends, our career, our hobbies, everything with which we come in contact is in a state of flux. If our world view limits how we see things, we'll create accidents by missing opportunities or reacting to things that aren't there. If we hold to mental models that no longer apply to our current situation, we'll be out of context when we act. Behaving like a 10 year old doesn't work well now that I'm pushing 50.


We need to learn from accidents. Learn about ourselves, our context, how they interact, and how to keep them synchronized.

Learning to Change

In Changing Quicker we looked at reducing or removing system delays to reduce the time delay between realizing a change needs to be made, and when the change's effects occur. Another way to change quicker involves learning to change. Learning is a process that depends on experience and leads to long term changes in behavior potential. We can use Causal Loop Diagrams (CLDs) to model learning and change experiences. This provides a framework for discussing learning.

The Learning Loop

Learning involves a basic sequence of steps:

1. Deciding to do something
2. Doing it
3. Noticing the results (possibly after a delay)
4. Comparing the results to what we wanted to have happen.

We can learn from everything we do. This means the linear representation happens continuously, over, and over, and over again. General systems thinkers use CLDs to draw pictures of repeating events. The CLD for our basic four step learning sequence looks like:



You can start "reading" this CLD at any ellipse. Starting at the bottom we do things, take actions, and otherwise interact with our environment. These actions cause things to happen and information comes to us as feedback. The parallel lines on the arrow connecting "Actions in the World" and "Feedback experience" represent a time delay. The shorter the time delay between when we take action and we get the results of that action the more quickly we can learn (this would be Transport Delay in "Changing Quicker"). We compare the feedback and results of our actions with a goal, the "why we did it" resulting in a "Difference". This "Difference" in turn influences our "Decisions".

For example let's look at my goal to provide quality software services to my clients (Goal). My equipment performs reliably, so I decide not to back up the client's files on another system (Decision). Then one day, my hard drive scrogs itself and I lose the source code I've been working on for weeks (Feedback). Now I can't provide much service (much less quality service) (Difference). This Difference causes me to periodically back up the client's source files to another computer. The results of my first pass through the loop actually worked well for several years.

So now I'm happily copying sources to another computer (Action). I've modified the current source and sent it to the client for testing. Not a problem since the original is on another computer. The client asks for another change which I make on top of the existing change, which is different than the unchanged source on the other computer. The second change doesn't work I need to back out change #2 and get back to change #1, which no longer exists (Feedback). This again trips the "Difference" between the goal to provide quality service and what's happened. This influences my decision to install a version control system where changes can be conveniently stored and retrieved as necessary. I've already changed how I store client files one time, so changing how I store client files the second time becomes easier. This is single loop learning.

Change can actually happen on different levels. In the basic learning loop, I change my actions to reduce the difference between my goal and the feedback I get. What happens if I "abstract up" one level, and change how I change? This leads to "meta-change" or changing how I change. The CLD for meta-change looks like:

This drawing resembles the learning model but has an extra balancing loop (B2). This balancing loop connects the feedback directly to the decisions and enables the question "How did this change work?". This retrospective position allows me to change how I change. Would a different action create a better (smaller in this example) difference? Did the feedback lead to the results I expected? If not, why not? Does my mental model (see Choosing Change for more on mental models) for this situation need adjustment? Am I using the correct model? Meta-change adds another feedback loop increasing sensitivity to the environment and making the system more stable.

We've not answered the question, when should we introduce a "new" change?

In Anticipating Change¹, Jerry Weinberg mentions McLyman's Zone Theory based on the Satir Change Model. McLyman's Zone Theory distinguishes four "zones" during change. We receive change opportunities differently depending in which zone we find ourselves.



The Gray Zone

When a foreign element arrives in the Gray Zone, people have already lost some of their meta-change skills, for old learnings about change have lost their usefulness. Without these meta-change skills, change is once again slow and difficult, and the chance of successful change declines.

The Red Zone

The Red Zone is the time before the previous foreign element is transformed, accommodated, or rejected. When a new foreign element arrives while the system is in the Red Zone, chaos from both foreign elements increases. Moreover, the chance of ever finding a transformation for either foreign element decreases, and the likelihood of rejection or accommodation increases.

The Yellow Zone

The Yellow Zone is the time interval when a previous transformation is still being integrated. When a new foreign element arrives while the system is in the Yellow Zone, chances of successful change are reduced, but not as seriously as with Red Zone foreign elements. The system may lose its grip on the original transforming idea and be thrown back into Chaos. ... With successive Yellow Zone foreign elements, the system builds an energy debt: Successful change becomes less and less likely, and productivity drags.

The Green Zone

The Green Zone is the time between late Integration and early New Status Quo. When a foreign element arrives in the Green Zone, the system's chances of successful change are maximized.

¹ Quality Software Management Vol 4, Anticipating Change, copyright 1997 by Gerald M. Weinberg, Dorset House, ISBN 0-932633-32-3, pages 42 - 44

Changing Quicker

We finished "Change and Stable Systems with the questions: Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change? Today we'll discuss some conditions that enable quicker change.

I want to recognize I've been using two words interchangeably: systems and organizations. In this context, I view an organization as a specific type of system.

Systems contain three basic components: reinforcing loops, balancing loops, and time delays. Reinforcing loops cause growth or decline. Balancing loops interact with reinforcing loops and create stability. Time delays separate cause and effect by days, months, possibly years. These delays determine how quickly a system responds to a change.

Delays occur in several places for organizations.

Transport delay involves the time required to move information around the organization. Information that development needs to know may enter the organization in customer support. "Oh no! The Frammin module appears to be broken! It's reformatting the customers' hard drives and displaying Elbonian profanities on their monitors!" The standard hierarchical organization communications path would be up the chain to the common node, then back down the development change to the managers who decide what should be done, and then to the programmers who actually do the work.

Decision delay results from the time required to decide what to do. I used to believe that inside every complex system, there was a simple system trying to get out. I still largely feel that way, but some software systems are complex, and that's that. We've been writing software for 50 years. Most of the easy programs should be written. That leaves the difficult and complex programs. Quick decisions can spell disaster if the long and short term ramifications aren't considered. When the development managers learn the Frammin module causes problems, it may take a while to determine the circumstances surrounding the problem event, exactly what part of the Frammin module causes the event, and what to do about it.

Implementation delay is the time required to do the work. The classic line here: "You can't produce a baby in 1 month with 9 women." Some work is separable and can be done in parallel by multiple workers. Some isn't and must be done by a single person. Quick thinkers will try to create separable work. While work can proceed in parallel effort, communications (and gaps) and interfaces become issues. These issues are avoided when a single person does the work. So which answer is better?

Time delay relates to a system parameter called time constant. When the system output reaches 63.2% its next value, one time constant has passed. The following graph shows a system with a time constant of (approximately) 4.5.



By reducing any or all of the delays, we can achieve a result in a shorter time period as demonstrated by:



We've moved the time constant to (approximately) 3, or reduced the time it takes to respond by 1/3.

How do we remove delay from the system?

Transport Delay: All organizations have informal networks that pass information to where it should go. These networks are usually called "friends". Some organizations explicitly encourage this by "cross assignment." A developer works in customer service. A tester may spend time in development. Besides broadening the skills and creating an understanding of what the other person does, this creates the informal network that keeps information flowing.

Decision Delay: "Empowerment" bothers me. I actually think it's a great idea, but in many situations the idea gets morphed into an evil double bind event. Nonetheless, we're talking about empowerment. Move the decision making authority to the person closest to the information (reducing transport delay) and work effort (possibly also reducing implementation delay). The management problem resides in authority to make a decision can be delegated, responsibility for that decision can't. Maybe this causes the standard empowerment double bind.

Implementation Delay: Better people make better products. I can't put my hands on the data, but I seem to remember that Jerry Weinberg, Tom DeMarco, and Capers Jones have all released studies showing that individual performance varies by an order of magnitude. So get better people. Read Johanna Rothman's new book: Hiring the Best Knowledge Workers, Techies & Nerds (available Sept 2004 from Dorset House Books). Improve the skills and abilities of the people where you work. Send them to the AYE Conference. Improved workers will impact Decision Delay by allowing true empowerment.

Can you think of other delay causes? How can we mitigate them?

Agree? Disagree? Drop me a note: don@donaldegray.com

Change is Good

Several years ago I found out that I was not really in charge of everything, or in control of very much. This lead me to Don's Dismal Dilemma: How will I achieve my goals, when I'm not in charge or control? Physical systems follow patterns established eons ago. Friends do what suit them. My clients determine when and where I'll work with them.

As time progressed, I found the one thing in the universe I have complete control over: me. This lead me to Don's Delightful Discovery: I can't control what happens to me, but I can control me, and how I respond to what happens to me. As Virginia Satir said, "We can direct our efforts to change what we can and to work out creative ways to live with what we can't change." [New Peoplemaking, pg 7]

When we quit changing with our environment, we face extinction. We need to update our mental models so they conform current with reality. As we grow and mature, our realities change. Our mental models need to reflect the changes. Mental models formed in childhood and not updated make for interesting adult behavior. Dad warned me about getting "Hardening of the Attitudes". (Notice the survival rule that affects my change quotient?)

Changing allows me to achieve my goals. If the goal doesn’t change, and external events (by definition beyond my control) change the situation, I need to change my actions (I control these) to bring the results in line with achieving my goal. Or perhaps my actions aren’t producing the results needed to achieve the goal. Again change becomes necessary to realign with my goal. If I don't change what I’m doing, my actions will take me away from my goal.

"Insanity: doing the same thing over and over again and expecting different results." Albert Einstein

Occasionally I need to change my goals. As I learn more, what used to be important may not be important now. Changing goals allows me to work on what's important to me.

Change and Stable Systems

In response to "Change Quotients" (2004/08/10, Methods category) Laurent Bossavit laurent_at_bossavit.com wrote:

"Change quotients" prompted one particular thought - since I'm usually the person recommending a change, I tend to be more sensitive to lower quotients than mine. Yet, I do recall one organization which had an intrinsic change quotient which apparently exceeded mine - they reorganized every two weeks, more or less. :)

Your remark on how change quotient relates to system size suggests that there must be some absolutes - a reorg every two weeks may be too much for a 40-people company trying to stabilize its software processes.

Change disrupts the status quo. Change events can be external (a new competitor, government regulations, market conditions, ...) or internal (promotions, people leaving, new product lines, process improvement...). Let's call the change event, a foreign element. When a system experiences a foreign element, its output fluctuates over time until things return to normal. The following graph shows a system exhibiting this behavior.



After a foreign element the system returns to its previous output. The output varies but gets closer to and eventually achieves the desired value. (Control theory buffs will recognize this as a quarter-wave decay response to a step change in the input. I should note other desirable responses exist to step change inputs including critically damped, absolute integrated error and others.)

Now what happens when the system experiences another foreign element, say at t = 4? We'll use the same "step change" for the input. The resulting output graph looks like:



Now the system takes longer to return to the desired output level. So far changing during change doesn't look desirable. For convincing let's add one more change at t = 5 (same parameters).



These graphs apply to bounded, linear systems. I have yet to meet a bounded, linear person. People respond to foreign elements more like:



I "lifted" this graph from my colleague Steve Smith's article The Satir Change Model

Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change?

Change Quotients

Some wag said, "The only person who likes change is a wet baby." Another favorite is "Everyone likes change, when someone else is doing it."

If change is so inevitable, why do people, teams and organizations experience so much difficulty changing? We should be good at it!

In fact, we are good at change, but in our own particular way. We have a unique change quotient. Change quotients range from 0 to 1. Values close to 0 indicate slower changes and values approaching 1 indicate people who readily change. People with lower change quotients often view those with high change quotients as chaotic and "flighty". Conversely, glacial describes low change quotients to those having change quotients approaching 1. 0 doesn't mead "bad", and 1 doesn't mean "good". The values are simply indicators.

Our preference for change depends on our heritage, personality, and work environment.

Our family creates our initial world view. Some families view consistency and slowness to change as admirable qualities. Others feel adaptability and responsiveness are desirable attributes. You start with this view.

Personality builds on this foundation. Some people like closure. Do it once, and it's done forever. Others prefer to keep options open and frequently appear to make conflicting sequential decisions [OK what I mean: Given a choice between A or B, A gets chosen. Shortly thereafter, based on some new piece of information, B becomes the preferred answer. The final answer occurs when the time window closes, and there no more chances exist to change the answer.] This appears (to me, at this time) to correspond to the Myers-Briggs "J/P" type comparison.

Lastly, the work environment influences how we feel about change. Large systems change slowly. Too much change to quickly, and the system (think company) becomes unstable. Complex, critical systems resist change too. Life critical software development should be written by people who aren't in a hurry to change things.

So what to do? The answer depends if you are the changer or the changee.

For the changee ...

Rhonda's Second Revelation: "When change is inevitable, we struggle most to keep what we value most." - Jerry Weinberg

1. Remember everyone has a different change quotient. What you see as change, they may view as stable.
2. The Helpful Rule reminds us that "Regardless of how it looks, people are trying to be helpful."
3. Share with the changer what is most valuable to you.

For the changer ...

Rules of Thumb for Change Agents - A manager gave me a photocopy of these. I BELIEVE they came from Herbet A. Shepard, OD Practitioner, Vol 7, No 3, Nov 1975

1. Stay Alive - This rule counsels against self-sacrifice on behalf of a cause you do not wish to be your last.
2. Start where the system is.
3. Never work uphill.
Corollaries:
1. Don't build hills as you go.
2. Work in the most promising arena.
3. Don't use one when two could do it.
4. Don't over-organize.
5. Don't argue if you can't win.
6. Play God a little.
4. Innovation requires a good idea, initiative and a few friends.
5. Load experiments for success.
6. Light many fires.
7. Keep an optimistic bias.
8. Capture the moment.

Understanding that we change differently as individuals leads to the conclusion that team and organizational changes present unique challenges.