The Dangers of Complex Adaptive Systems

October 3, 2009 — Posted by Al Shalloway

I have been told that this post misrepresents Complex Adaptive Systems by Jurgen Appelo, someone who knows more about CAS than I do. Since we do not have the opportunity for debate, I have decided to remove this blog post instead of possibly spreading misinformation about CAS - which was never my intent.

Alan Shalloway
CEO, Net Objectives

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Alan,

actually, at the enterprise level, the point is to realise that the enterprise is a CAS, and act accordingly. At the enterprise level, we (managers, process thinkers) are not the fish, we're the dolphins. We need to understand that just pushing the school to a direction won't make it go there, we need to find cleverer ways to make it move the way we want it to, like circling it.

Regards,
Pablo Emanuel

Pablo, thanks for this.I'll think about it. But it seems the dolphins had a strategy they all aligned to. Where did that come from?

My biggest issue with CAS is that it appears to be a way of explaining what happens.  As a consultant and practitioner I need a way that fosters the proper behaviors to emerge.   The notion of flow, limiting work, optimizing the whole, ...  enables me to do that. CAS can explain things - but don't see how it helps me decide what to do.  Do you (or anyone else) have an example of where it is?

Alan Shalloway, CEO Net Objectives

Alan,

there are some practical principles I inferred from CASs that I use in my day-to-day work. I divide them in two categories:

Dealing with CASs (usually large groups such as companies, big departments, cities, countries, etc):

  • CASs have homeostasis, and move through jumps - it doesn't help to try to push a CAS little by little, either you cause an avalanche or they'll stay where they are.
  • CASs won't react linearly. Sometimes the best way with CASs is to act on the effects, not on the causes (since there's so much feedback going on). It's the technique of force a smile to actually get happier.
  • CASs doesn't have a natural scale, i.e., sometimes you have to act globally, sometimes you have to act on the detail to get the result you want.

Inducing on systems the good features of CASs:

  • Short and abundant feedback loops
  • To achieve robust efficiency, CASs must have:
    • Redundancy: Each feedback loop must have a secondary feedback loop, no individual can be irreplaceable, etc
    • Variability: The distributions must have fat tails, instead of focus on just what happens to be optimal right now, allow for some different sub-optimal behaviour to exist, which must be exactly what you need in the future. For instance, new ideas must have room to grow, parallel projects must be allowed to drain a small percentage of the resources, people should be trained in skills other than the ones you need now.

In general, I agree with you. Lean is a set of principles that translate very directly to a set of tools that give measurable results. CAS theory can give you insight, but it's definitely not a roadmap, so, comparing CAS and Lean is indeed comparing apples and oranges.

Regards,
Pablo Emanuel

Pablo:Thanks. This helps tremendously. Gives me a completely different perspective of the value of CAS.

Alan Shalloway, CEO Net Objectives

In addition to thinking about the contrast between the geese and the mullets, it is worth thinking about the contrast between the behaviour of the mullets in situations where it does work and in the situation you describe. My guess is that most of its predators are non-social, and that the bunching behaviour works against them. If dolphins were their only predator, there would be strong selection pressure to develop the behaviour of just swimming off in all directions. I'm not sure what conclusions might be drawn about this for software development - maybe something along the lines of: some Agile practices work in some situations, but not in others.

Another thing to think about is: Is there an analogue to natural selection in software development methodologies? If all its predators begin acting like dolphins, then either there will be the odd mullet who swims away to survive and reproduce another day, or else they're going to go extinct. Does something similar occur in the way software development methodologies get reproduced, or else go extinct?

Andrew Blair

First, thanks for the post, Alan. I am always intrigued to know how others are applying system theory in their professional pursuits, and there are many great thought-provoking concepts in this article. I'll try to avoid diving down the rabbit hole, though, and just offer a few ground-level tips that have worked for me.

I agree with Pablo that CAS is not a roadmap or methodology. It is a set of scientific observations about the natural world that can offer insight into the dynamics of social organizations, such as businesses, but it is not prescriptive. In my view, CAS is the desired result, the item on the menu, and it is up to us to forge the recipe. So I do not agree totally with Pablo's statement that "the enterprise is a CAS." Rather, the enterprise is a complex system--a whole composed of many interacting parts--but the "adaptive" part needs to be earned and maintained. Most successful companies do begin as adaptive systems--innovative and opportunistic--but get locked into rigid, almost mechanistic, processes as they become larger and more established, making it harder and harder for them to adapt to the changing world around them. I believe one of the more significant challenges facing businesses today is how to retain (or regain) that agility in the face of rising global competition. CAS theory puts you in the right mind set but doesn't push any buttons or turn any gears for you. So how to become adaptive?

When it comes to adapting, all complex systems have one thing in common: evolution is a bottom-up process. CASs are distributed systems with decentralized control. There is no lead goose, head mullet, or central brain directing the behavior of all others in the group. Any member of the system can make independent decisions on behalf of the whole. Most companies don't operate this way, though. New strategies are established from on-high and new behavior mandated through top-down policy. Change does occur this way but I would argue that it is not adaptation. So, the most important lesson I have learned about applying system theory to business is that rigid, top-down, command-and-control style governance models are extremely counter-productive.

We don't need more leadership, we need more openness. In order to effect agility at the enterprise level, we need to address the flow of control.

I believe we need leadership and openness.  We are not trying to do evolution - we are trying to have a directed journey of improvement.  Can you show me one enterprise that has positively transformed itself without leadership?  Bear in mind, that by leadership I mean creating a vision of a better space and then coaching/training people on getting there.  Not how to do it, but rather helping people get the tools/knowledge to do it.

Too many agile teams think that if we just work together we'll figure it out.  Not likely if you are a big organization.  For that you need to understand how big organizations work.  Yes, CAS is a part of it, but systems thinking, flow and other concepts are incredibly useful to get the components of the organization a common vision so they can work together and avoid local minimizations.  All too often teams solve problems that aren't the real problem - that which is keeping the organization from moving forward.  You need to see the whole.

Alan Shalloway, CEO Net Objectives

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
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
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
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, 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
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban