Prof. David Snowden created the Cynefin framework to characterize various domains or systems. Understanding the characteristics of a domain can help us to not only gain understanding on its intricacies but also to establish suitable approach to manage it.
In my view product development fits into Complex domain (non-ordered system) since it assumes the following characteristics.
There is no repeated relationship between Cause and Effect.
This is because every product is unique and has to bring new features to the end user. In other words, repetition in product development is against bringing innovative ideas. Specially, instead of controlling variation, we embrace uncertainty because it is our opportunity for discovering new features. Generally, retrospective in Complex domains can help us understand what happened in the past but these insights can not allow us in predicting the future.
Product team interacts with the system.
In Ordered domains (Simple and Complicated), the agent (team member) is controlled by prescriptive process and best/good practices. Whereas in product development we can not impose such practices on the team, rather the team invents the practices which work for it based on the context.
We can not define a Target State of the product.
To contrast, Systems Thinking is based on:
- Understanding Present State and root causes
- Define Target State
- Create plan and activities to bridge the gap between Present and Future States.
Complex System on the other hand advocates that it is impossible to define the Target State. We can only clearly define the Present State and conduct the work through safe-to-fail experiments.
Think resilience instead of up-front robust design.
Instead of having big upfront product design, the team embarks to sprints which act as safe-to-fail experiments. The knowledge which each experiment creates help to provide direction and is not meant to mitigate risks which can destroy system capacity to innovate.
There is constraint set by the system.
Product development can have many constraints established by the market, organization and end user. A key constraint could be Cost of Delay of a feature. Meaning delaying the deployment of a certain feature can be prohibitive and therefore the team has to deliver a sound implementation of the desired feature by the deadline. Both team and the company evolves within the given constraint (Co-evolution). Without constraint there can not be co-evolution.
Complex System values stories instead of process and specs.
We as human are geared to learn through story telling much more than procedures and instructions. In product development, we tell the team a story and it creates the corresponding working software. In other words, we do not give specs to the team.
The above characteristics represent sound theory helping us to enhance and scale Scrum/Agile implementation. Prof. Snowden said the way to deal with Complex System is to “manage the emergence of beneficial coherence within the attractors within the constraints.”
For me the sprint is a natural time-box for the team to conduct an experiment. Although the stories are known early at sprint planning, however, in typical product development those stories are merely guesses. The experiment is tested at the end of the sprint during the sprint demo. Moreover, Prof. Snowden advocates not having one experiment but instead create multiple parallel experiments which contradict with each other. I am always faced with teams who do not know which design approach can work or will be acceptable to the customer. This can be translated into parallel Scrum teams each is working on a different design approach.
The Complex domain is the domain of “exploration” where the product team experiments to shape the desired product feature. Product team interacts with the system through fail-to-safe experiments, being self-organized(coherence) and have the experiments finely grained. However, sometimes the team should “exploit” the experimentation to deploy the desired product features. Exploitation lends itself to the Cynefin Complicated domain, which is an ordered domain but requires analysts to figure a suitable development approach.
To summarize, Complexity Theory can be used as a tool to comprehend the involvement in product development. For instance, mapping the elements of product development to the above characteristics can result better understanding of management and teams, which can allow them to scale product development.