More than a shared understanding is required

Posted on March 1, 2015 by OpLaunch

To be very successful in new product development, more than a shared understanding is required.

A Common Perspective on Shared Understanding

In some cases, a shared understanding is facilitated during ideation (brain storming) sessions with a diverse group of individuals guided by a facilitator. The progress toward agreement may be managed by creating and arranging sticky notes and voting. In some cases, ‘shared understanding’ implies consensus. In some cases, certain opinions are promoted by the most dominant personality in the room or the Highest Paid Person’s Opinion (HiPPO).

This type of shared understanding facilitates progress in a Big Design Up Front (BDUF) context. A shared understanding promotes a feeling of confidence when requirements are written.

Note: For this post, I am not addressing the benefits of project artifacts such as style sheets, templates, and processes. These tend to promote consistency. They do not drive shared understanding.

Shared Understanding and User Stories

Recently, I have noted that the meme of ‘shared understanding’ is being associated with the requirements for user stories. The assumption seemed to be that ‘when there is a shared understanding within the development team, requirements can inform the writing of user stories.’

Challenging Shared Understanding

A shared understanding is problematic when it is incorrect or insufficient. Memes that are incorrect or insufficient are insidious.

Better Understanding

Instead of a shared understanding that may be insidious, strive to develop a network-informed, self-correcting understanding. Strive to improve the capability to detect mismatches.

Mismatch: the difference between the phenomena that is observed and the conceptual description of that situation.

A better understanding improves through cycles of synthesis, testing, and observing interactions between proposed solutions and stakeholders (such as customers, sales representatives,…). Development networks that can deliver and test prototypes are positioned to appreciate the trends that emerge and adapt to provide better solutions more efficiently.

A development network can achieve a shared understanding or, better yet, they can improve their capability for a better understanding. Shared understanding can be achieved in the isolation of a conference room. The capability for better understanding can be accelerated through interaction between stakeholders (including potential customers) and prototypes. Instead of prematurely accepting requirements, hypotheses can be validated.

Impact on Development Experience

When a development network has ample potential to improve capabilities that they value, individuals (such as designers, engineers, subject matter experts, …) are more likely to be motivated. The development environment facilitates the improvement of factors such as autonomy, mastery, and purpose. Such environments promote a culture where the quality of the Development Experience [DX] enables multiple successes.

Antifragility in New Product Development

Posted on April 30, 2014 by OpLaunch

In the book Antifragile: Things that Gain from Disorder, Nassim Nicholas Taleb shared insights on optionality that can be expanded to include new product development environments.

This post provides an introduction to the non-linear gains associated with antifragile systems that may be realized by designing new product development environments that help individuals improve their capability to synthesize many new options continuously and enhance their proficiency to exercise options that are attractive. This post includes a comparison to concepts represented in Boyd’s OODA Loop sketch.

Fragile, Robust, Resilient, and Antifragile Development Environments

Taleb’s classification of systems as fragile, robust, resilient, and antifragile may be used to characterize development environments. Every development environment can be characterized in terms of its fragility, robustness, resilience, and antifragility.

Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb

A development environment that tends to be fragile does not welcome disorder. When uncertainty is injected, the results may be unpleasant.

In a fragile development environment, one obstacle can prevent the realization of value. Examples of harmful conditions include:

Incorrect, incomplete, or misleading information
A problematic handoff between functional groups
Disagreements among functional groups

Unpleasant results may include delays, cost overruns, and insufficient adoption of the product. Individuals tend to be frustrated. The more fragile the development environment, the less likely it is to thrive.

From project-to-project, a robust development environment tends to survive unchanged. Processes tend to be preserved. Individual contributors tend to retain their employment status.

From project-to-project, a resilient development environment survives changes from external factors. After a project is complete, there may be changes such as a re-arrangement of the organizational chart. New tools may be incorporated. The organization survives to serve the needs of the next project.

The word ‘antifragile’ is an adjective created by Taleb. It can be defined as the exact opposite of fragile. According to Taleb, “Antifragile is beyond resilience or robustness.”

An antifragile system thrives and grows when exposed to a moderate amount of volatility, randomness, disorder, and stressors. An antifragile system benefits from a moderate amount of adventure, risk, and uncertainty.

