The Implications of Systems Thinking and Complex Systems

December 31, 2013 — Posted by Al Shalloway

I have just started writing a new book and there is a section in the introduction that I thought would be interesting to people.  It's called "Systems Thinking and Complex Systems."  Here is an early version.

I keep hearing that because we are working on complex systems we cannot have full coverage of what to look for.  I think it is just the opposite.  Because we are working on complex systems we must have complete coverage.

Systems Thinking and Complex Systems[1]

Complex systems are characterized by dynamic relationships between their related components.  One cannot understand the system by individually looking at any one or two or three components alone.  The system is not merely the sum of the components but rather it is the integration of the components, their relationships and the interconnections between them.  Systems thinking starts with understanding this.  You must recognize that you cannot investigate or learn about a system by decomposing it into its components. Rather, to learn how the system behaves, and more importantly, how to improve it, you must take an holistic view of the system.  A system thinker can investigate components of a system, recognizing that the sum of the components aren’t the system and that investigating the system while ignoring certain components that make it up will leave a faulty understanding of the system.­­

One of the salient characteristics of systems thinking is that it is the system within which people find themselves contributes greatly to their success or failure.  While we respect people, attention to the system is paramount.  In fact, it is precisely because we respect the people that we must strive for good systems.  Management must make this a priority and the people in the system, who typically know more about how it effects them than anyone else, need to be looking to continuously improve it.

The validity of this is easy to confirm.  Consider the job of a programmer who works side by side with a tester.  Further suppose the two of them work with their product owner doing acceptance test driven development.  As the programmer writes code, he not only can run his own tests, but the tester can run any additional tests he created.  The synergy improves understanding of what to do and the teamwork enables coding and testing to happen virtually simultaneously.

Now let’s look at a more prevalent system for coding and testing – a group of programmers who have a group of testers validate their work. Let’s further suppose the test team tests the programmers’ code a week after it is written. Whereas before, within a system of virtual simultaneous code and test, fixing discovered bugs is very quick, it will now be much harder and more time consuming.  Yet the programmer is the same.  Why the lower productivity and lower quality of resulting code.  The answer is obvious – the system.

Once we recognize the importance of systems, we understand that to achieve improvement of our methods we must improve the system we operate in.  But, if we remember that complex systems are interrelated, we must attend to all aspects of the system.  We cannot just say “create teams” while ignoring flow (or vice versa). When we start we won’t be able to attend to every aspect in detail.   And we don’t need to.  Part of our attention should be to ask – “which parts of the system do I need to attend to at the beginning?”

We appear to be in a dilemma.  Systems thinking requires us to look at the whole, while our limitations on beginning new things means we can’t look at everything.  So what do we do?  We need to be at least aware of the forces present to attend to.  There really aren’t that many and most of the ones we need to start looking at center around delays in the workflow and in feedback cycles.  These types of delays are caused primarily by:

  1. Too many things being introduced into development
  2. What is being introduced into development is too large
  3. Co-located, cross-functional teams do not exist forcing people to wait on others
  4. There are too many things in play at any one time
  5. Teams are not coordinating well so that they work on related things at different times causing integration errors later
  6. Developers and testers are not coordinating well

Note how these interact with each other.  It’s important to note that the common practice of limiting WIP directly only addresses two of the above. It's a bit naive (dogmatic?) to suggest we should always start by addressing one particular issue.  Virtually every one of the above issues will have an adverse effect on the others - making for a downward spiral.  Instead we must look at a variety of potential solutions (these relate to the prior list):

  1. Institute a pull system by development where work does not get to the team except when it pulls it from a sequenced queue
  2. Use minimal business increments to work on the most important items
  3. Create co-located cross-functional teams to the extent possible (see a 3-part blog on why this is important as well as how to do it).
  4. Set WIP limits on each stage of the work flow (including queues)
  5. Teams coordinating with each other should pull the work in a coordinated fashion so that work does not begin until all the necessary people and resources are available
  6. Use acceptance test-driven development

We don’t need to address all of these issues at the beginning, of course.  But we should be aware that they exist.   We can ask a series of questions to see where we should start (these relate to the prior list):

  1. Will management cooperate to restrict work hitting the team?
  2. Can we convince stakeholders to use MBIs?
  3. To what extent possible is it to make committed, cross-functional teams without adversely impacting the rest of the organization
  4. Do we have a stable enough system where setting WIP limits will do us some good?
  5. Do we have teams that are working together?  Can we use common backlogs so that they work on things in a coordinated fashion
  6. Are our product owners/Bas, programmers and testers willing to use ATDD?  See How to Start with ATDD to see the different ways to start.

By recognizing we need to consider all aspects of the system yet knowing we must phase them in, we start at a high level and drill down only when there appears to be benefit.


[1] Thanks to David Snowden for his insights in this area.

 

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile