What is required is a method for developing a sound understanding of a situation and evolving a strategy that is highly likely to improve the situation. It is the intent of this site to provide that methodical approach, along with numerous examples to aid in substantiating the approach.

Conventions

• Rather than begin with a lengthy introduction attempting to substantiate the value of this approach, if you're willing to invest a few hours, you can just begin experiencing it, and its power will emerge as a natural result. If you're going to learn to ride a bicycle a lengthy description of how to ride a bicycle is of far less utility than actually spending time on a bicycle, though a few initial pointers are essential.
• All models are constructed with the Simgua software. These models could be implemented in Stella/ithink, Vensim or Powersim as well; though after having used numerous simulation packages Simgua is currently my software of choice. Some of the descriptive diagrams were developed in Vensim PLE for reasons that will become evident. The final version of each model is executable via the web with no software required.

Connections

I believe the content of this site can substantially benefit from your feedback. As such, as you interact with the content, you are encouraged to provide feedback to Gene Bellinger.

Next: Systems Thinking

Welcome

• SystemsThinkers that do it on this wiki
• WikiWebUse and more for doing it on this wiki too
• DrawDiagrams directly in the wiki, to do it with more than words
• SystemsThinking what Wikipedia says it is
• SystemsThinkingLinks to a wide variety of emerging and growing systems thinking forms
• SystemsThinkingEvents, cheers!
• BookList

• ControversialStatements and SystemParadoxes for entertainment
• MadStakeholder & HeadlessBody not really in opposition
• NegativeFeedbackLoops for checking we are all still healthy and effectively tracking what is happening?
• PositiveFeedbackLoops for what are we likely to be able to effectively hunt and digest?
• HighIntegrityCommunication for building highly reliable and secure receivable deliverables
• The First Discipline - Entry point for Systems Thinking, Modeling & Simulation Content from Gene Bellinger

• BookList of agile (and) systems books
• DiagramOfEffects, how to make and use 'em
• SystemEffectiveness in (dis)guises
• SatirChangeModel focuses not just on systems of people but also on individual people
• NetworkFlowMath, a differential form supporting effectiveness of DOE's
• DifferentialSatirChangeMath, differential form of the Satir change , intuitively
• ValueStreamMapping - understanding the flow of value through your system (and its' fractals).

• ShootingAndAimingStances, business martial arts
• TimeForEvolution, planning a journey to congruence
• ScenarioPlanning for preparing journeys

• Feedback request on http://existentialsociety.bravehost.com
• Feedback request on http://existentialsystems.bravehost.com
• The Existential Society is an International Discussion group
• in Systems and Existentialism
• http://elindblom.bravehost.com

• CenterOfHumanEmergenceCommunityPatternLanguage

Some more lines of stuff Just testing; FrontPage ---

AnotherSandBoxPage]]> unknown 19 October 2009 14:02 GMT http://wiki.systemsthinking.net/Systemsthinking/MartineDevos.html http://wiki.systemsthinking.net/Systemsthinking/MartineDevos.html gene 04 October 2009 14:29 GMT http://wiki.systemsthinking.net/Systemsthinking/Systems%20Thinking.html http://wiki.systemsthinking.net/Systemsthinking/Systems%20Thinking.html Systems Thinking is the construction of models, simplified views of reality, intended to promote understanding. Systems Thinking is also presented as an approach for getting beyond cause and effect to the patterns of behavior that surface the cause and effect, and further, for identify the underlying structure responsible for the patterns of behavior. Systems Thinking models are generally developed as Causal Loop Diagrams (CLDs), though there are shortcomings of CLDs. There is a more disciplined approach to developing models which creates clearer, more well defined and structurally sound, models and additionally provides a foundation from which to investigate the dynamic nature of models.

When thinking about a situation not only is it important to consider the elements relevant to the situation, it is also important to consider the interactions between those elements. As it turns out there are only a few basic types of primitives necessary to describe almost all situations, and even fewer valid interactions between them. The following sections present these primitives as well as the interactions between them and some implications of those interactions.

Primitives

There are only four basic types of primitives needed:

