1.Tell a short story to give an overview of the situation.

2.Select the most interesting story (In a multi story workshop)

3.Ask (the storyteller) detailed questions on the selected story

4.Collect variables (observables or measurables) variables and other elements based on the current situation. Interventions come later.

5.Draw arrows between variables. does a variable have a positive or negative impact on an other? Start with the most interesting variables.

6.Simplify. strive for 7 +/- 2 variables. Remove all variables that aren't related to others. Keep only the most interesting variables. If there are still too many, split up the diagram. Try step 10 if there are still too much.

7.Look for loops in the relations. are the loops reinforcing or balancing/stabilizing?

8.Add intervention points

9.Draw a 'new system' diagram (in case intervention points are not sufficient)

10. Present the diagram to a group

11. Adjust the diagram based on the feedback (use any of the previous steps as you see fit)

12. Store the diagram so you can easily retrieve it later (digital photos of flipovers, or use a diagramming software).

1. Work with someone. I understand the story better and draw better diagrams when I work with someone. We bring different viewpoints to the same story.

2. Asking detailed questions ... I guess I should blog about this somewhere.

3. Variable Names - I try to use positive or neutral noun phrases. I'm adamant about not using negatives. That way I don't not have to worry about double negatives and thinking backwards. I use "goes up" and "goes down" to check if the names will work for me.

4. Influence between variables - I've seen:

Positive	Negative
(nothing)	Black Dot
s(ame)	o(pposite)
+	-

5. I've seen drawings created in almost any drawing package. I have a Visio template created by a friend that provides the drawing items mentioned in DiagramOfEffects. Available free for the asking. I've seen diagrams created in Powerpoint.

6. It's common to spend time working on a drawing. It's uncommon to sit down and draw a diagram on the first try.

DonGray 2006.05.07]]> 66.82.9.53 01 December 2007 17:43 GMT http://wiki.systemsthinking.net/Systemsthinking/DrawDiagrams.html Systemsthinking/DrawDiagrams LettingGoOfPairProgramming, CostOfDefects, CodeAndMoreCode and PascalVanCauwenberghe feature examples of diagrams made with this wiki.

Diagrams are made with GraphViz. It has no special support to draw a DiagramsOfEffects, but it comes in handy to quickly sketch out diagrams in a pair or a larger group, without having to pas diagrams back and forth through e-mail or other means.

Starting a new one is probably best done by copying an existing one. Don't forget to change the name of the .png image that is created after copying an example, otherwise your edit will replace an image on another page...

click 'edit this page' to see how the diagram below is created, and copy-paste the text to a new page.

]]> 66.82.9.53 01 December 2007 17:39 GMT http://wiki.systemsthinking.net/Systemsthinking/html/Systemsthinking/style.css.html Systemsthinking/html/Systemsthinking/style.css 80.249.49.1 17 April 2007 14:30 GMT http://wiki.systemsthinking.net/Systemsthinking/SystemParadoxes.html Systemsthinking/SystemParadoxes http://en.wikipedia.org/wiki/Paradox.

Feel free to drop a (system) paradox on this page ...

The EPR paradox, named after Einstein, Podolsky, and Rosen, appears in a thought experiment showing quantum mechanics leads to very counter-intuitive and paradoxical consequences. Bohm improved the formulation of the thought experiment. -- a way cool unentanglement can be found at http://roxanne.roxanne.org/epr/index.html

"According to theory, the Sun derives energy by the thermonuclear conversion of hydrogen into helium, deep inside its core. There is convincing evidence that the Sun is getting at least half of its energy by this method. Such a thermonuclear source could power the Sun for nearly 10 billion years. Most scientists think that the Sun (along with the rest of the solar system) is about 4.6 billion years old, which means it would have exhausted approximately half its 'life'. Over the Sun's lifetime, the thermonuclear reactions would, according to theory, gradually change the composition of the core of the Sun and alter the Sun's overall physical structure. Because of this process, the Sun would gradually grow brighter with age. Thus, if the Sun is indeed 4.6 billion years old, it should have brightened by nearly 40% over this time" -- Danny Faulkner in http://www.answersingenesis.org/docs2001/0228faint_sun.asp

