Miyamoto Musashi (1584-1645) was a swordsman, a masterless samurai, and an independent teacher. He won his first duel at age 13. By the time he was 29, he had dueled more than 60 times. He never lost.

http://oplaunch.com/blog/wp-content/uploads/2015/01/a-better-perspective-on-competition-during-new-product-development.mp3

Subscribe on iTunes. Duration: 6 minutes. File Size: 3.5 MBytes

 

Rule 9 from “The Book of Five Rings” by Miyamoto Musashi is “Do not do anything useless.”

Musashi’s Rules

Musashi began to write “The Book of Five Rings” in 1643. In The Earth Scroll, he summarized his rules for “learning the art:

Think of what is right and true

Practice and cultivate the science

Become acquainted with the arts

Know the principles of the craft

Understand the harm and benefits of everything

Learn to see everything accurately

Become aware of what is not obvious

Be careful even in small matters

Do not do anything useless” [Page 22]

To expand #9, Musashi offered the following advice about combat:

“Whenever opponents try to attack you, let them go ahead and do anything that is useless, while preventing them from doing anything useful” [Musashi, The Book of Five Rings, The Fire Scroll, Page 54]

Opponents and Competition

In new product development contexts, it is more common to use the word competition than opponent.

In new product development, discussions about competition usually evoke thoughts of external struggles between organizations to complete projects and capture market share.

During new product development, competition also exists internally. Typically, internal competition discussions include topics such as negotiations about the schedule and project resources such as headcount and equipment budgets.

There are more subtle aspects of internal competition.

Internal Competition during New Product Development

During new product development, engaging skilled and experienced practitioners can address Musashi’s rules 1-4. Involving wise practitioners can address rules 5-8.

Rule 9 is more subtle. Familiar practices and past successes may make it difficult to detect what is useless.

Success in new product development depends on your ability to determine the relative usefulness or uselessness of all potential efforts.

For a simple exercise, consider your next scheduled meeting. A decision to have a meeting creates internal competition for attention. What might be done to improve the usefulness of the meeting? Will the agenda be available before the meeting? Is there a prominent objective? Are there new documents that must to be reviewed before the meeting? Will the completion of action items be verified? Will the duration of the meeting be less than one hour? Will meeting notes be created interactively during the meeting? Can remote contributors participate in the meeting? Can these needs be fulfilled more effectively by other means?

For a more complex exercise, consider how an individual contributor (a coder, engineer, scientist, communications specialist, subject matter expert,…) validates that their contributions provide value to the project. Besides completing a task (such as writing code to implement specific functionality), how will you determine if the effort was valuable? Was there a better use of the time? How will the effort be validated in terms of project success?

For a more substantial exercise, consider how an individual’s efforts contribute to improving their development experience factors such as autonomy, mastery, and purpose.

Developing a better perspective

Musashi’s advice was “Do not do anything useless.” This is a practical project objective and a desirable career strategy. Developing this perspective requires substantial effort and it produces significant rewards.

When efforts are not wasted on the useless, individuals can develop better perspectives to win as they evolve their focus and direction th[...]

Some emphasize that product development begins with writing code and that effort transforms into a win. The lingering question for this type of three-part development model is “What is Phase 2?”

Some emphasize that product development begins with writing code and that effort transforms into a win. The lingering question for this type of three-part development model is “What is Phase 2?”

What is Valued by Gnomes that Code?

Many managers track business metrics and project metrics during Phase 2 to forecast the potential to win.

What is valued by gnomes that code?

Gnomes associate winning with factors that include autonomy, mastery, and purpose. Dan Pink wrote about what motivates individuals in his book Drive.

Gnomes can develop autonomy, mastery, and purpose in an environment when there is a moderate amount of volatility, randomness, disorder, and stressors. Gnomes can benefit in a development environment that is characterized by a moderate amount of adventure, risk, and uncertainty. Taleb called this type of environment antifragile.

Development Options

Taleb wrote ‘The option is an agent of antifragility.’ An agent obtains results.

An appropriately designed network continuously synthesizes development options that provide the potential to take action that may result in a favorable gain. When an attractive gain may be realized, options are exercised.

Development options:

Include tasks that are likely to improve the antifragility of the network during a project

