how to absorb changing requirements in new product development
DESCRIPTION
The presentation explores several approaches to prepare for absorbing changing requirements in product development projects. This episode was inspired by Alistair Cockburn’s (@TotherAlistair) recent remarks. Enhanced podcast at https://itunes.apple.com/us/podcast/development-experience-oplaunch/id628299825TRANSCRIPT
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