1. A primitive representing a quantify of something, which we will refer to as a stock. A good example of this is a bathtub containing water.
2. A primitive representing the movement of something into or out of a stock, which we will call a flow. With the bathtub stock above water can flow in or out.
3. A primitive which represents a value involved in defining some part of an interaction, which we'll refer to as a parameter.
4. A primitive which conveys information about one primitive to another, which we'll call a link.

Interactions

Considering the stock, flow, parameter, and link characteristics there are only a few valid interactions between them.

The content of one stock can flow into another stock. When the source or destination of the flow is not considered relevant to the situation being considered it is represented as a cloud. When you fill a bathtub with water you are generally not concerned with the source of the water.
A link may be used to convey information: from a stock to a parameter, from a parameter to a parameter, from a parameter to a flow, from a flow to a parameter, from a flow to a flow, from a parameter to a stock in order to establish its initial value.

Sample Model

Orders are a flow into Inventory, a stock, causing it to increase. Sales, a flow, moves Finished Goods, a stock, out of the company. Resources and Productivity, parameters, interact in some manner to define Production, a flow, that moves Inventory to Finished Goods. The diagram to the right is a model of this set of interactions.

Summary

• Your questions is probably, "So what?" By using these primitives the models you develop will provide a much clearer perspective of situations than you could arrive at though any other approach. This will become evident in the subsequent sections.

• All you really need to develop these models is a pencil, paper and an eraser; definitely an eraser because of the iterative nature necessary to clarify the thought. Using software to draw diagrams is even better. The above diagrams were done with Simgua and you'll learn why in the next section.

• Employing the rigor associated with mapping out your thoughts using these conventions result in a qualitative perspective. To fully understand the implications of the interactions, how the elements change over time, and produce a quantitative view requires software that will actually bring the interactions in the model to life. While there are numerous software packages that will do this Simgua is an excellent choice. It is extremely powerful though amazingly easy to use and endlessly extendable if you should need. The reasons for its choice will become evident in the following sections.

Internal Links

• Creating a Model
• The First Discipline

Getting Started

There are two points to remember as you're beginning:

• It doesn't matter where you start because all the pieces are related in one manner or another. As such, with the appropriate rigor applied to the development of the model you should end up with an appropriate model regardless of where you start.

• You're developing a model, a simplification of reality to promote understanding, of some perceived situation. You are not developing a model of "the system". The problem with developing a model of "the systems" is the model will tend to become overly complicated and make it difficult for the model to fulfill its purpose; to promote understanding.

Ok, so here's the description of a perceived situation we can investigate in a rigorous manner.

If one can put money in an investment account and it grows over time, and it grows even faster with regular deposits, why aren't more people rich and ready for retirement? I've started numerous retirement programs though the years though for one reason or another they've all evaporated in time. What is the basis of this sad state of affairs?

Now we have a place to start. The previous description identifies two elements; an investment account and deposits. Let's start with Investment Account. This sounds like a quantity of money so it must be a stock.

The stock is labeled Investment Account. The traditional wisdom says that when naming stocks you should use a noun, and a positive sense one at that, and you'll see why later. Also note that nothing changes in a stock unless it is increased by an inflow or decreased by an outflow. Neither hand waving nor smoke and mirrors have an affect within a model.

A deposit is something that increases the value of the Investment Account so it must be a Flow into the Stock. Fig. 2 depicts deposit as a Flow into the Stock. That the Flow is blue is a personal convention. The Flow is labeled as a noun; a positive one at that. The "regular" modifier was dropped because, while it would be nice, the deposit doesn't have to be "regular". The "+" sign indicates that the deposit adds to the Investment Account. If deposit increases it adds to Investment Account. If deposit decreases it still adds to Investment Account, just not so rapidly.

Initially deposit begins in a cloud as we're not concerned with where the deposit comes from, though this could change as we continue to develop the model.

We're now at a point where we've exhausted what was provided in the situation description. To progress from this point we have to ask questions and think. Though what are the appropriate questions? There are really only two question.

• What else affects what's already part of the model, and

• What else does the existing parts have an affect on; that's relevant to the situation we're considering?

