how to absorb changing requirements in new product development

1

How to Absorb Changing Requirements in New Product Development

Mark A Hart, NPDP

1

2

Objective

Prepare for absorbing changing requirements in product development projects

2

3

Project Requirements•Formal requirements•Waterfall / Big Design Up Front

(BDUF)•Changes may be frustrating to

the development team

3

4

Alistair CockburnDoes not 'welcome changing requirements.' He sets up projects to absorb changes in requirements in the best possible way.

4

@TotherAlistairvimeo.com/71485554

5

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

52001

6

Recollections from the meeting that produced the Agile ManifestoCockburn (pronounced Co-burn, the Scottish way ) was one of the 17 signatories of the Agile Manifesto in 2001

6

7

Recollections from the meeting that produced the Agile Manifesto•Meeting was not to develop something new

•Summarize similarities in approaches

7

8

Agile Manifesto

8

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

Crafted in one day with complete agreement over the wording

9

We follow these principles

9

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Not complete agreement over the wording

10

Welcome (?) changing requirements

10

2 July 2013

11

The Mindset Regarding Changes

•Incomplete research•Misunderstandings•Error propagation•Mismatches because of changing

market conditions

11

Requirements change during projects

12

An active approach to absorbing changes

•Not analogous to a sponge absorbing water

•Analogous to a shock absorber designed to smooth the driving experience for passengers

12

13

Several approaches to absorbing changes

•Information radiators•Alternative ways to capture

information•Ri-level practitioners•A series of cooperative games

13

14

Information Radiators•Large (easily seen)•Easy to understand•In conspicuous location•Up-to-date, changing

information

14

The opposite is an information closet

15

An alternative training approach

•Capture educational information from interactive sessions in rich formats

•One-to-one format with Q&A•Employ visual aides

15

This approach relies on the interaction that results from dialog

16

Pursue activities that maximize the production of value and minimize the time spent on project artifacts

16

17

Practitioners•Shu-level: Learned a technique but is

not aware of the limitations. Looks for broad level clues.

•Ha-level: Collected multiple techniques but may not know why they are appropriate for every context.

•Ri-level: Invent and blend techniques. Insist on contextual clues before providing recommendations.

17

18

Ri-level practitioners•Narrow or broad context•Craft experiments•Produce prototypes rapidly•Distinguishes unvalidated inputs

from validated inputs•Shape project requirements

18

19

Development as a cooperative game

•Cooperative, finite, goal-seeking, group game

•Team consists of individuals with many diverse roles

•System orientation•Resource-limited•Harmony

19

20

Changes to requirements are more likely to be viewed as a correction to achieve a common goal

20

21

Development Experience (DX)•Variety of approaches to solve

problems•Agility and adaptability•Likely to thrive

21

22

How to Absorb Changing Requirements in New Product Development

Mark A Hart

22

www.OpLaunch.com

Twitter: @OpLaunch

August 2013

Text