Are a response to the question ‘what should the network embrace now to improve the potential to win in the future?’

Are continuously synthesized and exercised during a project within the development network to refine the focus and direction of efforts to generate a win

Are consistent with the concept of safe-to-fail experiments that have an asymmetric payoff function (large potential gain, small potential loss)

Are exercised, evolve, or expire

The capabilities of the network impact the attractiveness of the development options that are generated.

To the extent that options are exercised and provide feedback, confidence in their attractiveness tends to increase.

Multiple options can be active simultaneously to provide multiple opportunities to win within the network’s current capabilities and within the project’s current constraints.

Precursors to Development Options

Analysis is a precursor of synthesis. Analysis is a problem solving approach that divides the whole into its constituent parts. Synthesis is a process of connection.

A synthesis approach enables one to imagine how several capabilities may work together to produce the desired result. Validation may follow from a combination of decision, action, interaction, and more observations.

John Boyd represented these items in his OODA Loop sketch in his final briefing titled “The Essence of Winning and Losing” in 1995. I have expanded Boyd’s notation to represent the interactions of individuals and their efforts during a project.

John Boyd’s OODA Loop sketch notation can be expanded to represent the interactions of individuals and their efforts during a project. This illustration includes the representation of simultaneous efforts within a hierarchy and the pursuit of two options simultaneously.

The following notation represents synthesizing options and exercising options throughout a development project.

Synthesizing many options and exercising attractive development options should occur rapidly throughout a project. ‘Synthesize options’ includes imagining solutions and documenting them. The cloud filled sky background of the ‘exercise option’ portion of this graphic represents the interaction of prototypes with the environment (which includes customers).

Designing to Improve the Capability to Synthesize and Exercise Attractive Development Options

Optionality can be improved by design. Concepts that can be employed in a development environment to help gnomes that code improve their capabil[...]

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 Ashb[...]

In this post, I will share ways to categorize new product development artifacts. I will clarify several memes. Then, I will offer a concept that individual contributors can use as they determine what they should be doing on a particular day.

Two Types of Artifacts in New Product Development

During new product development, many artifacts are produced. The word artifact is from the Latin phrase arte factum, skill + to make.

Typically, the product is a valuable project artifact. Other artifacts include items such as “design documents, data models, workflow diagrams, test matrices and plans, setup scripts, …” (from “What does artifact mean” on Stack Exchange).

In the context of new product development, deliverables are a subset of artifacts.

A product may be characterized as a set of external deliverables. Other items may be characterized as internal deliverables. Some of the internal deliverables may be maintained as documents. These are not the only artifacts.

In the context of new product development, deliverables are a subset of artifacts.

Other Artifacts in New Product Development

In addition to external deliverables and internal deliverables, artifacts include:

Items used to produce deliverables such as tools

Secondary items produced during development. These may be unintended items.

Items that are not incorporated into the current project but may be incorporated into future development efforts. This includes training.

Incomplete, unfinished, or abandoned items

Intangibles such as development strategies, tactics, and culture

These items are a subset of artifacts.

Why it is Difficult to Determine What is Important Today

Individual contributors ask “What should I be doing now?” and “Why?” There may be questions such as ’Should a specific artifact be created?’ and ‘How much effort should be expended creating it?’ Resolving priorities may be difficult because of situations such as:

The number of items that could be explored during a project may be greater than the network’s (1) development capacity.

Predictions about the future (including how much effort will be required to develop a particular item such as a user story or feature) are estimates about an emerging set of conditions.

Some items are not on the list of considerations. Because of a lack of experience and insight, these items are not known.

Some priorities may be specified explicitly. Some issues seem to require immediate resolutions. Some priorities evolve.

Interruptions impact flow (2). This includes flow within functional groups and flow between functional groups and the system.

There are dependencies. For example, a coder’s efforts may precede a technical writer’s efforts during development.

Perspectives Influence the Perception of Value

The value of any artifact is subject to the perspectives of the stakeholders. Coders tend to value working code. Some individuals may stress the importance of prototypes they created. Copywriters tend to value persuasive messages. Other individuals favor spreadsheets.

