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:

• If you distrust your people their behavior will get worse than if you trust them
• If you distrust people and pretend you trust them, they will eventually figure out that you distrust them
• If you over-work your people you will lower their efficiency
• If you treat people poorly they will not work as hard for you as they would otherwise
• If you give people too many things for them to handle, it will not only lower their productivity, but lower their resolve to do better
• If you separate people by distance and.or time their ability to work together will go down
• 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 a common vision they will not work as well together as a team that has a common 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
• if people attend to what they like instead of what works it will be hard to get a functional team

And here are some on software development itself:

• if you don't define your acceptance tests actually with or validating with the customer (or their rep) before writing your code you will waste a lot of effort
• if you don't attend to code quality your code will degrade and be harder to maintain and update in the future
• if you write for just yourself, your teammates will have trouble understanding your code
• if you use archaic names for your code variables people won't understand your code as well
• if you take a long time bewteen integrations your integrations will take longer to do
• 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)

And finally (for now) some about management:

• if managers can't see what you are doing, they won't understand what you are doing
• 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.

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?