Generally an Investment Account pays some amount of interest based on an interest rate and the amount of money in the Investment Account. In Fig. 3 we've added interest which is a flow and adds to Investment Account and the interest is a function of Investment Account and interest rate. At this point interest rate is indicated to be a constant (which isn't really true though we'll start there) which is why it doesn't have a "+" sign on it and it's black.

The "R1" notation is an indication that the loop (Investment Account -> interest -> Investment Account) is a reinforcing loop. Whether a loop is a balancing or reinforcing loop can be determined by counting the number of "-" signs around the loop. If the number is 0, or even, then it's a reinforcing loop; an odd number and it's a balancing loop.

Admittedly the Investment Account could be a stock portfolio in which the stocks periodically pay dividends or it could be a mutual fund with variable return on investment, though for now we've just chosen to use interest as in a savings account.

If you get to a point where you can't quite figure out another relevant connection asking others for input is a wise move. I find it continually amazing where insights come from at times.

Withdrawals has been added as the means by which the Investment Account is decreased. Notice the "-" sign indicating "subtracts from". That withdrawals is red is also a personal convention making subtractions easier to spot in a model.

At this point there seems to be several aspects of this model which directly relate to the initial question:

• Starting the Investment Account is a necessary first step, otherwise nothing happens.
• Choosing an Investment Account with a good interest rate will ensure it grows faster.
• The larger and more frequent the deposits the faster the Investment Account will grow.
• Withdrawals are contrary to the intent of the Investment Account.

Regarding finding a good interest rate, it depends a lot on one's tolerance for risk. If you're looking for a guaranteed return, with no possibility of loss, then you have to settle for a lower interest rate. If you can tolerate the possibility of losing your money then certain stock investments have a high yield potential, along with the potential of loss. And, there are lots of vehicles in between these two options.

Deposit was initially placed in the diagram with a cloud as its source indicating the source of the deposit wasn't relevant. You know the deposit has to come from somewhere that's relevant to the person making the deposit, and that would be you. Fig. 5 adds some clarification around the source of the deposit.

The money available for deposit is the difference between income and expenses, which usually turns out to be about zero.

In order to encourage people to make deposits, at least in the US, there are types of accounts into which you can put pretax dollars. Depending on one's tax bracket this could be a 15 to 35 bonus. And, one can set it up as a direct deposit so one never sees the money, and therefore avoids the risk of spending it. Also one isn't taxed on the interest until they take the money out of the account.

As an additional discouragement to withdrawing money from the Investment Account there are penalties incurred if one removes the money before reaching the age of 59 1/2. Though even with the disincentives for withdrawal the attractiveness grows proportional to the Investment Account. Fig. 6 adds there elements to the model to depict these aspects of the model.

We now have a model which provides some incentives to start and continue to deposit into an Investment Account, and some disincentives toward the withdrawal of funds, though have we really addressed the initial situation posed? Not really. As far as starting the Investment Account and regularly depositing money, there are incentives, and for many these incentives were enough to get them to invest. For many the incentive, for one reason or another, has not been sufficient. And, any more strict incentives would likely be looked on unfavorably. People do not like to be manipulated, even when it is for their own benefit. The penalty for withdrawal is a deterrent in some respects though as the Investment Account continues to grow its attractiveness in terms of what it can purchase continues to entice. The best answer for this situation is to legally tie up the withdrawal process so it's only an option in the case of dire emergencies. Though as much as people find being manipulated by others distasteful, being controlled by themselves is just as distasteful.

Is the model done? As usual, the answer is; "It depends?" If it has provided sufficient understanding to address the situation posed then it is sufficient. If not then it should be taken further, though once it is sufficient you should STOP!

Summary

There are several items it is hoped that you will take away from this article:

• A model is a simplification of reality intended to promote understanding. If the model does that then it's a good model, otherwise work on it some more.

• The situation under consideration should be described in terms of how it has evolved over a period of time, and possibly how it's expected to evolve in the future.

• A model should be developed only for those interactions which are relevant to the situation being considered. Model what is necessary and sufficient to address the situation described, and no more.