Even though the word artifact has noble origins, it may have positive or negative connotations. Sometimes, there is an implication that certain types of artifacts have less value than a product delivered to the customer. For example, the Agile Manifesto includes the phrase “working software over comprehensive documentation.”

Perceptions about the value of artifacts and the attention that they should receive are driven by factors that include:

The status quo. A bias to repeat what was done previously. Value is attributed to what was delivered previously.

The loudest voice. The person that has the most authority. HiPPO, which is an acronym for “Highest Paid Person’s Opinion”

Curated information that may of may not be validated

Expectations from estimates and milestones.

Feedback from well-crafted experiments

Sub-optimization

When a multitude of individuals with diverse specialties develop artifacts, there may be a te[...]

When the Beatles performed on the Ed Sullivan Show on 9 February 1964, there was noise from screaming fans. During this performance, John, Paul, George, and Ringo had difficulty hearing each other. However, they delivered a great performance. How did they coordinate their musical efforts?

Requisites to Coordination

The requisites to coordination in that noisy environment included:

Individually, John, Paul, George, and Ringo were proficient musicians. They invested years developing their musical abilities.

As a group, the Beatles practiced together for years. They performed under a diverse set of conditions. They had experience in ideal performance conditions and challenging performance conditions.

Musically, they knew what to expect. They pre-selected songs for the performance that they had mastered. The arrangements were designed for live performance by four musicians. These arrangements were familiar.

They did not rely on a technology that they could not control. They did not have a sophisticated audio monitoring system. They did not have headphones or in-ear personal audio monitors.

They did not rely on delayed feedback from others involved in the production.

In part, the quality of the musical performance required using information accumulated in the past to influence the future. This can be called a feed forward approach. A feed forward approach benefits from the involvement of proficient practitioners. In a feed forward approach, training precedes performance.

In other contexts, a feed forward approach may be characterized by a control signal that is transmitted from a source to a destination.

Prominent Signals and Subtle Signals

During the performances in 1964, the crowd noise was a prominent signal. During the performances, there were valuable subtle signals.

In a noisy environment, these subtle signals correlated with specific parts of each song. They included:

Discernible sounds such as the crash of a cymbal or the rumble from the bass drum

Facial expressions of the other musicians including mouth movements

Movements of fingers, arms, and feet of the other musicians

Interactions with the environment such as instantaneous interaction of the performance and reactions from the crowd

(Based on remarks by Paul McCartney in “The Beatles: The Night that Changed America. CBS 9 February 2014)

The subtle signals provided feedback during the performances. Feedback is an approach that uses information about current results to influence operation in the present. Feedback modifies a system based on interim results. Feedback changes the system output. This approach may be referred to as closed-loop feedback.

Subtle signals should be incorporated judiciously. Considerations include:

Valuable subtle signals may not be available when they would be the most useful.

Valuable subtle signals may be overlooked by novices.

An individual musician may not have the capacity to discern valuable subtle signals from the spurious subtle signals. Stated another way, an individual may not know that a subtle signal is valuable when they detect it.

The value of amplifying a particular signal by a specific amount is assessed by the nature of the results and the interaction with the environment.

Incorporating the appropriate subtle signals enabled the Beatles to be proficient performers in environments with nearly overwhelming undesirable noise.

Camera Operators Coordinated Their Efforts

It was so noisy in the Ed Sullivan Theater during the Beatles’ performances that the camera operators could not hear the instructions from the program director. The camera operators were proficient individually. They formed a cohesive team. They framed every shot without being able to hear the coordinating instructions from the director. The next week, a decision was made to replace the open-ear headphones with over-the-ear headphones.

(Based on remarks by the production crew in “The Beatles: The Night that Changed America. CBS 9 February 2014)

Mismatches

Mis[...]

The greatest value of producing interactive prototypes can be the impact on the network developing new products. In some development environments, this value may not be communicated as a primary objective.

Sequential Development Processes

Some textbooks summarize the steps to new product development (NPD) as a sequential process:

Select one idea from a large list of possibilities

Scope the project. Develop a plan that includes estimates to transition from an idea to a complete new product

Craft a business case or business model

Develop the product. These development activities are typically done by individuals in roles such as scientist, engineer, coder, tester, marketer, subject matter expert, project manager, product manager, …)

Test the product internally

Produce high fidelity prototypes