Systems are usually based on Euclidean shapes like circles, squares and triangles while clouds like the observables used in DOE's belong to fractal geometry.

What if fractal geometry can be perceived as patterns happening at increasingly fine magnifications?
What if the visual appearance of a fractal object can be influenced by fractal dimension (D)?
What if the fractal scaling relationship between structures observed at different magnifications can be quantified?
What if its value depends on the complexity and richness of the repeating structure?
What if systems were designed to mimic Nature's fractal patterns?

-- NynkeEtkFokma, August 2004

The Parent Paradox

It's generally reckoned that when educational professionals need to talk to parents about changes in their children's education, it's important for them to help the parents feel comfortable so that they can express their views without being prejudiced by the professional.

So far so good. But the paradox is that the more skilled the professionals are in making the parents feel comfortable, the more the parents will look to the professional for answers and supress their own views. The parents will feel that they are in safe hands.

This paradox has implications for learning organisations. Empowering others is not as simple as making them feel secure. While they may be less afraid to speak their mind, they may be less motivated to do so. Comfort does not inspire passion.

Sorry, no answers here!

Hugh Williams, Educational Psychologist, Birmingham UK

Related pages: ControversialStatements]]> 85.145.81.247 17 January 2007 16:34 GMT http://wiki.systemsthinking.net/Systemsthinking/WillemVanDenEnde.html Systemsthinking/WillemVanDenEnde http://www.willemvandenende.com blog http://ruminations.willemvandenende.com

I started creating CausalLoopDiagrams in 2002, after having been interested in the big picture for a long time. The main reason for me starting was that I needed to find creative solutions to (for me) new problems I encountered after initial successes with AgileSoftwareDevelopment . Every solution creates new problems :-)

I like to DrawDiagrams directly in this wiki, it's one of its coolest features:)

BallGameAtSOLDutchOpen

AgileITSupportForBusiness

I'm collecting material here to contextualize work practices such as piecemeal planning, maintaing a SustainablePace and close collaboration:

MultiTaskingConsideredHarmful

ResultDrivenCoaching

SleepDeprivation

ContinuousRefactoring

XP2005 Workshops:

SystemsThinkingTutorial

ToyotaWayPrinciples

ValueStreamMappingWorkshop

CrystalBallGazingWorkshop

UnitTestPressures

BalancingActXPDays2005

PlanningParadox

CynefinAndXP

Currently puzzling on PairProgramming :

LettingGoOfPairProgramming

Flow, stuckness and interruptions

CostOfDefects

how to add custom shapes to diagrams - would be nice to make diagrams with clouds :-)

CodeAndMoreCode

RiskAnalysisEffects

SystemsThinkingSteps

TheseAreJustSomeOfMyFavouriteTools]]> 69.67.161.235 05 August 2006 21:07 GMT http://wiki.systemsthinking.net/Systemsthinking/DiagramOfEffects.html Systemsthinking/DiagramOfEffects The in this page used description of Diagram of Effects was adapted from Appendix A of the first book in Quality Software Management series of JerryWeinberg: http://www.geraldmweinberg.com/books.html, for which Jerry graciously gave his permission because of the example used: “I always give my permission for fairy tales”.

This tale is from a theme in The Once and Future King written by T. H. White

• http://shop.barnesandnoble.com/bookSearch/isbnInquiry.asp?isbn=0399105972
• http://www.amazon.com/exec/obidos/ISBN=0399105972
• http://www.pricescan.com/books/BookDetail.asp?isbn=0399105972

"I am taking you to see one of those," said the tench, "the Emperor of these purlieus. As a doctor I have immunity, and I daresay he will respect you as my companion as well - but you had better keep your tail bent in case he is feeling tyrannical." "Is he the King of the Moat?" "He is. Old Jack they call him, and some call him Black Peter, but for the most part they do not mention him by name at all. They just call him Mr. P. You will see what it is to be a king."

