Development Experience – OpLaunch » dx Mark A Hart, OpLaunch

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

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

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

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