Understanding the challenges present in changing behavior is important. There are many models about complexity in the world of software development and what that means. t simple, complicated, chaos and complex events. While discussed by many, some of these discussion ignore three salient points:
Some quick definitions
There are different types of relationships between different entities. These relationships are more or less easy to understand. The behaviors between the entities also change based on these relationships. While it is not really possible to define a relationship as specifically this or that, it is possible to define aspects of these relationships. We will use the following definitions:
Simple means there is a well defined relationship between an event and the resulting action from that. Dropping a pen and seeing that it will fall is a simple relationship. Or, if one wants more accuracy, there may be other factors (such as wind velocity) taking it out of the simple domain. Doing this in space may be a more complicated relationship. Hence, relationships may be simple but not in all contexts.
Chaos is a result, not an event. Its definition is “complete disorder and confusion” as in “snow caused chaos in the region.” It can result from behavior so unpredictable as to appear random, owing to great sensitivity to small changes in conditions.”
Chaotic event is an event that is unpredictable even if there is an underlying science. The “straw that broke the camel’s back” and the “butterfly effect” where a butterfly flapping it’s wings in Asia can theoretically cause a typhoon on the west coast of the US. These are often called “non-linear” events since a small change may cause a large change.
Complicated systems are when there are several well-defined relationships between cause and effect. If all of these relationships are known then we can predict the outcome of the actions. Launching a rocket is an example of complicated.
Complexity means that the exact relationships between things are neither known and possibly unknowable. Complexity does not mean general predictions can’t be made, but that exact predictions cannot. For example, weather is complex, but there are patterns to weather we can learn.
Difference between inherent nature and what we understand
Many things that appear complex in the past were really just events for which we had no understanding. See Complexity Is Not What it Used to Be for an example of what appeared to be complex, was solved by someone, but couldn’t get it adopted because of the lack of understanding.
Taking a Systems Thinking point of view
Systems Thinking provides us with two main tenets:
What this means is that a system likely exhibits all 4 types of events: simple, complicated, chaotic, and complex. And definitely all four if people are present in it as people’s behavior is complex. See People Are Complex, Software Development Isn’t.
How to manage chaos and complexity
Chaos from chaotic events and complexity
While chaotic events and behavior of complex systems, by their very definition, can’t be predicted, they can be controlled. In the case of business development where a goal is intended, feedback is essential. This enables the unplanned for actions that occur, such as misunderstandings and creating errors, to be attended to quickly. The negative impact of these unplanned actions can thereby be mitigated. Reducing delays between the incident and its mitigation is critical. Particularly in knowledge work and software development where a delay in detecting an error can cause a great amount of additional unplanned work.
This is the driving force for quick feedback. We can always introduce errors into our system. If we can find them quickly, we can eliminate most of the impact of the error.
Chaos from simple and complicated systems
Chaos can result from simple and complicated systems as well. When systems are overloaded, that is, they have more work in process (WIP) than they should, this will introduce delays in workflow, feedback and using information. This alone will cause problems (new unplanned work) as well as exacerbate any challenges from the chaotic and complexity described above. Managing WIP is therefore very important. Two related articles are:
Predictability vs. repeatability in complex systems
There is a difference between predictability and repeatability. But before discussing those, let’s look at two types of predictability – micro and macro. Micro-predictability refers to a particular event while macro-predictability refers to the result over time. Consider that one can’t accurately predict the result of a coin flip but can predict that over time a fair coin will come up heads as often as tails. If the coin isn’t fair, it’d be a good bet that the results of the second thousand flips will match the results of the first thousand flips – hence macro-predictability.
While complex systems are inherently unpredictable, it is possible to constrain them so as to increase predictability of an aspect of the system. This can result in repeatable results. For example, automated testing and lowering technical debt can greatly increase the predictability of changing code. Repeatability of results in complex systems requires:
It is important to understand that achieving repeatability is one thing and maintaining it is another. It is easy to fall back into past habits before predictability was achieved. This is why management and teams must work together with regular retrospectives to ensure the continued predictability. As understandings change so must systems. These retrospectives must be geared toward continued improvement – systems are either improving or decaying, there is no stasis.
It is also important to remember that achieving repeatability does not mean the system is predictable when new changes are attempted. Complex systems by their nature are not predictable. We can work with them, but when people are involved, complexity will always be present.
See Types of Process by Don Reinertsen for more information.
Your method is part of the system
When a transition to new methods is attempted, the actions being attempted become part of the system. This is why one should consider the effect of following a particular approach will have on your organization. That is, include people’s reaction to Scrum, Kanban, Kanban Method, SAFe, FLEX, DAD, LeSS, etc. The method you are using becomes part of your system. This should be accounted for in the design of your approach. Many approaches take a different attitude about how they will/should affect the system. For example, Scrum suggests that impediments to doing Scrum should be removed. This works in some contexts, but not so well in others. Lean suggests taking a systems thinking point of view so that any adjustments to your workflow must consider the value streams being affected.
Disclaimer and Acknowledgements
This article is not intended to be a representation of Dave Snowden’s Cynefin model or Jurgen Appelo’s work. While this paper has been influenced by them, no more so than many articles and ideas going back 4+ decades.