Yes Virginia, You Can Attribute Cause-and-Effect even in Complex Adaptive Systems

October 16, 2010 — Posted by Al Shalloway

I am somewhat writing this blog in response to two things. The first is that over the last year I've had several complex adaptive systems "thinkers" out there challenge using lean-thinking to help teams because it supposedly relies on understanding cause and effect. The other is I'm planning to attend Jurgen Appelo's "Complexity vs Lean, the Big Showdown" at LESS 2010. I'll admit, I think understanding of CAS is useful, but when people tell me that I can't do things because of it I get turned off. I've been told for most of my 40 year career that I can't do things only to almost always figure out a way to get it done. I started off my career working under a brilliant person at the IBM Research lab on a team that designed the most complex chip (at the time) ever designed. It was called "theoretically impossible" to do before we started. I was the chump programmer on the project so don't claim any brilliance myself here.

Now, I admit transforming organizations is a lot more complex than solving software and design problems. As Gerry Weinberg says, "it's not a technical problem it's a people problem." Even so, I think there is a lot that can be done when you get people aligned and wanting to make a difference. So, I guess I'm optimistic on both a technical and a personal level.

I do believe I understand chaos theory and complexity theory to some extent. While I am an amateur compared to those truly in the field, I suspect I know more than most of the other amateurs out there. The thing is, not being able to predict (non-determinism) has been completely confused with not being able to control – particularly among many agilists. There is also a difference between micro-prediction and macro-prediction. See Types of Process by Don Reinertsen for more on this. Anyway, while I know you can't predict exactly how complex adaptive systems will respond, I do believe there are many things you can predict about them. Ironically, the weather, which is often used as the classic example of chaos theory (remember the butterfly effect), is fairly predictable at a macro-level (hurricanes don't tend to happen in the winter in Montana, for example).

In any event, I thought it'd be interesting to catalog some cause and effects of the complex adaptive systems called software development teams:

General laws for knowledge work:

  • Distrusting well intended, competent people will cause their behavior to be less useful than if you trust them 
  • If you distrust people and pretend you trust them, they will eventually figure out that you distrust them
  • Over-working people lowers their efficiency
  • If you treat people poorly, they will not work as hard for you as they would otherwise
  • People working on too many items lowers both their productivity and their resolve to do better
  • if you reward people based on particular measures, they will work more towards those measures than they will towards what you really want
  • if people ignore principles that effect their work, they will get inferior results than if they attend to them
  • if people don't have compatible visions of the future, they will not work as well together as a team whose members have a compatible vision
  • if people disagree on what is important and don't try to resolve the disagreement or work with it, this disagreement will cause challenges
  • people on a team attending to what they like instead of what works, lowers the functionality of a team

Some laws specific to software development work:

  • Not defining or validating acceptance tests with the customer (or their rep) before writing code tends to cause wasted effort
  • Not attending to code quality results in the degradation of the code over time, increasing it’s cost to maintain
  • When a developer writes code attending to only how they like code to be written, their teammates will have more trouble understanding it than if they attended to how their teammates will understand the code
  • Using archaic names for your code variables makes it harder for people (including the author) to understand the code’s intention than if intention revealing names were used
  • The time it takes to perform an integration is correlated to the period of time between integrations
  • if you don't get customer feedback quickly, you will write code a lot of code they really don't want (for any number of reasons)

Some laws regarding management:

  • if managers can't see what you are doing, they won't understand what you are doing (this does not imply they will understand it by just seeing it)
  • if managers ask you to do one more thing in your iteration and they don't know your process (or you don't have an explicit one) then when you say you can't squeeze it in they will likely think you just aren't willing to take the extra effort required
  •  if you treat managers without respect, you will get less respect in return
I would say I've got a few cause-and-effects here. Please leave others in the comments. Smile

My own belief is that you have to attend to creating a structure and system within which the appropriate behaviors you want will most likely emerge and then cultivate them.  Feedback is an essential aspect of agile methods because we lack determinism but have a great deal at our disposal about how to respond.  In my mind this is an important issue because it highlights a split in the agile community.  I've written about some of this before - see The Difference Between Inspect and Adapt and Plan-Do-Check-Act.

Bottom line for me is - how can we use theories of complex adaptive systems to help us do what we need to do and not tell us what we can't do?

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.


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