The Wart began to hang behind his conductor a little, and perhaps it was well that he did, for they were almost on top of their destination before he noticed it. When he did see the old despot he started back in horror, for Mr. P. was four feet long, his weight incalculable. The great body, shadowy and almost invisible among the stems, ended in a face which had been ravaged by all the passions of an absolute Monarch -by cruelty, sorrow, age, pride, selfishness, loneliness and thoughts too strong for individual brains. There he hung or hoved, his vast ironic mouth permanently drawn downward in a kind of melancholy, his lean clean-shaven chops giving him an American expression, like that of Uncle Sam. He was remorseless, disillusioned, logical, predatory, fierce, pitiless -but his great jewel of an eye was that of a stricken deer, large, fearful, sensitive and full of griefs. He made no movement, but looked upon them with his bitter eye.

The Wart thought to himself that he did not care for Mr.P.

"Lord," said Merlyn, not paying attention to his nervousness, "I have brought a young professor who would learn to profess." "To profess what?" asked the King of the Moat slowly, hardly opening his jaws and speaking through his nose. "Power," said the tench. "Let him speak for himself." "Please," said the Wart, "I don't know what I ought to ask." "There is nothing," said the monarch, "except the power which you pretend to seek: power to grind and power to digest, power to seek and power to find, power to await and power to claim, all power and pitilessness springing from the nape of the neck." "Thank you." "Love is a trick played on us by the forces of evolution. Pleasure is the bait laid down by the same. There is only power. Power is of the individual mind, but the mind's power is not enough. Power of the body decides everything in the end, and only Might is right"

A diagram of effects consists primarily of nodes connected by arrows:

1. Each node stands for a measurable quantity, like Grind and Digest, Seek and Find or Await and Claim. The nodes having a “cloud” form serves as a reminder that nodes indicate measurements, not things or processes as in flowcharts, data flow diagrams, and the like.

2. The cloud nodes can represent either actual measurements or conceptual measurements –things that could be measured at present because they may be too expensive to measure or not worth the trouble, or just not measured yet. The important thing is that they can be measured.

3. To indicate an actual measurement currently being made, use a regular, elliptical cloud. Most of the time, however, effects diagrams are used for conceptual –rather than mathematical– analysis, so most of the clouds will be appropriately rough.

4. An arrow from node A to node B indicates that quantity A has an effect on quantity B. We may know or deduce the effect that leads us to draw the arrow in one of three ways:

• From a mathematical formula as in NetworkFlowMath for describing the effect
• Deduced from observations, for instance, when people are observed to get nervous and lose their effectiveness when under pressure from management;
• Inferred from past experience, for instance noticing the change in our bodies demand for food when time is spent on making love or new meanings.

• No dot means that as A moves in one direction, B moves in the same direction like when spending time on Seek and Find, Wait and Claim, Grind and Digest, one’s body will grow by a proportionate amount.
• A dot on the arrow means that as A moves in one direction, B moves in the opposite direction like when spending time on Seek and Find, Wait and Claim, Grind and Digest, one is not spending that time on Making Love.
• A mathematical formula as in NetworkFlowMath for describing the transformation
• Deduced from observations, for instance, when people are observed to get nervous and lose their effectiveness when under pressure from management inferred from past experience, for instance noticing the change in our bodies demand for food when time is spent on making love or new meanings.

• A white square means that human intervention is making the affected measurement move in the same direction as the movement of the cause (just as a plain arrow indicates a natural same direction).
• A gray square means that human intervention is making the affected measurement move in the opposite direction as the movement of the cause (just as a gray dot indicates a natural opposite direction)
• A half-white/half gray square means that human intervention can make the affected measurement move in the same or the opposite direction as the movement of the cause, depending on the intervention. In our case Mr.P can choose to investigate other causes by trying other behavior.

"Now I think it is time that you should go away, young master, for I find this conversation uninteresting and exhausting. I think you ought to go away really almost at once, in case my disillusioned mouth should suddenly determine to introduce you to my great gills, which have teeth in them also. Yes, I really think you might be wise to go away this moment. Indeed, I think you ought to put your back into it. And so, a long farewell to all my greatness."