Iatrogenesis

In Chapter 7, Taleb described the concept of iatrogenics as “damage from treatment in excess of the benefits.”

Iatrogenesis: preventable harm resulting from the treatment or advice of a healer.

The word iatrogenesis is not common in product development but harmful inputs may come from multiple sources. These include:

Specialists that assume that solutions to development problems relate to their area of expertise.
Innovation pundits, consultants, and vendors that offer their favorite tools and techniques as solutions
Interventionalists that believe that their contributions will improve outcomes
Status quo

It may be difficult to recognize the harmfulness associated with specific sources because of cognitive biases or unvalidated claims. Recognizing harmfulness is more difficult in development environments that isolate individuals of different functional specialties.

New product development efforts can suffer from iatrogenesis. Approaches to recognize potentially harmful inputs and reduce potential damage from harmful inputs include:

Requisite Variety
Disintermediation
Pair Development

Requisite Variety

The concept of requisite variety can be used to emphasize the importance of having a diversity of potential responses in a development environment.

Requisite Variety: For a system to be viable, only a variety in responses can force down the variety due to disturbances.

The Law of Requisite Variety was formulated by W. Ross Ashby

For a development environment to be successful, only a large repertoire of possible responses can address the variety presented by a complex set of development problems that emerge throughout projects.

In a new product development environment, requisite variety may be achieved by mobilizing a network of contributors with diverse specialties and multiple perspectives. To be successful, individuals may require additional training, access to individuals with unique expertise, and cooperation.

Without requisite variety, previously successful responses to familiar patterns may not be recognized as insufficient responses.

Without a variety of potential responses at the appropriate times, a development environment may be fragile.

If there is excessive variety, the agility of the development environment may be reduced. To ensure appropriate adaptability, the network determines that certain responses should be amplified. Other responses are attenuated.

Disintermediation removes layers between individual contributors and data. It removes barriers between decision makers. One way to facilitate disintermediation in new product development environments involves individual contributors experiencing the interactions of customers with prototypes (or other experiments related to the product being developed). Direct observations that promote full-fidelity interactions are preferable to mediation approaches such as presenting individuals with reports that summarize activities.

Pair Development is implemented by facilitating the interaction of individuals of different disciplines (such as a coder and a marketer). Pair development provides an opportunity for interaction through activities such as dialog and sketching. The result of pair development should be the synthesis of options, not a summary of previous activities. Typically, no slides sets are used during these interactions.

Pair development in new product development

The result of pair development is the synthesis of options that is informed by the analyses available from multiple perspectives.

The purpose of pair development is not cross-training. The purpose is to develop a self-correcting focus and direction informed by the analyses of multiple perspectives.

Reducing iatrogenesis is a pre-requisite to synthesizing more attractive options.

Typical Options

A typical option, such as a financial option, provides a buyer with the potential to take action by a specified date without an associated obligation to buy or sell. Typically, an individual decides to exercise an option based on their perception of value at a specific time.

According to Taleb, optionality is the property of asymmetric upside (preferably unlimited) with correspondingly limited downside (preferably small).

Optionality: a quality of state where choice or discretion is allowed.

In Chapter 12 Taleb stated that “An option is a substitute for knowledge” In Chapter 13, Taleb wrote “antifragility supersedes intelligence.”

The value of a typical option depends on factors such as the negotiation skills of the individuals involved and the type of control individuals have over their decisions. Development options require additional proficiencies.

Example

Taleb summarized the experience of Thales, an ancient philosopher. Thales acquired an option to use equipment that may be needed during next year’s harvest. His potential profits or losses were not be determined solely by the accuracy of a crop forecast. If there was an abundant harvest, he could exercise his option for the equipment and be rewarded financially. If the harvest was scarce, he could decline his option and not suffer a loss. The harvest was bountiful and Thales built a substantial fortune.

Development Options

To improve the potential for success in new product development environments, an option must be more than a negotiated agreement based on a speculation. Development options are the most valuable when associated with current capabilities or a capabilities that may be acquired within an appropriate amount of time for an appropriate cost within the project constraints.

The approach to development within a network of individual contributors includes the interplay of capabilities with analyses and synthesis.

