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

The product development game

During the Innovation Games® summit held in San Jose, CA in January, 2013, Tom Grant gave a keynote presentation titled “It is time to change the rules at work”.

Grant characterized the state of product development as follows:

  1. Complexity: Our software products are so complex to develop, maintain and implement.
  2. Poor customer insight: We as developers don’t understand what the customer value is. Therefore, our software is not providing new opportunities to the customer which creates business growth or addressing real pains.
  3. Lack of understanding of how customer is like at work: Generally, we donot understand the customer’s world. Developers in many cases are expected to create products for various industries, for example, banking and health care.
  4. No honest conversation with our customer: Normally we don’t like customers or at least we are not sincerely trying to help them. We even call out them by phrases like:
    They don’t know what they want or even we claim that they don’t know their own business. The customer change their minds too often. No one is available to answer development team questions and so forth.
  5. Dysfunctional team: The cross-functional team who develops the product lacks productive communication. Team members don’t collaborate to figure the business value to our customer. Moreover, team members are from different non-aligned groups which add inefficiencies. Continue reading

Lean view on Product Owner (PO) role

But they’re supposed to have PO, aren’t they?

In IT enterprise product development, I have found how vulnerable the PO role can be. This is because the demand on delivery team arrives from various sources. Moreover, the demand is not necessarily representing product features, but instead it can be any required service.


If we want to implement PO role in this set-up, the Lean objectives can be impacted because of the following reasons.

Continue reading

Treating users as players in Agile implementation

Gamification became a main stream approach for marketing as well internal operation of the enterprise. In this post I will talk on one aspect which is understanding the users and categorizing them for Agile implementation.

There have been so many discussions about Agile transformation and how it is eaten by the culture. My argument is that there is only one action we should do toward a company’s culture, which is Respect. Rather than changing the culture, we should focus on more intuitive light weight approach for Agile implementation which is above all should be Fun for the users!

The Agile mind-set changes the roles of traditional project management to become self-organized and team empowerment. For me this is the toughest change and normally takes time. What about if we treated the users (team members, Scrum Master, Business Analysts, UX, Admins and others) as  players?

Bartle Test of Gamer Psychology provides perspective for categorizing players in a gamified system which could be applied to users in Agile adoption.

Gamifiying Agile adoption means creating well designed activities to encourage desired behavior from implementing Agile. The activities should be intriguing to the users so that they are motivated to show the required behavior through implementing those activities.

How a project manager changes so that he can give-up autocratic approach to support empowering a team to sign-off for its own tasks?

The focus should be shifted into designing activities which are rewarding and enabler to the desired behavior. Driven by Bartle’s we could have project managers as:

  • Socializers: Those who primarily want to network with peers in the organization to enhance their Agile understanding and implementation. The human-interaction focus of Agile is particularly appealing to socializers.
  • Explorers: Those who want to explore independently every activity of Agile and to define their role related to each.
  • Achievers: Those who, regardless of rewards, want to prove that they master as many as Agile activity as possible and demonstrate exceptional quality in Agile project management. They want recognition as to be praised by socializers.
  • Killers: Those want objective evidence (e.g. metrics) to prove they beat their peers in implementing Agile.

Gamification activities should be designed bearing the above categories in mind.

At the heart of gamification is the player-centered design which requires careful understanding of Bartle’s categories as it makes sense in the context of Agile adoption.

Let’s respect the culture and center Agile implementation around our players for motivating the desired behavior through having fun!