The Wart had found himself almost hypnotized by the big words, and hardly noticed that the tight mouth was coming closer and closer to him. It came imperceptibly, as the lecture distracted his attention, and suddenly it was looming within an inch of his nose. On the last sentence it opened, horrible and vast, the skin stretching ravenously from bone to bone and tooth to tooth.

Inside there seemed to be nothing but teeth, sharp teeth like thorns in rows and ridges everywhere, like the nails in labarours' boots, and it was only at the last second that he was able to regain his own will, to pull himself together, to recollect his instructions and to escape. All those teeth clashed behind him at the tip of his tail, as he gave the heartiest jack-knife he had ever given. In a second he was on dry land once again, standing beside Merlyn on the piping drawbridge, panting in his stuffy clothes.

-- NynkeEtkFokma, 2002]]> 66.27.48.94 18 July 2006 00:05 GMT http://wiki.systemsthinking.net/Systemsthinking/SystemsThinkers.html Systemsthinking/SystemsThinkers PascalVanCauwenberghe ...

WillemVanDenEnde

NynkeEtkFokma

MarcEvers

MartineDevos

Eric J. Lindblom PhD http://lindblom.bravehost.com

DonGray]]> 62.195.239.155 19 June 2006 23:02 GMT http://wiki.systemsthinking.net/Systemsthinking/ShootingAndAimingStances.html Systemsthinking/ShootingAndAimingStances Oblivious

There is nothing to aim at, nowhere to go?

Conditions or beliefs required to succeed:

• I'm solving my own problems
• Those problems aren't too big for what I know is technically possible.
• I know what I want better than anyone else.
• YaDaYa ...

... and we also need such awareness for each and every problem or obstacle we will meet underway.

Investigating likely system responses in an aware manner can reveal and predict system pressures that we may need to deal with on a journey for learning steering and anticipating stances. And having figured out which stance I need to solve a particular problem, is only the beginning of solving it. A required stance may not be one that I know (well) how to do. A stance may be uncharted territory in and off itself for a product and/or context.

Variable

We aim at a target, and when we miss, well, ... we missed, and we take aim again. We are learning to shoot. This approach suits innovative projects where we are willing and aware of entering The Great Unknown. There seems to be no other way for entering uncharted territory than by traveling it and charting it. When used for the wrong product type this stance results in blaming. No one will dare take accountability for any of the problems. Not me!

Conditions or beliefs required to succeed:

• I have great rapport with my customer.
• I'm a competent professional.
• My customer's problem isn't too big for me.

Routine

We aim at a target and when we miss we investigate why our body missed hitting the target. We are learning to learn how to shoot better, as in, we are learning how to aim. This approach is suitable for consolidation and balancing. When doing this, the products are processes. Examples of typical systems that can be effectively developed in this way are archiving systems. When used incongruently this stance can result in placating. People will spend most of their energy and time on the system, and the system will come to a grinding halt in terms of learning how to deal with changes in its environment. Every attempt to change anything is done in a routine manner, even when not intended as a routine. Foreign elements get rejected, encapsulated or fought.

Conditions or beliefs required to succeed:

• We realize the problem is bigger than one small team can handle.
• The problem is not too big for us to handle.
• The developers must conform to our routine process.
• We hope we don't run into anything too exceptional.

Steering

We aim at a target and when we miss we investigate why we aimed at something else because, obviously, our body shot something else. We are learning how to aim better. With this approach to aiming and shooting we can best create systems on demand. When used improperly this stance can result in head (executive system) and body (operational system) going to war in love/hate relationships or existing in total misunderstanding of each others pressures and their own pressures in irrelevance, resulting in a HeadlessBody with lots of rumors and puzzles flying. People start solving apparent non-problems as if the world depends on it. Other people vote with their feet - now that is really useful for solving any real problems!

Conditions or beliefs required to succeed:

