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/id628299825

1. 1
How to Absorb
Changing
Requirements in New
Product Development
Mark A Hart, NPDP
1

2. 2
Objective
Prepare for absorbing changing
requirements in product
development projects
2

3. 3
Project Requirements
• Formal requirements
• Waterfall / Big Design Up Front
(BDUF)
• Changes may be frustrating to the
development team
3

4. 4
Alistair Cockburn
Does not 'welcome changing
requirements.'
He sets up projects to absorb
changes in requirements in the
best possible way.
4
@TotherAlistair
vimeo.com/71485554

5. 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. 6
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
6

7. 7
Recollections from the meeting
that produced the Agile Manifesto
• Meeting was not to develop
something new
• Summarize similarities in
approaches
7

8. 8
Agile Manifesto
8
Individuals and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Crafted in one day with complete agreement over the
wording

9. 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. 10
Welcome (?)
changing requirements
10
2 July 2013

11. 11
The Mindset Regarding Changes
• Incomplete research
• Misunderstandings
• Error propagation
• Mismatches because of changing market
conditions
11
Requirements change during projects

12. 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. 13
Several approaches to absorbing
changes
• Information radiators
• Alternative ways to capture information
• Ri-level practitioners
• A series of cooperative games
13

14. 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. 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. 16
Pursue activities that
maximize the production of
value and minimize the time
spent on project artifacts
16

17. 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. 18
Ri-level practitioners
• Narrow or broad context
• Craft experiments
• Produce prototypes rapidly
• Distinguishes unvalidated inputs from
validated inputs
• Shape project requirements
18

19. 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. 20
Changes to requirements are
more likely to be viewed as a
correction to achieve a common
goal
20

21. 21
Development Experience (DX)
• Variety of approaches to solve
problems
• Agility and adaptability
• Likely to thrive
21

22. 22
How to Absorb Changing
Requirements in New Product
Development
Mark A Hart
22
www.OpLaunch.com
Twitter: @OpLaunch
August 2013
Text