Characterizing product development in light of Complexity Theory

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.

Prof. Snowden- Practice without sound theory will not scale

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.

Fail-to-safe experiments

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.

Cynefin 001xA

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.

3 thoughts on “Characterizing product development in light of Complexity Theory

  1. I take pleasure in, cause I discovered exactly what I was taking a look for.
    You’ve ended my 4 day long hunt! God Bless you man. Have a nice day.

  2. Excellent beat ! I would like to apprentice while you amend your website,
    how could i subscribe for a blog site? The account aided me a acceptable deal.
    I had been tiny bit acquainted of this your broadcast provided bright clear concept

  3. Can I simply just say what a relief to discover a person that actually understands what they’re discussing on the web.
    You definitely know how to bring a problem to light and make it important.
    More people have to look at this and understand this side of the story.
    I was surprised you are not more popular because you most certainly have
    the gift.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s