• The problem is big enough that we know a simple routine won't work.
• Our managers can negotiate with the external environment.
• We don't accept arbitrary schedules and constraints.
• We are challenged, but not excessively.
• NetworkFlowMath

Anticipating

We imagine aiming at several likely targets, but do not really have to shoot the arrow each time. We are learning to predict likely effects of our aiming and shooting stances for that particular product or context for a receivable we are to deliver. This way of aiming and shooting is highly recommended for producing secure and reliable products. Perhaps it is required. When used for a non fitting product this stance can result in superreasonable behavior of the system. A MadStakeholder system in which its people loose time, energy and resources to tracking changes in executive management moves instead of a target.

Conditions or beliefs required to succeed:

• I'm solving my own problems.
• We measure quality and cost (internally) by meaningful statistics.
• We use an explicit choreography group to aid us in the dance of cocreating receivable deliverables.
• TimeForEvolution

Congruent

There is everything to aim at, and everywhere to go?

Conditions or beliefs required to succeed:

• We have procedures, which we improve continuously.
• We identify and measure all key choreography variables automagically.
• Our goal is customer satisfaction, which drives everything.

-- NynkeEtkFokma]]> DonGray 204.116.144.62 12 June 2006 19:50 GMT http://wiki.systemsthinking.net/Systemsthinking/MultiTaskingForProgrammers.html Systemsthinking/MultiTaskingForProgrammers

Time on task - time spent doing actual useful work.
Project Work Piling Up - the backlog of things to do. From this or previous projects.
# of Switches - How many switches. DeMarco states 3 complete context switches use up a whole day (Why Does Software Cost so Much?, pg 90)
Total Settling time - How long it takes to respond to a switch and get going on the new task.
Frustration - the frustration level

What have I left out? DonGray 2006.06.09]]> DonGray 204.116.144.62 30 May 2006 02:49 GMT http://wiki.systemsthinking.net/Systemsthinking/MultiTaskingForManagers.html Systemsthinking/MultiTaskingForManagers DeMarco in Why Does Software Cost So Much (If We Did Only One Thing to Improve ...) states "I've come to believe that fragmentation is due mostly to managerial sloppiness." (pg 90).

How do the environment and corporate culture impact managerial decisions? In what context does development multitasking make sense? Here are three situations that make sense to me. (And I'm on the developer's side of this discussion!)

1. Specialized skills. This would be those people that management is lucky to have one of, and their existence has to be spread across several projects to justify their existence. DBAs, architects, object specialists. Would agile coaches be included?

2. A project is completed, the programmers moved on to the next project and: - a defect is located that needs to be corrected. - the client requests a series of improvements. Who better than the original developer(s)?

3. A developer hits a wait state based and can't move forward until something from someone else arrives. Why not let them get started on something while they're waiting?

What other contexts make sense for multitasking development?

DonGray 2006.05.29]]> DonGray 204.116.144.62 28 May 2006 02:18 GMT http://wiki.systemsthinking.net/Systemsthinking/MultiTaskingConsideredHarmful.html Systemsthinking/MultiTaskingConsideredHarmful DiagramOfEffects about multi-tasking would be nice...

Making the problems of multitasking real, blog-entry by Johanna Rothman

Convincing Management That Context Switching Is a Bad Idea, article by Johanna Rothman. This article started a blog dialog between me (Don) and George Dinwiddie. George has added to his thoughts since my last post. I need to go see what he's added.

Multitasking makes you stupid, blog entry by Clarke Ching

Human Task Switches Considered Harmful by Joel Spolsky. This one has nice graphical examples. Clarke Ching made these into an animation for his presentation at XP Day London 2004.

MultiTaskingForProgrammers may work differently than MultiTaskingForManagers, and differently than MultiTaskingFor... It may boil down to how large amounts of 'focus time' one needs for certain tasks, and how 'big' (many, percentage) these tasks are as a part of the job.]]> WillemVanDenEnde 26 May 2006 16:03 GMT http://wiki.systemsthinking.net/Systemsthinking/WikiWebUse.html Systemsthinking/WikiWebUse WikiWeb.