Synthesis is a process of connection. Synthesis generates something new and different. A synthesis approach enables one to imagine how a several capabilities may work together to produce the desired result.

In a properly designed new product development environment, proficient individuals analyze situations and synthesize new options continuously.

The interplay of synthesizing options and exercising options to improve antifragility

The interplay of synthesizing options and exercising options improves antifragility

The interplay of synthesizing options and exercising options includes interaction with the environment (feedback) that enables a network of individuals to comprehend, shape, and adapt during development. This enables operation at faster tempos and rhythms and the compression of cohesive observation-orientation-decision-action time cycles.

The capability to synthesize many development options and exercise a few attractive development options rapidly and repetitively enables a properly prepared network of individual contributors to realize non-linear gains that are not possible by alternate approaches such as ones that focus on managing mandates.

Comparing Development Options to Concepts Represented in Boyd’s OODA Loop Sketch

Concepts related to development options have similarities with concepts represented in John Boyd’s OODA Loop sketch.

The concept of synthesizing development options is similar to the Observation and Orientation items represented in Boyd’s OODA Loop sketch.
The concept of exercising development options is similar to the Decision, Action, and Unfolding Interaction with Environment items represented in Boyd’s OODA Loop sketch.
The outcome from cycles of synthesizing a multitude of development options and exercising a multitude of development options is consistent with victory and the representation of a “series of maneuvers” in an OODA Loop context.
The non-linear gains associated with exercising attractive options in antifragile environments are similar to Boyd’s themes for vitality and growth.

Concepts related to development options have similarities with concepts represented in John Boyd’s OODA Loop sketch. Synthesizing development options is similar to the Observation and Orientation. Exercising development options is similar to the Decision, Action, and Unfolding Interaction with Environment items.

Enhancing Optionality throughout Development

For each development project, the goal is to change the environment to improve the capability to synthesize a multitude of development options and exercise a multitude of development options that are attractive. To increase this capability throughout development, invest to improve the following objectives:

Design the development environment to embrace optionality
Produce new repertoire based on theory and refined by practice with others seeking a high level of proficiency. This requires a sustained, deliberate effort.
Develop the capability for rapid cycles of observation, orientation, decision, and action which is based on the OODA Loop concept from John Boyd.
Improve the capability to shift rapidly between options which is similar to the concept of Fast Transients from John Boyd. This is similar to improving agility.
Improve the capability of individuals to synthesize options that are cohesive across the network and cohesive over the duration of the project(s).
Improve the proficiency to exercise attractive options. Identifying attractive options includes developing a holistic perspective and recognizing iatrogenesis.

Antifragility and Development Experience

Individual contributors invest much of their time in new product development projects. Their personal investment is what Taleb refers to as “skin in the game.” I refer to an individual contributor’s day-to-day and year-to-year set of perceptions and responses as Development Experience [DX].

There are multiple approaches to improve an individual contributor’s development experience by reducing fragility, increasing robustness, or increasing resilience of the development environment. An individual contributor’s development experience may improve dramatically by designing the development environment to improve antifragility. According to Taleb, “The option is an agent of antifragility.” Options make vitality and growth possible.

Development options are agents of development experience. Development options drive non-linear gains in antifragile development networks. Designing to improve development options stimulates better performance from individual contributors even when there is volatility. This inspires better performance from others. This creates virtuous circles, beneficial cycles of development efforts. This inspires greater commitments to project success.

Additional Information

1. Taleb includes Post-Traumatic Growth as a characteristic of antifragility in Table 1 in his book. In “Beyond Surviving New Product Development” I defined:

Post Development Growth: the positive changes experienced by individuals that result from enhanced new product development capabilities. Post Development Growth includes reflection to achieve cognitive clarity. It goes beyond reflection to action.

An antifragile development environment is more likely to produce Post Development Growth. This tends to enable better outcomes in future projects.

2. A fragile development environment is consistent with the model introduced in “The Devastating Zero Model of New Product Development.”

3. Too many inputs may be harmful because it may be difficult to discern the valuable from the harmful or signal from the noise. Too many inputs reduce a network’s agility. A requisite variety approach must include ways to evaluate potential contributions to project goals. One approach is the development of “continuously correcting, network-informed schwerpunkt” described in my Reimagining How New Product Development Artifacts Impact What We Should Be Doing Today post.

