I was flipping through an old work note book and came across the following story.

I spent three days working with a client who had adopted Scrum for project management about six months earlier. On the fourth day I attended a Sprint planning two (user stories to task with time estimates) meeting. As we talked about stories and sizes, George asked the following question. “How do we deal with work that is too big to finish in a sprint?” In all my time coaching teams, I haven’t found a user story so large that it couldn’t be done in a sprint. If there is such a story, it usually an epic that can be further divided into smaller stories.

Wanting to be helpful I said, “Well, split the story into smaller stories.” Mentally allowing that I haven’t seen all the possible user stories in the world (and there /MIGHT/ be one story so large it couldn’t be finished in a sprint, I continued … “If that doesn’t work, pull the work into the sprint and burn down as much as possible. You don’t get velocity points, but if the backlog is properly ordered you’ll have work done for the start of the next sprint.” Hoping to point to some future perfect day where the team was burning down faster than anticipated I added, “It’s just like when the sprint burns down faster than estimated. You pick the next story from the Product Backlog and start work on it.”

George replied “We’d never do that. We get graded on how well we complete our stories. If we have unfinished work it counts against us.”

The Fundamental Software Development Process

The fundamental software development process looks like:

This system dynamics drawing² varies somewhat from the Diagram of Effects (aka Causal Loop Diagram) I often use by showing the stocks (levels) and flows (rates) associated with the development process. User stories flow into the Product Backlog. The team converts the user stories into Implemented Features at some rate (Velocity). By and large it’s how everyone develops software. Steps may have different names and take more time to complete (or not) but we take what user’s want and give them software that performs those actions.

An important aspect of the Fundamental Software Development Process involves recognizing it’s an open loop system and open loop systems are inherently stable. User stories come in as they will and become part of the Product Backlog. The team works at some natural development speed based on their abilities, the story complexity, and their intrinsic motivation. The Implemented Features accumulate and eventually the software gets released to the users. Based on the Product Backlog size (in story points) and the team’s velocity (in story points) it’s possible to calculate when the next releasable set of Implemented Features will be ready to go to the users.

But what if that date isn’t soon enough?

Add Some Feedback

The conversation with George happened my last day on site and I had meetings stacked the rest of the day. But on the flight home I started wondering, “Why would someone want to ‘grade’ the teams on how well they completed the stories?” One answer is to build confidence in team’s velocity value. Another possible explanation would be a behavioral assumption that the developers tend to avoid work and a way to make sure the developers don’t shirk is to compare the sprint results with the estimates made during the sprint planning.

Whatever the reason for “grading” the sprints, the action of “grading” has created a feedback loop in the system. Adding feedback means taking a system output and sending that output (or some portion there of) back into the system input. I wrote about feedback control loops in Multi-Use Model. Feedback loops provide the opportunity for control, aiming the system at some new target such as a new delivery date. Unfortunately feedback also provokes instability in the system. Unless great care is taken, the system becomes dysfunctional at best and destructive at worst. The Fundamental Development Process now looks like:

The “split” rectangle means management has a choice at this point. They can choose to “grade” sprint results or not. If the grading happens, the rest of the reinforcing loop happens. In a nutshell:

• Team members want to look good. I don’t know if “counts against us” includes performance evaluation, but it could.
• Since the team wants to look good, they’re not likely to take risks. Not taking risks could mean:
  1. Not bringing additional work if they finish early.
  2. Inflating story points for user stories during estimating sessions.
• Since the team won’t take risks, measured velocity won’t decrease (and indeed may increase) while actual velocity (the rate of delivering implemented features) may decrease. As Robert Austin notes:

Boomerang Measurement

I confess I’m doing a certain amount of mind reading now since I didn’t have a chance to talk with the person who decided grading the sprint results would be a “good thing”. But I can’t wrap my mind around the concept that they explicitly set out to slow the development process. But they did, we have another boomerang measurement.

Truth be told, I believe the person thought they were (are?) doing the best possible actions to help the developers be more efficient. I’m serious. You can’t make up stuff like this.

For more information on how management goes astray with measurements I recommend reading Measuring and Managing Performance in Organizations by Robert Austin and Slack, Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco.

Got an example of a boomerang measurement? Drop me a note.

¹I first heard this line from Jerry (Gerald M.) Weinberg
²http://en.wikipedia.org/wiki/System_dynamics
³Measuring and Managing Performance in Organizations Dorset House Publishing, ISBN 0-932633-36-6, page 38

Why is it so?
Jerry (Gerald M.) Weinberg chose to use Brook’s Law in Quality Software Management: Vol 1. Systems Thinking to demonstrate non-linear feedback systems. Combining Fig 5-1 (page 78) and Fig 6-4 (page 93) gives us:

Brooks' Law

I describe how to read Diagram of Effects here.

In essence adding manpower affects the system by:

1. Creating more communication paths. The number of communication paths is n*(n-1) where n equals the number of team members. This says increasing from 4 to 6 members increases communication paths from 12 to 30.
2. Adding new team members creates a training load on the existing team members. This in turn reduces the productive work finished.

These problems get exacerbated when managers decide to add “extra” manpower just to be sure the project doesn’t slip any more.

Communications and Sharing Information

Tools to support software development methods have changed since Brooks’ Law was introduced. We now have information radiators for sharing information in parallel. By simply walking around your office it’s possible to learn information about the project. Additionally wikis, build systems, source code management are types of information magnets. They hold pertinent information that can be searched, sorted and reviewed.

There’s a sliding window of opportunity where manpower can be added to a project and not negatively impact the schedule. This window closes when the additional productivity achieved by adding more staff isn’t enough to offset the lost production due to training them. According to Israel Gat, BMC Software staffed the two releases with 80-95 developers compared to other companies who staffed similar sized projects with 25-35 developers. This staffing level resulted in product delivery in 4.5 – 5 months instead of over a year. This rapid delivery creates problems for the downstream organizational activities such as marketing, sales, revenue recognition and the back office. BMC Software recognizes this problem and is currently working on synchronizing the activities.

How to Beat Brooks’ Law

The state that invokes Brooks’ Law is “late”. To beat Brooks’ Law all you have to do is avoid having late projects. What are some ways to avoid late projects?

• Staffing – BMC Software avoided late project delivery by aggressively staffing when they started the project.
• Cross functional teams – This keeps the project delivery from being derailed when something happens to a “key” developer.
• Incremental and iterative development – Customers rarely need all the new functionality at once. Delivering the highest value functions sooner relieves the pressure for a “big bang” delivery. The customer can decide to stop the project early if/when their needs get met.
• Fast feedback – This naturally flows from incremental and iterative development. Every two to four weeks the customer provides information on how well the development is doing at meeting the customer’s needs.
• Continuous Improvement – At the end of each delivery cycle, set aside time to learn from the cycle’s activities and events. What went well? What could be improved? Select something from the “What could be improved” list and work on it the next delivery cycle. Be sure to ask at the end, “Did we implement the improvement?” Some things take more than a single delivery cycle to get right.

1. The AYE Conference schedule contains several sessions involving systems thinking. Two sessions, Experience the Diagram of Effects and General Systems Thinking obviously involve systems thinking. Several other sessions will include systems thinking principles, without necessarily naming them as such.

You can receive emails about the conference by signing up here

2. I recently received an email related to Force Ranking. It said … “I am currently working at [a company] for few yrs, and yes, I am suffering in the “forced ranking” system. After 1.5 yr from your article which talked about forced ranking, today is 2007- 5 – 27, our team is breaking down into a mess, ppl started to protect themselves, fighting each other rather than helping each other; poor management team : political competitions happen anytime anyday, and kissing boss’s ass will get a better position; The [company] stock price drops, always hear the rumour of [larger company in Redmond] will buy [our company]. Our so-called “innovations process” never reached the outstanding result as [a competing company], it is just a way for ppl to getting a better KPI (annual review), to avoid falling into the bottom 10%. Let’s see how/what [this company] will turn to be…u bet?

I have a pretty good idea how this is going to turn out. Maybe not soon, but if the system forces don’t change, it’s only a matter of time.

3. In Multi-use Models I mention how the feedback control loop model can be used for personal problem solving. I used the example of losing weight. It works! I’ve lost 30 pounds since I wrote the blog entry. Another 4.5 kilos and I’ll be at my goal.

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

This model is the basis for most of the process control in the world. Basically the setpoint getscompared to the actual value. The error value goes to a controller, that then takes a corrective action. If the temperature is to hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The generic sprint cycle looks like:

The outside loop is the sprint cycle (usually 30 days or less).  Every sprint the product owner sees new product functionality. This allows him/her to compare the current product state with the target. A subset of the remaining stories gets selected by the team and becomes the current spring backlog. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal by completing the stories in the sprint backlog.

I’ve left some feedback loops out of this drawing:

1. The team assigns stories relative weight/size/difficulties to the stories.
2. The sprint planning meeting occurs in the arrow labeled “Priority Stories”. The team uses the information from its previous sprints to determine how much they can accomplish in the next sprint.
3. The many interactions that happen each day as the team works towards the sprint goals.

I chose not to include them since I’m working from an overview position. If these areas presented difficulty for the system, I’d focus on them and leave the other loops off.

A Rose is a Rose

In Quality Software Management: Systems Thinking Jerry Weinberg presents the model in a slightly different picture (page 62).

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

1. Randomness – All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. Here’s a list of models I’m aware I’m using.

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model.

Based on the domain, I may choose to use other models to help resolve the difference. If I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, it’s everywhere, Cybernetic Model.

But as I think about what I understand involving force ranking, the logic behind it makes some sense. If I remove the lower performers (by some criteria) from my team, the overall average team performance (of that criteria) goes up. [Let me know if you'd like to see the math behind this thought.]

Here’s my idea of what a DoE looks like for force ranking

Force Ranking Dyanmics

Force ranking creates competition between individuals. As competition increases, more effort will be put into increasing (at least the appearance of) individual performance. As individual performance increases, it appears that force ranking is working, and force ranking gets used more. When this goes on long enough, the people who excelled in being force ranked get promoted and force ranking becomes institutionalized. After all, it worked for them.

But after a while, the secondary loop starts to apply pressure to the system. The competition between individuals reduces the team’s performance. This happens since time and energy spent “improving one’s self” comes at the expense of time and energy working toward the team’s goals. It probably creates conflict and tension between the team members, and quite possibly internally in the team members (not everyone enjoys competition). Since the overall team performance has gone down, we need to do more force ranking to get the performance up to where it used to be, there by invoking _Weinberg’s First Law of Bad Management_ If what you’re doing isn’t working, doing more of it won’t help.

But It Appears to Work!

For a while anyway. This happens because people will sacrifice for some period of time. This creates the delay before the secondary “team loop” starts to function. During this initial period of “working” observers notice the shiny new management technique and proceed to implement it. However …

Why does it fail?

Force ranking fails to consider (at least) three principle systems concepts: emergence, cause-effect and optimization.

It’s that old-timey synergy thing: “The whole is greater than the sum of the parts.”

Cause-effect comes into play by separating the effect (poor team performance) from the cause (force ranking) in time. When management notices that team productivity has declined, force ranking will be institutionalized, and the primary thought will be “find the low performers and move them out.” It will take a catastrophic calamity before anyone will stop to consider that force ranking may have caused the problem.

Force ranking optimizes the organization at the individual level. As each individual optimizes their outcome, the larger systems (teams, departments, and organization) will be sub-optimized due to the conflicting goals between individuals. If the original reason to force rank is to improve performance, then in the long run, force ranking is dysfunctional as it returns less value to the client than the original state.

Another way to blame?

Without actually saying it, force ranking seems to be a blaming activity. People are identified as “not as good” and removed from the team. Here’s a DoE that shows blaming’s effects.

The Blame Game

What did I miss? Send me an email.

Why I Can Agree

Jerry’s example of here-now-us related to a client’s problem. Through the magic word “snow”, one person transported themselves to “there-then-them”, and applied the emotions and feelings from the “then-there-them” to the current “here-now-us”.

Willem’s example of “there-then-them” shows that reflecting on “there-then-them” (“me“ in his example) provides insight that may allow him to change his behavior (if he wants to).

Neither example precludes or excludes the other when thinking about “there-then-them” and “here-now-us”. So what good is it?

A Useful Tool

The “there-then-them” / “here-now-us” tool can be used tactically or strategically. Tactically it helps problem solvers keep track of WHICH problem they’re trying to solve. When the solving the current problem suddenly vectors off in a surprising direction, be suspicious that someone went “there-then-them”.

Strategically, “there-then-them” can be used to reflect on how we got here, and what we might want to change.

Do you have useful tool for systems thinking? Drop me a note.

The Root Problem

I would say that the root of the problem or “cause” was the pure and simple fact, that a poor decision was made to “band aid” a poorly designed system. If the correct decision was made in February of 2004, to replace the poorly designed, inherited system, it’s unfortunate to say this but, we would not have had the opportunity to meet, as I would have had a turn key system installed. I have proven to management here, … that it was a poor decision to band aid, rather than replace. The unfortunate problem now is that the system is running just good enough that it is much harder to justify a new system. You could argue that “just good enough” means the problem is fixed, but I have showed, using our Quality data, that even though we improved from a 33 %! defect rate down to a 3% average defect rate. That 3% adds up to approx 160K per year. There is more to the equation than just coding issues, you have hardware failures that add to the defect rate, which would be eliminated with a properly designed centralized control system.

One thing to remember that it was one guy who made the decision, I.E. it was not a group decision. In fact I almost had the go ahead to do the upgrade until our friend jumped in and decided to “save” the company money. Our friend moved to other places after the damage was done about 2 months after the decision was made to band aid. Pretty convenient eh? Not to mention the multitude of other management changes that have taken place over the past 2 years, in effort to try to make RTM work. Over all things are better now than they were 2 years ago.

The Sky is Falling

I agree with George. For the last two years we’ve been adding features (complexity) and size (lines of code) to a system that should be replaced. And now he’s adding 1/3 more functionality. The logical conclusion seems that sometime, possibly in the not to distant future, the system will implode from its heritage.

Three Ways to Solve a Problem

The original quality problem had three possible solutions:

1. Solved: This solution provides the maximum possible benefit. George would have a new system properly designed to handle the process.
2. Resolved: This is the “good enough” solution. The results are satisfactory, but not maximized. George’s current reality.
3. Dissolved: By changing requirements (such as quality parameters), the problem could just “go away.” Not going to happen for George.

With my help, George now has a system that satisfices. His new problem is getting management on board to realize a change should be made before it’s too late.

Systems have several essential characteristics:

1. A system’s parts must all be present for the system to carry out its purpose optimally. If you can take components away from something without affecting its functioning and its relationships, then you have just a collection, not a system. A pile of quarters on the table would be a collection. The company for which you work is a system.
2. A system’s parts must be arranged in a specific way for the system to carry out its purpose. If the components of a collection can be combined in any random order, then they do not make up a system.
3. Systems have specific purposes within larger systems. To paraphrase, “It’s systems all the way down.” Your company, your department, your team, you, your various physical systems, and smaller the systems get until you reach the sub-cellular level.
4. Systems maintain their stability through fluctuations and adjustments. Systems achieve this stability through the interactions, feedback and adjustments that continually circulate among the system parts, and between the system and its environment. If a systems doesn’t achieve stability, it generally doesn’t last long enough to get noticed.
5. Systems have feedback. Feedback is the transmission and return of information. The most important feature of feedback is that it provides the catalyst for a change in behavior.

A system has feedback within itself. But because all systems are part of larger systems, a system also has feedback between itself and external systems.

Finally, feedback is not necessarily transmitted and returned through the same system component or even through the same system.

What would you add or change?

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 email 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
• Work Time
• Money for bills
• Writing Time
• 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.

Update 2010.1.28

I still create Diagram of Effects when I find sticky issues, those things that hang around, even when I try to fix them.

I now use Inkscape to create my diagrams. I have a template I’ll share if you ask. I still have the Visio template too.

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.