Complexity theory has had many people believe that predictions aren’t possible in complex systems and that emergent change is the only way forward. But it is important to understand that while knowledge work and many kinds of projects are complex, embedded within the complexity are fairly straightforward relationships. I call these the laws of Flow, Lean and Theory of constraints because these models explain what they are and how they work.
True, these may not be real laws like gravity, but they are reasonably accurate and provide guidance. They are not mere guidance but more fundamental principles on which to create guidance. Here are a few.
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.
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-Study-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?