4. This post included extracts from my book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop”

[Requires iTunes or Apple Quicktime. Duration 15 minutes]

Antifragility in New Product Development [ 14:45 ] Play Now | Play in Popup | Download

An Alternative to Herding Cats in New Product Development

Posted on October 31, 2013 by OpLaunch

In some new product development (NPD) organizations, managers may feel that they are herding cats. Other organizations embrace a different approach and produce better Development Experiences [DX].

Herding Cats

Herding cats is an idiomatic saying that refers to an attempt to coordinate an intractable situation where individuals that are part of a team tend to do very different things. A manager may say “Managing developers is like herding cats” or “Managing designers is like herding cats.” When managers use this phrase, they may be invoking a stereotypical treatment of specific contributors. Alternatively, the phrase may be used to convey the frustration that arises from moderating disagreements between groups such as marketing and engineering.

My search of LinkedIn today returned 749 results for the phrase “cat herder.” There were 2101 results for “herding cats.”

One humorous treatment of this type of situation was depicted in the Cowboys Herding Cats advertisement in 2000.

The Development Experience where there are Cat Herders

When someone works in an organization that includes cat herders, the following cultural characteristics may be present:

The prevailing development approach relies on explicit coordination. The roles and responsibilities of individual contributors are documented extensively. Processes and checklists govern day-to-day activities.
Resources are considered to be interchangeable. The common belief is that one engineer can be substituted for another with similar qualifications.
It is assumed that the development environment is relatively stable and predictable. It is assumed that the cat herder will be able to manipulate behavior within the development environment. It assumes that the cat herder knows the criteria for success.
Cat herders shop for cat herding tools that incorporate the latest technology and fads. They do not refer to their tools as cat herding tools.
Cat herders transition from deadline to deadline.
Some individual contributors may be satisfied producing specified deliverables on specified dates. They may be glad to be working in an environment that embraces hand-offs between functional groups.

Orientation and Interplay

In Boyd’s OODA Loop Sketch, (Boyd, The Essence of Winning and Losing, 1995) the Orientation component includes the interplay of the following items:

Genetic heritage
Cultural traditions
Previous experience
New information
Analyses & synthesis

: The Orientation component from Boyd’s OODA Loop Sketch from “The Essence of Winning and Losing” 1995

The previous experience item includes a representation of an individual’s knowledge, skills, and capabilities. Some relevant experience is a result of specific training and deliberative practice.

Analyses is a problem solving approach that divides the whole into its constituent parts.

Synthesis is a process of connection. It generates something new and different. Synthesis benefits from inputs from a network of individuals with a diverse set of specialties. A synthesis approach enables one to imagine how a series of techniques may work together to produce the desired result.

Orientation and Schwerpunkt

Orientation can be defined as the way an individual approaches development. The appropriate orientation provides a unifying focus that pervades the development environment.

John R Boyd stated “Orientation is the Schwerpunkt. It shapes the way we interact with the environment—hence orientation shapes the way we observe, the way we decide, the way we act.” (Boyd, Organic Design for Command and Control 1987, 16)

The literal translation of schwerpunkt is “difficult point.” Carl Philipp Gottfried von Clausewitz (1780–1831) described schwerpunkt in “On War” which was published posthumously by his widow in 1832. Schwerpunkt conveys strategic objective, goal, or destination. Schwerpunkt is any concept that provides focus and direction to development. It provides actionable guidance in situations where there are no explicit directions. It reinforces mutual trust. It contributes to a focus on the results.

Schwerpunkt is a concise version of your strategy. It can be communicated in one sentence. In a military context, a schwerpunkt example is “Control the city in 72 hours.” For the Toyota Production System, it is about shortening the time it takes to confer customer orders into vehicle deliveries.

