Is it time to rethink A3 in knowledge work?

A3 is a collaborative method for driving improvement by the team. A3 is based on the ability to envisage the future state “by the team” and create plan to bridge the gap with the current state.

According to Complexity Theory and the CYNEFIN model, I believe product development fits in the Complex domain. Please see this video by Prof. David Snowden talking on Complexity Theory. In Complex Adaptive System it is required to understand carefully the current state, however we should not try to envision the future state which is against A3 thinking.

The reason of the above is that A3 was originated from manufacturing which values predictability and uncertainty control. The carving for having repetitive process is behind locking the future state from upfront.

Product development has characteristics which are non congruent with A3 thinking.

  1. A key to success in product development (PD) is to learn  how to embrace uncertainty.
  2. PD is a Complex system where the team and the system co-evolve based on given constraints (for example technology employed) and within attractors (rewarding system).
  3. In PD practices emerge instead of being dictated or planned for. Such practices are context based. 
  4. The team interacts with the system through safe-to-fail parallel experiments with contradicting purposes.
  5. Every experiment creates knowledge and pave the way for a new one. Nevertheless, at some moment the team shifts from experimentation to “exploitation” to scale its practices.

Prof. Snowden created this ACTION_forms_2013_01_edition to help in experimentation to probe a Complex system.

A3 Thinking was not meant to handle experimentation but instead to create a concrete plan to reach the future state. This thinking is contrary to PD because of the above characteristics.

Chef vs. recipe book approach for managing product development

The chef and recipe book metaphors were originated from the work of Prof. David Snowden on Complexity Theory.

Recipe book approach suggests the implementation of specific frameworks to achieve the value from certain practice (Agile). This will require the organization to re-engineer (or transform) itself, at its own cost, so that those frameworks can be implemented.

On the contrary, Chef based approach does not dictate pre-configured set-up as pre-requisite to achieve the value from implementing the practice. Instead, the chef uses whatever is there to create valuable implementation of the desired practice. The value the chef delivers allows organizations to evolve and thus gradually restructure as they become motivated by implementation gains. Specifically, the chef understands how to deal with unusual scenarios which can happen when conditions change. This is because the chef has developed knowledge over years of implementation and following instructions.

Advocating Inspect and Adapt without understanding these two approaches cannot help. In absence of a chef, Inspect can lead to superficial improvement suggestion which can produce mediocre outcome from Adaptation.

The chef approach leads to evolution of the system to new states which cannot be defined up-front. The chef has the ability to guide teams (Inspect) so that they can come up with options implementable by them (Adapt).

A good agile coach implements a Chef based approach. He can help the team and system to interact together so that they can evolve to a target state which is being shaped as we go. The agile coach can help to introduce the mind-set of conducting fail-to-safe experiments by the team, so that it can probe a direction for improvement. Probing the direction can lead to sensing what approach to follow.

In contrary relying only on recipe book (for example, strict implementation of Scrum events and roles) will require pre-configuring the organization roles and teams to fit into cookie-cutter structure to achieve the up-front defined future state. In this mode we can only expect reaching this target state with no real value. For that reason, recipe book approach deprives the organization from improvement opportunities which can happen if it embraces uncertainty and experimentation.

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. Continue reading