• Using the stock, flow, parameter, and link elements causes one to think more explicitly than when using just parameter and link elements to construct a model.

• Any influence which is the basis for a change must be explicitly represented (no smoke and mirrors or hand waving allowed).

• There are some good guidelines which improve the model's potential for promoting understanding. Refer to the Guidelines for Drawing Causal Loop Diagrams paper.

• The resultant model is qualitative. There may be times when the real implications of the interactions are simply not intuitively evident even after the model has been developed.

• For a quantitative understanding of the interactions within a model one needs a software package that provides for simulation of the model with explicit values.

Internal Links

• Simulating a Model
• Systems Thinking
• The First Discipline

References

• Richardson, George, Problems with Causal Loop Diagrams Revisited
• The Systems Thinker, Guidelines for Drawing Causal Loop Diagrams

You can read more about my thoughts on agile, software development, and other stuff, on my company website, 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
• 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)

WillemVanDenEnde

NynkeEtkFokma

MarcEvers

MartineDevos

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

DonGray

Gene Bellinger]]> 83.83.109.99 17 December 2007 08:54 GMT http://wiki.systemsthinking.net/Systemsthinking/SystemsThinkingSteps.html http://wiki.systemsthinking.net/Systemsthinking/SystemsThinkingSteps.html DiagramOfEffects. Most of the steps are also contained in bob the project manager thinks about systems by PascalVanCauwenberghe . MarcEvers and WillemVanDenEnde use them in the SystemsThinkingTutorial.

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 http://wiki.systemsthinking.net/Systemsthinking/DrawDiagrams.html 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.

]]> 80.249.49.1 17 April 2007 14:30 GMT http://wiki.systemsthinking.net/Systemsthinking/SystemParadoxes.html http://wiki.systemsthinking.net/Systemsthinking/SystemParadoxes.html 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 http://wiki.systemsthinking.net/Systemsthinking/WillemVanDenEnde.html 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]]> Pascal Van Cauwenberghe 12 August 2006 18:29 GMT http://wiki.systemsthinking.net/Systemsthinking/BookList.html http://wiki.systemsthinking.net/Systemsthinking/BookList.html

Systems Thinking Playbook by Linda Booth Sweeney & Dennis Meadows
ISBN 0966612779 About people, teams and organizations

• The Dance of Change by Peter Senge et al
  ISBN 1857882431
• Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco
  ISBN 076790768X
• Software for your Head by Jim & Michele McCarthy
  ISBN 0201604566
• PeopleWare: Productive Projects & Teams by Tom DeMarco & Timothy Lister
  ISBN 0932633439
• The Psychology of Computer Programming by Gerald M. Weinberg
  ISBN 0932633420
• Software Quality Management - I - Systems Thinking by Gerald M. Weinberg
  ISBN 0932633226
• Software Quality Management - II - First-order Measurement by Gerald M. Weinberg
  ISBN 0932633242
• Software Quality Management - III - Congruent Action by Gerald M. Weinberg
  ISBN 0932633285
• Software Quality Management - IV - Anticipating Change by Gerald M. Weinberg
  ISBN 0932633323
• On Organizational Learning (second edition) by Chris Argyris
  ISBN 0631213082
• Project Retrospectives by Norman L. Kerth
  ISBN 0932633447
• Agile Retrospectives by Esther Derby and Diana Larsen
  ISBN 0977616649
• The mythical man-month by Fred Brooks
  ISBN 0201835959
• Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco & Timothy Lister
  ISBN 0932633609
• Fearless Change by Linda Rising and Mary Lynn Manns
  ISBN 0201741571

Lean

• Lean Software Development: An Agile Toolkit by Mary & Tom Poppendieck
  ISBN 0321150783
• Implementing Lean Software Development: From Concept to Cash by Mary & Tom Poppendieck
  ISBN 0321437381
• The Machine that changed the World by Womack, Jones & Roos
  ISBN 0060974176
• Lean Thinking by James P Womack
  ISBN 0743249275
• Thinking Beyond Lean: Multi-project Management by Micheal A. Cusumano
  ISBN 0684849186