Schwerpunkt “acts as a center or axis or harmonizing agent.“(Boyd, Patterns of Conflict #78)

Schwerpunkt is “A focusing agent that naturally produces an unequal distribution of effort as a basis to gain superiority in some sectors by thinning-out-others.” (Boyd, Patterns of Conflict 78) Schwerpunkt guides individuals when they set priorities. It clarifies what to next to add value to your efforts.

The preferred orientation is implicit. In a development context, the intended meaning of implicit is closely connected, joined, interwoven, and intertwined. It is what you do without prodding from cat herders.

An Improved Development Experience

When a well-crafted, shared orientation exists throughout a development network, the development experience will be characterized by an abundant amount of cooperation, collaboration, and harmony. The development approach will be more recursive. Problems of a similar type will be solved instead of waiting for handoffs. Small continuous adjustments that are created simultaneously across specialties will cumulate and create substantial change.

Needs are anticipated. Dynamic adjustments are made. Multiple interdependencies are managed. Friction is diminished. Network efficacy, the shared belief in its capacity to successfully develop a specific item, increases.

Developing Orientation

Boyd had advice for developing a better shared orientation in military contexts:

“Arrange setting and circumstances so that leaders and subordinates alike are given opportunity to continuously interact with external world, and with each other, in order to more quickly make many-sided implicit cross-referencing projections, empathies, correlations, and rejections as well as create the similar images or impressions, hence a similar implicit orientation, needed to form an organic whole.” (Boyd, Organic Design for Command and Control 1987, 23)

For new product development contexts, ‘individual contributor’ can be substituted for “subordinates.” Steve Blank’s customer development advice about ‘getting out of the building’ is analogous to the phrase “interaction with the external world.”

In preferred NPD environments, schwerpunkt should not be about herding cats. The predominant metrics should not highlight process metrics. It should recognize individual contributors as knowledge workers and value contributors.

Closing Thoughts

Instead of focusing your efforts on herding cats or gaming the cat-herding-system, I advocate investing to develop better implicit orientations. This enables the development of a compulsion loop that can become a vital driver to sustain a vibrant new product development environment. A byproduct of this approach is a series of great products that are associated with great user experiences.

What is the schwerpunkt of your development environment?

Endnotes

This post included extracts from the book “Developing Winners: Assimilating the Insights Encapsulated in Boyd’s OODA Loop” by OpLaunch founder, Mark A Hart.

An Alternative to Herding Cats

An Alternative to Herding Cats in New Product Development [ 9:58 ] Play Now | Play in Popup | Download

How to Absorb Changing Requirements in New Product Development

Posted on August 6, 2013 by OpLaunch

This post explores several approaches to prepare for absorbing changing requirements in product development projects. This post was inspired by Alistair Cockburn’s recent remarks.

Project Requirements

Many development projects have formal requirements. Most often these are found in projects that follow a waterfall methodology or those that embrace the Big Design Up Front (BDUF) approach. Typically, these types of projects contain requirements that include features that must be in the final product and constraints related to the schedule and budget. Sometimes the requirements change significantly as the project progresses. The changes may be frustrating to the development team.

Alistair Cockburn (@TotherAlistair) declared that he does not ‘welcome changing requirements.’ He sets up projects to absorb changes in requirements in the best possible way.

Cockburn made these comments on 2 July 2013 (VIDEO: the ‘set up to absorb’ comments are at at 38:30). The phrase ‘welcome changing requirements’ refers to one of the Principles behind the Agile Manifesto

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

To understand the context of his remarks, let’s review a few items from 2001.

Recollections from the meeting that produced the Agile Manifesto

Cockburn (pronounced Co-burn, the Scottish way ) was one of the 17 signatories of the Agile Manifesto in 2001. This meeting was not to develop something new. It served to summarize similarities in the approaches that had been used by the attendees for several years.

He recalled that the manifesto was crafted in one day. There was complete agreement over the wording. This includes the familiar phrases:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Work began on the Twelve Principles behind the Agile Manifesto the next day. His recollection is that there was not complete agreement on all of the wording for the principles.

During the one hour Q&A 2 July 2013 session, Cockburn playfully emphasized the word ‘welcome.’ It seems that Cockburn may not have been in complete agreement with the choice of the word ‘welcome’ in the ‘welcome changing requirements’ principle.

The Mindset Regarding Changes

Cockburn has been involved with enough development efforts to know that requirements change during projects.

Some changes occur because of incomplete research or misunderstandings. Some errors may be perpetuated in the documentation. Mismatches may be revealed because conditions in the marketplace have changed since the requirements were gathered.

Projects can be designed to respond to changing requirements. Cockburn has adopted an active approach to absorb changes.

When Cockburn spoke of ‘absorbing changes’ he was not suggesting something analogous to a sponge absorbing water. The better analogy is a shock absorber on a vehicle. It is a device designed to smooth the driving experience for the passengers. It improves comfort and safety.

Several Ways to Set Up a Project to Absorb Changes

There are many ways to prepare projects to absorb changes. In this post, I will summarize a few approaches that Cockburn has employed.

Information Radiators

When the team has access to relevant, emerging information, they are more likely to be able to absorb changes. One way to share emerging information is with an information radiator. Cockburn coined the phrase “information radiator” in approximately the year 2000. According to Cockburn, an information radiator needs to be large (easily seen), easy to understand, public, and changing. Information radiators promote interaction. Current development information, including problems, should be visible to everyone on the team so that specific problems are perceptible to the individual that may have the solution.

Often, information radiators are positioned on the team room wall or some other conspicuous place. An information radiator facilitates distributed cognition.

The opposite of an information radiator is an information closet. Cockburn cautioned against the tendency to store necessary information online and assume that team members are interacting with it.

Capture educational information from interactive sessions in rich formats

To efficiently and effectively facilitate information transfer to new or less experienced members of the team, Cockburn advocates a one-to-one interaction format that is recorded. For example, the expert on a specific item can meet with a new team member to explain specific items. A white board or flip chart can be used to visually capture some of the information. The session should be interactive with questions and answers. The session must be recorded so that when the next new team member needs to learn about this item, they can start by reviewing the recording.

Instead of an emphasis on formal documents or presentations, this approach relies on the interaction that results from dialog.

Overall, this interactive approach emphasizes the pursuit of activities that maximize the production of value and minimize the time spent on project artifacts.

Ensure that the team includes Ri-level practitioners

To maximize the potential to respond appropriately to changes in requirements, Cockburn advocates that development teams include Ri-level practitioners.

Cockburn uses the concept of Shuhari to characterize the stages of learning to mastery. For a particular set of skills, an individual can be classified in one of three levels:

Shu-level: An individual has learned a technique but is not aware of the limitations. They look for broad level clues.
Ha-level: An individual has collected multiple techniques but may not know why they are appropriate for every context.
Ri-level individuals invent and blend techniques. They insist on contextual clues before providing recommendations.

An individual can be a Ri-level practitioner in a narrowly defined area such as a particular programming language or in the broader context of product development. Having a critical mass of Ri-level individuals as part of the team improves the potential for selecting the appropriate options based on the specifics of the project.

In addition, individuals that have the insights to craft experiments and the skills to produce rapid prototypes are more likely to distinguish unvalidated inputs from validated inputs. They are more likely to distinguish opinions that may be unsubstantiated from refined information that can shape project requirements.

A Series of Cooperative Games

A cooperative team is equipped to handle changes better than a team that promotes non-cooperative functional areas (also known as silos). Cockburn envisions development as a cooperative game.

“I would like you to consider software development as a cooperative, finite, goal-seeking, group game. The goal is to produce a working system. The group, or team, consists of the sponsor, manager, requirements or usage specialists, software designers, testers, and writers. Usually the goal is to produce the system as quickly as possible, but there are other factors that affect the time goal: ease of use, cost, defect freedom, and liability protection. In general, it is a resource-limited game, which affects how the moves are made”

A cooperative game approach is consistent with a harmonious team effort toward a common goal. Within a cooperative game paradigm, changes to requirements are more likely to be viewed as a correction to achieve the common goal rather than a struggle to promote a particular perspective.

Development Experience

A team that has the benefit of items such as appropriate information radiators, efficient and effective training, an abundance of expertise that enables a variety of approaches to solve problems, and, a cooperative game approach is likely to thrive when presented with changes to project requirements. A team that has prepared for changes is more likely to thrive.

Cockburn advises teams to improve agility and adaptability. An environment that promotes the qualities of agility and adaptability is more likely to adjust to changes in requirements.
This type of team is more likely to enjoy better development experiences.

How to Absorb Changing Requirements This podcast is available on iTunes. Search for Development Experience.

How to Absorb Changing Requirements in New Product Development [ 10:58 ] Play Now | Play in Popup | Download

Reductionism and Recursion in New Product Development

Posted on May 31, 2013 by OpLaunch

Which approach to new product development will produce better results? Reductionism or Recursion?

Reductionism

According to Wikipedia:

“Reductionism is a philosophical position which holds that a complex system is nothing but the sum of its parts, and that an account of it can be reduced to accounts of individual constituents.”

In new product development, reductionism is rationalized as breaking development tasks into manageable pieces. Typical artifacts are seen in organizational charts or the roles assigned to individuals. For example:

Coders or Testers
Designers or Developers
Marketers or Sales
Project Managers or Product Managers
Front End of Innovation or Development

One of the potential advantages of reductionism is that it may provide focus to specialty efforts. Another potential advantage is that is may facilitate the interchangeability of resources (for example, one tester can be replaced by another tester with the equivalent qualifications).

Potential disadvantages of reductionism approaches include:

Degrades communication across functional groups
Acceptance of a hand-off mentality. This occurs when one functional area ‘finishes their job’ and presents their deliverables to the next group.
Increases the amount of explicit documentation
Sub-optimization. Too much effort may be devoted to certain tasks while others items do not receive sufficient attention.
Too much emphasis attributed to reaching milestones. Not enough emphasis on value creation.

Recursion

Recursion involves solving problems of the same form. In new product development, typical primary problems include:

Solving a customer’s problem. This is also described as providing a solution for the job the customer is trying to accomplish.
Increasing the organization’s revenue and/or profits
Positioning the organization for success in the future
Increasing the motivation of the development network. Dan Pink described this using the qualities of autonomy, mastery, and purpose. I describe this as improving the Development Experience [DX]

Recursion in the Development Network

For a recursion approach to flourish, an individual relates their short-term efforts (such as hourly, daily, or weekly efforts) to solve one or more of the primary problems listed in the previous section. For example:

Are their current efforts improving the ability of a customer to solve their problem? Has the learning increased so that individual contributors can determine if they are closer to solving the customer’s problem today than they were yesterday?
Are these efforts valuable to the customer? Are these efforts too bureaucratic?
Will the development efforts for the next project produce better results than the current project? Are the development capabilities being enhanced for future projects?
Will the contributors to the development network feel a sense of accomplishment? Will the predominant feelings relate to burn-out and frustration?

An environment that enables recursion to flourish ensures that individuals embrace opportunities to contribute to value creation during the current project and future projects.

Alistair Cockburn described this type of approach as a series of cooperative games. He stated:

“Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.”

Clinton Keith described it this way:

“For a cross-discipline team that is measured by value added to a working game, the role of an artist shifts to that of a ‘game developer’ who specializes in art. An artist doesn’t simply create an asset for someone else to put in the game and make fun. The artist participates in the creation of an experience, where art has an equal value. By having a voice in the discussion about what is being created, the artist elevates the value of what they create and minimizes the cost of creating it.”

From the book “Agile Game Development with Scrum” by Clinton Keith (@ClintonKeith) page 227. Published in 2010.

Contrasting Recursion and Iteration

Iteration is repeating. Often, it involves executing the same process with new items from a long list of potential tasks.

In Scrum, Sprint is the term for an iteration. In Scrum, the duration of a typical Sprint is in the range of one to four weeks. During a Sprint, development is devoted to completing selected items from a backlog of items.

Common metrics for a series of Sprints may highlight factors related to the speed of execution. This may include items such as burn-down rate.

One of the potential problems with an iteration mindset is that the number of product features that are completed is associated with a proxy for the value produced by the project.

Which is Better?

Which approach provides better value from a project? Is it a reductionist approach or a recursion approach?

A tyrannical approach does not produce better project value. Debating over a development question that includes the word ‘or’ is not likely to improve qualities such as autonomy, mastery, and purpose.

Better value will be produced with the proper combination of reductionism and recursion. Some individuals excel as reductionists. However, the potential for project success can not be achieved when the reductionist viewpoint is the only viewpoint that is tolerated.

Maximizing the potential for project success requires that one or more of the primary problems is being solved. Solving these primary problems is best accomplished with the inclusion of a recursion approach. This requires more than assigning someone to a role such as Product Owner.

I have found that that potential to maximize success in new product development improves when there is a critical mass of individual contributors that embrace a recursive approach to development. This diversity in the development network improves the potential for harmonious plans, decisions, and actions throughout development. It improves the potential for the self-correcting analysis of feedback.

Vision and Version

The interplay of vision and version in new product development

The interplay of reductionism and recursion is similar to the interplay of vision and version in new product development. These approaches facilitate implicit coordination within a diverse group of individual contributors throughout development that will produce better outcomes than alternatives that enforce handoffs and explicit coordination during development.

With a synergistic approach, the customer’s problem is more likely to be solved. The Development Experience [DX] of the individual contributors is more likely to improve from one project to the next.

Reductionism and Recursion in New Product Development (10 Minutes, 15.5 MBytes)

Reductionism and Recursion in New Product Development [ 9:52 ] Play Now | Play in Popup | Download

Introduction to Development Experience (DX)

Posted on March 13, 2013 by OpLaunch

How does one enhance the capabilities of the individuals within the networks that develop new products? Some approach new product development (NPD) with their favorite processes and precedents (which are typically called ‘best practices’). Some tend to insist that individuals follow explicit procedures.

Another approach is to design Development Experiences (DX) to produce better outcomes. This places the focus on the contributors. Can better new products develop from this approach?

Individuals with enhanced capabilities in a new product development network are indicated by the difference in color and size. The white-colored field that surround these two individuals indicates better interactions between these contributors.

Development Experience (DX) Definitions

Development Experience (DX) is the set of perceptions and responses from a diverse set of individuals that develop a new product, system, or service. DX includes emotions, beliefs, preferences, perceptions, physical and psychological responses, behavior and accomplishments that occur before, during, and after development. Factors that influence DX include the system, the individuals, and the context of development. DX varies over the time from concept to commercialization.

Well-crafted DX capitalizes on the mixed nature of diverse disciplines entering and exiting the development effort.

DX strives to capitalize on the mixed nature of groups contributing to development and their approaches (such as Stage-Gate©, waterfall, agile, Kanban, and lean).

Efforts related to Development Experience (DX) are distinct from efforts that focus on the product or the intended user of the product.

DX affects individuals that develop new products
UX affects individuals that use the product

A portion of this definition is based on the ISO 9241-210 definition of User Experience, UX.

Development Experience Design is the design of the experiences of a diverse set of individual contributors during the development of new products. It includes factors related to the development environment such as those that impact cooperation, collaboration, cohesiveness, and harmony of anyone associated with the new product development network at any time during development. It addresses experiences related to the development of items such as the hardware, software, interfaces, purchase, installation, setup, operation, and maintenance of the new product. It spans the time from concept to commercialization.

WHO: A designer shaping the experiences of individual contributors from many disciplines. Some individual contributors are full-time-equivalents (FTEs). Some contributors participate part-time. Some contributors are involved with the project for a short time (such as a few hours or a few days).

A DX influencer is a person that has a big impact on DX because of their intrinsic approach to development.

WHAT: Designing for a better experience for participation in NPD efforts by addressing factors such as cooperation, coordination, and collaboration.

WHEN: Throughout development, concept to cash

WHERE: DX impacts individuals at multiple sites. Some individuals at a central location. Others near the central location. Others are remote.

WHY: Better outcomes, happier individual contributors, and less grief

HOW: A DX designer enhances the capabilities of individuals by providing better orientations, pathways to proficiency, and strategies to win. More than processes, tools, patterns, and templates Beyond individuals that are thought of as interchangeable resources.

A Development Experience Designer is an individual that strives to impact the perceptions and responses of a diverse set of contributors during the development of new products. A DX Designer strives to enhance the new product development capabilities of individual contributors. A DX Designer explores factors related to the development environment such as those that impact cooperation, collaboration, cohesiveness, and harmony of anyone associated with the new product development network at any time during development.

More Information

More information about Development Experience (DX) is included in the OpLaunch website.

End notes

These DX-phrases were coined by Mark A Hart in March 2013.

Parse error: syntax error, unexpected '<' in /data/59/2/21/148/2999800/user/3329880/htdocs/blog/wp-content/themes/twentyeleven/footer.php on line 18