Place prototypes with potential customers for external test

Craft a marketing communications package

Launch the product to the intended market

A phased-gate approach to new product development is characterized by a sequential process used to manage projects

Often, this approach is administered by:

A formal management process such as a Stage-Gate® process

A resource management process that includes a list of requirements for specific project roles

Other explicit processes, checklists, procedures, and practices

Often, when Agile or Lean concepts are introduced, the impact is limited to the day-to-day activities of development.

Common Uses of Prototypes in New Product Development

There are many kinds of prototypes associated with a sequential product development process.

Some prototypes are produced quickly. They are used to evaluate a few design parameters. Typically, these prototypes are discipline specific. Artists sketch. Electrical engineers breadboard. Designers wireframe. Marketers test messages with focus groups. Typically, these prototypes are produced early in the development effort. Often, the process of designing and building these prototypes enhances the capabilities of the functional specialists that produce them. The raw data from testing these prototypes remains within a small group of like-minded specialists. In many cases, an interpretation of the test results is summarized in reports that are distributed to other specialists and managers.

Other prototypes are produced in limited quantities near the end of the development process. The construction of these high-fidelity prototypes requires the integration of components from multiple functional disciplines. Since the prototypes are constructed prior to the market launch, the potential for changing the product is minimized. Often, the major reasons for the production of high fidelity prototypes are:

Test the integration of components developed by separate groups of specialists

Gather testimonials for use in the market launch

Use for compliance testing (such as electrical safety, crash testing, drop testing,…)

Forecast production problems

Other names for these prototypes include alpha-units or beta units.

Typical Benefits of Interactive Prototypes

Prototypes can be static or interactive. Typically, interactive prototypes can provide insights that a static prototypes can not. For example, instead of a designer producing static sketches of web pages, the prototype could be designed and developed in HTML and CSS. Instead of asking someone to evaluate the aesthetics of sketches, evaluators interact with dynamic prototypes to perform tasks and solve simulated problems.

Dynamic prototypes have the potential to provide valuable feedback. Since the feedback loop from the evaluator to the designer is faster, the potential for misinterpretation of the evaluator’s comment by the designer is minimized. The potential to detect mismatches (what the designer believed that the customer wanted and what the customer needs) is maximized.

When evaluators interact with prototypes, deficiencies are revealed. Individual contributors are presented with an opportunity to fix[...]

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 [...]

This post explores feedback and feed forward approaches to improve development experiences in new product development (NPD).

This post was inspired by a new appreciation of the feedback and feed forward labels in John Boyd’s OODA loop sketch of 1995.

OODA Loop sketch that includes feedback, feed forward, and implicit guidance & control. Created by Mark A Hart. Based on a 1995 sketch by John Boyd.

A more common and older use of the phrases feedback and feed forward is from the design of control systems for mechanical and electrical devices.

To prepare for sharing these insights relating to new product development, I will review simplified electrical circuits that can be used to control the temperature in an electrical, tank-type appliance used to heat and store hot water.

Initial Design of a Water Heater

An initial system design includes a tank to store hot water. It includes a heater in an insulated tank. It includes a switch to activate the heater and a sensor to measure the water temperature. The water temperature is regulated by turning the heater switch on and off.

An initial design for an electrical, tank-type appliance used to heat and store hot water

A more sophisticated design would permit a user to input a set point for the desired water temperature. Ideally, the system would provide water at the set point temperature regardless of how much water was used for any task.

A Feedback Approach to Controlling Temperature

When a feedback approach is implemented, the temperature of the water exiting the tank is measured and that information is used to control the heater circuit.

A feedback approach to controlling the temperature of a water heater

This type of control is a feedback approach because the temperature sensor is after the circuit element producing the heat.

Feedback is an approach that uses information about current results to influence operation in the present. It includes modifications to a system based on results. Feedback produces a reactive response. This approach may be referred to as closed-loop feedback.

For this design, there is a characteristic lag (a delay after hot water is depleted before the heater is activated to raise the water temperature) and overshoot (a condition caused by exceeding the temperature set point because of a delay in deactivating the heater). An unsophisticated control circuit can not distinguish a scenario when a small amount of water is used or when a significant amount of water is used.

A Feed Forward Approach to Controlling Temperature

