Disciplined Agile

Laws of Flow, Lean and Theory of Constraints

Most everyone agrees that complex systems make it so accurately predicting what will happen when changes are made to a company’s way of working is not totally possible.  Although emergent behavior is necessary there are many things we can know about how complex systems will behave. It is important to see that the behavior of systems is determined more by the relationships between the components of the systems instead of the components themselves.

These relationships are often well defined and universal. They can be thought of as natural laws.  The theories of Flow, Lean and Theory of constraints discuss these. Understanding these laws enable taking action that will either lead to improvement or learning.  The learning is often in the form of discovering new relationships between items in a system or understanding those that were previously seen better.

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?

Additional resources

Dealing with Complexity by Creating a Bias For Simplicity. This is based on inherent simplicity by Dr. Eli Goldratt (creator of the Theory of Constraints).It provides a more actionable approach to dealing with complexity than sense-making frameworks.