Click on the wiki link in the menubar to go to the FrontPage

Check out WikiWeb and WikiName for more info about Wiki webs.

Check out WikiTextFormattingRules and GoodStyle for editing tips.

You can DrawDiagrams (albeit simple) with this wiki :)

Click the "Recent Changes" link to see who changed what recently

Click the "Edit this page" link to modify a page.

Enter words in the "Search" box and push <RETURN> to search for words. The search is case-sensitive.

Category ]]> WillemVanDenEnde 26 May 2006 15:48 GMT http://wiki.systemsthinking.net/Systemsthinking/CausalLoopDiagrams.html Systemsthinking/CausalLoopDiagrams DiagramOfEffects (DOE)]]> 80.126.57.161 26 May 2006 12:43 GMT http://wiki.systemsthinking.net/Systemsthinking/MarcEvers.html Systemsthinking/MarcEvers XP Day Benelux and Agile Open) based on systems thinking, extreme programming, and agile values, principles, and practices.

You can read more about my thoughts on agile, software development, and other stuff in my weblog and on my homepage.

Some interesting stuff

• Working Together In "War Rooms" Doubles Teams' Productivity, University Of Michigan Researchers Find
• Forced Ranking is Stupid
• Frameworks are leading indicators for programming languages
• Going Home - Our Reformation (By Robert Paterson)
• The long tail of software. Millions of Markets of Dozens.
• Long Tail vs. Bottom of Pyramid
• Dunbar, Altruistic Punishment, and Meta-Moderation
• Situated Software
• Stanford Prison Experiment
• Continuations for Curmudgeons
• Seaside tutorial
• No Best Practices
• Structure and Interpretation of Computer Programs - Video Lectures by Hal Abelson and Gerald Jay Sussman
• Design debt@http://www.jamesshore.com/Articles/Business/Software%20Profitability%20Newsletter/Design%20Debt.html
• Magic Numbers - Are Tribes Forming in the Blogosphere to do work?

• Drucker on The Whole vs. The Part
• Vanguard articles (written by John Seddon)

• Focus on the People Issues
• People Matter Most
• Self-organization
• Unjust Deserts?
• Project Meeting Protocols: Daily Coordination for Managing Promises
• Project Meeting Protocols: Look-Ahead Planning

• Being There
• Code as Documentation
• When Project Managers Attack!
• Cook Until Done
• Ruby and Embedded Domain-Specific Languages
• Architecture & Agility: Strange Bedfellows?

• Blogs & Wikis: Technologies for Enterprise Applications?
• Connecting People With Content
• Weblogs und Wikis als Wissensmanagement-Werkzeuge: Gemeinsamkeiten, Unterschiede, Einsatzmöglichkeiten
• The Social Enterprise
• Socialtext
• JotSpot
• Centered Communication: Weblogs and aggregation in the organisation

• WATIR User Guide

• Managing Programming for CEOs Part 3 – Features Kill

• Pedagogical Patterns
• Incremental vs. revolutionary improvements
• Change or Die

Retrospectives

• An Interesting Retrospective Idea - Emotions Box
• Taking Time to Think

• Distributing Ruby Applications
• Using the Rake Build Language

• Ten Tips for New Trainers/Teachers

• Open-Sourcing Conferences
• Foo Camp: ad-hoc learning
• Build something cool in 24 hours
• Unconferencing
• How to organise valuable congresses/conventions
• Unconferencing, Long Tail of Conferencing?
• No Fluff, Just Stuff
• Events: wikis, blogs, podcasts and a diagram for how they might fit together

• Luca Cardelli & Peter Wegner, On Understanding Types, Data Abstraction, and Polymorphism (PDF)

Don 2006.05.07 (Now can I start adding? ;{)>)

Yes, please :))

Willem 2006.05.09]]> unknown 27 March 2006 19:01 GMT http://wiki.systemsthinking.net/Systemsthinking/MartineDevos.html Systemsthinking/MartineDevos