• Toyota Production System by Taichi Ohno
  ISBN 0915299143
• The Toyota Way - 14 management principles from the world's greatest manufacturer by Jeffrey K. Liker
  ISBN 0071392319
• The Toyota Way Fieldbook by Jeffrey K. Liker and David Meier
  ISBN 0071448934

Theory of Constraints

• The Goal - A Process of Ongoing Improvement by Eliyahu Goldratt
  ISBN 0566074184
• Critical Chain by Eliyahu Goldratt
  ISBN 0566080389
• It's Not Luck by Eliyahu Goldratt
  ISBN 0566076276
• Critical Chain Project Management by Lawrence P. Leach
  ISBN 1580530745
• Throughput Accounting, by Thomas Corbett
  ISBN 0884271587
• Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David J. Anderson
  ISBN 0131424602
• Thinking for a Change by Lisa Scheinkopf
  ISBN 1574441019

Reuseful Patterns

• Metaphors We Live by by Lakoff & Johnson
  ISBN 0226468011
• How Buildings Learn by Stewart Brant
• The Nature Of Order Volumes I and II by Christopher Alexander
  ISBN 0972652914
• A Foreshadowing of 21st Century Art by Christopher Alexander
  ISBN 0195208668
• The Oregon Experiment By Christopher Alexander
• The Timeless Way Of Building by Christopher Alexander
  ISBN 0195024028
• The Design of Sites by Douglas van Duyne et al.
  ISBN 020172149X

Communication

• The Art Of Focused Conversation by the Canadian Institute of Cultural Affairs Canada
  ISBN 0865714169
• The Visual Display Of Quantitative Information by Edward Turfte
  ISBN 0961392142
• Visual Language by Robert Horn
  ISBN 189263709X
• Understanding Computers and Cognition: A New Foundation for Design by Terry Winograd & Fernando Flores
  ISBN 0201112973
• The Art Of The Long View by Peter Schwartz
  ISBN 0385267320
• Co-Opetition: A Revolution Mindset That Combines Competition and Cooperation by Adam Brandenburger and Barry Nalebuff
  ISBN 0385479506
• The One Page Business Plan by James Horan
  ISBN 1891315072
• Positioning: The Battle For Your Mind by Al Ries & Jack Trout
  ISBN 0071373586
• Managing the Unknowable : Strategic Boundaries Between Order and Chaos in Organizations by Ralph Stacey
  ISBN 1555424635

The Addison Wesley XP series:

• Extreme Programming Explained: Embrace Change by Kent Beck
  ISBN 0201616416
• Extreme Programming Installed by Ron Jeffries, Ann Anderson, Chet Hendrickson
  ISBN 0201708426
• Planning Extreme Programming by Kent Beck, Martin Fowler
  ISBN 0201710919
• Extreme Programming in Practice by James W. Newkirk, Robert C. Martin
  ISBN 0201709376
• Extreme Programming Examined Editors: Giancarlo Succi, Michele Marchesi
  ISBN 0201710404
• Extreme Programming Applied: Playing to Win by Ken Auer, Roy Miller
  ISBN 0201616408
• Extreme Programming Explored by William C. Wake
  ISBN 0201733978
• Extreme Programming Perspectives Editors: Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams
  ISBN 0201770059
• Testing Extreme Programming by Lisa Crispin and Tip House
  ISBN 0321113551
• Questioning Extreme Programming by Pete McBreen
  ISBN 0201844575
• Pair Programming Illuminated by Laurie Williams, Robert Kessler
  ISBN 0201745763

About Agile Development - Software oriented

• Refactoring: Improving the Design of Existing Code by Martin Fowler
  ISBN 0201485672
• Test Driven Development: by Example by Kent Beck
  ISBN 0321146530
• Test Driven Development: A Practical Guide by David Astels
  ISBN 0131016490
• Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus by Richard Hightower, Nicholas Lesiecki
  ISBN 047120708X
• Object Oriented Reengineering patterns by Serge Demeyer etc
  ISBN 1558606394
• Smalltalk best practice patterns by Kent Beck
  ISBN 013476904X