One implementation of a feed forward approach senses the amount of cold water entering the tank. The heater is turned on as a function of the amount of cold water entering the tank. This approach uses knowledge about the system to predict how much additional heat will be required. Such an approach is proactive.

A feed forward approach uses knowledge about the system to transmit a controlling signal from a source to a destination

Feed forward is an approach that uses knowledge about the system to transmit a controlling signal from a source to a destination. A feed forward approach is a rules-based approach.

Simultaneous Control Systems

A feed forward approach should be used with a feedback system. These are complementary approaches. The combination provides a system that is more responsive and more effective.

There are examples of analogous approaches in new product development.

Feedback Approaches in New Product Development

During new product development, it is common to present product prototypes to potential customers and gather feedback. Prototypes can take the form of surveys, A/B tests, and other interactions with hardware, software, and concepts.

This approach may be associated with other popular phrases such as ‘fail fast’ or ’safe to fail experiments’ where learning follows the development of a prototype. Another popular version of this type of approach includes the concept of a minimum viable product (MVP).

Feedback approach[...]

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 solut[...]

How do you get individuals involved in new product development to do more of the effective activity? There are many approaches. In this episode, I will explore several concepts from game development. I will describe how to develop the conditions for a core compulsion loop to drive positive Development Experiences (DX) in new product development.

Game Thinking and Game Mechanics

Often, playing a game is associated with the concept of fun. During game development, individuals are involved in tasks such as designing, coding, and composing, their deliverables. In addition, they strive to make playing the game fun.

According to John Earner of Space Ape Games, a great game has the following characteristics:

You are not forced to play the game. If you are forced to play, you are likely to resist.

In itself, playing the game may seem unproductive but it allows learning. A game probably has a purpose.

The outcome is uncertain.

You understand the rules

The game may be set in artful, virtual worlds. These worlds can capture an experience in a fictitious environment.

Games have easily understandable goals such as ‘save the Princess.’ Throughout a game, you may avoid obstacles, win tokens, and advance to the next level so that you are closer to saving the Princess.

It is not a surprise that some of these game characteristics have been applied in other contexts. The term for this is gamification. According to Wikipedia:

“Gamification is the use of game thinking and game mechanics in a non-game context in order to engage users and solve problems”

According to Stephanie Morgan, (@notSMorgan) “game mechanics are constructs of rules intended to produce a game. Common game mechanics include:

Scores and points accumulated through experimentation, interaction, and learning

Achievements such as badges and rewards

Avatars that provide a sense of identity”

Unfortunately, the concepts of gamification are frequently misinterpreted. One needs more than a tally of scores or a presentation of leader boards to maximize fun or interest or engagement. It requires more than dazzling graphics and carefully composed music.

Note: Some individuals may try to manipulate the system for a desired outcome. This is also known as “gaming the system” (http://en.wikipedia.org/wiki/Gaming_the_system) . This is different than gamification.

Core Compulsion Loops in Game Development

To understand what makes a game fun, some have explored a concept called the core compulsion loop. Some say that the proper development of a core compulsion loop is the essential ingredient for a successful game.

The word compulsion has definitions that range from:

The state of being forced

A difficult to resist urge to behave in a certain way

In the game context, the ‘difficult to resist urge’ conveys the desired intention for a core compulsion loop. A properly developed compulsion loop feeds the mechanics of the game.

A simple, primary compulsion loop is kill monsters, obtain rewards, buy items to kill more monsters.

A simple compulsion loop from a game

Secondary compulsion loops can be layered and fed into one primary compulsion loop. A secondary compulsion loop may have an element that may be characterized as instant gratification. The primary compulsion loop has a long-term impact. The primary compulsion loop may be characterized in terms of accomplishment.

A properly functioning primary compulsion loop is a virtuous circle that keeps players engaged.

Note: In this post, I am presenting compulsion loops from a positive perspective. Compulsion loops can designed to amplify destructive, additive behavior. I am not addressing those aspects in this post.

Common Gamification Approaches in New Product Development

Common approaches to new product development activities include:

Document explicit processes

Compliance enforcement. Establish milestones and demand accountability to deadlines.

Financial incentives related to salaries and bonuses of individual contributors

Ther[...]