• Extreme Programming Adventures in C# by Ron Jeffries
  ISBN 0735619492
• Unit Testing in Java: How Tests Drive the Code by Johannes Link, Peter Frolich
  ISBN 1558608680
• The Pragmatic Programmer by Andrew Hunt and David Thomas
  ISBN 020161622X

About Agile Development - Process oriented

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by Scott W. Ambler
  ISBN 0471202827
• Agile Software Development by Alistair Cockburn
  ISBN 0201699699
• Agile Software Development with SCRUM by Ken Schwaber & Mike Beedle
  ISBN 0130676349
• Agile Project Management with Scrum by Ken Schwaber
  ISBN 073561993X
• Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Jim Highsmith
  ISBN 0932633404
• Agile Software Development Ecosystems by Jim Highsmith
  ISBN 0201760436
• A Practical Guide to Feature-Driven Development by Stephen Palmer and John Felsing
  ISBN 0130676152
• DSDM: Business Focussed Development by DSDM Consortium
  ISBN 0321112245
• Agile Software development: Principles, Patterns and Practices by Robert C. Martin
  ISBN 0135974445
• Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehn and Richard Turner
  ISBN 0321186125
• Agile and Iterative Development: A Manager's Guide by Craig Larman
  ISBN 0131111558
• Better Software Faster by Andy Carmichael
  ISBN 0130087521
• Extreme Programming Refactored by Matt Stephens, Doug Rosenberg
  ISBN 1590590961
• Agile Software Development in the Large: Diving Into the Deep by Jutta Eckstein
  ISBN 0932633579
• User Stories Applied by Mike Cohn
  ISBN 0321205685
• Agile estimating and planning by Mike Cohn
  ISBN 0131479415
• Managing Agile Projects edited by Kevin Aguanno
  ISBN 1895186110

]]> 69.67.161.235 05 August 2006 21:07 GMT http://wiki.systemsthinking.net/Systemsthinking/DiagramOfEffects.html http://wiki.systemsthinking.net/Systemsthinking/DiagramOfEffects.html 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

"Look over there." "The Wart looked and at first saw nothing. Then he saw a small translucent shape hanging motionless near the surface. It was just outside the shadow of a waterlily and was evidently enjoying the sun. It was a baby pike, absolutely rigid and probably asleep and it looked like a pipe stem or a seahorse stretched out flat. It would be a brigand when it grew up.

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

5. The general direction of the effect of quantity A on quantity B may be indicated by the presence or absence of the large gray dot on the arrow between them.

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

6. A square on an effects line indicates that human intervention is determining the direction of the effect:

• 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]]> 62.195.239.155 19 June 2006 23:02 GMT http://wiki.systemsthinking.net/Systemsthinking/ShootingAndAimingStances.html http://wiki.systemsthinking.net/Systemsthinking/ShootingAndAimingStances.html 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 if we experience an attraction or repelling, humans and collectives thereof can be perceived to use one of four ways of dealing with aiming for and shooting at targets. Depending on what product is required of a system to solve a particular problem, one of these aiming and shooting stances can be determined and agreed upon as way of "getting somewhere" ...

http://www.moebius.nl/component/option,com_docman/task,doc_view/gid,17/Itemid,203/

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

Variable and routine stances seem widely known and practiced by many companies, even when products were chosen that would have been better served with aiming and shooting stances mentioned in the steering and anticipating pattern. Many companies and individuals appear to get stuck in the second stance as some sort of addiction to balancing, I suspect in shying away from awareness of The Great Unknown.

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.

You can find more on working with these stances, states or cultural patterns in the Quality Software Management series of JerryWeinberg: http://www.geraldmweinberg.com/books.html

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

---

This diagram attempts to capture how context switching affects work. The variables are:

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 http://wiki.systemsthinking.net/Systemsthinking/MultiTaskingForManagers.html 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 http://wiki.systemsthinking.net/Systemsthinking/MultiTaskingConsideredHarmful.html 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 http://wiki.systemsthinking.net/Systemsthinking/WikiWebUse.html 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 ]]>