N R Malotaux

1
Evolutionary delivery

• Ir. Niels Malotaux

tel [phone] e-mail niels_at_malotaux.nl internet
www.malotaux.nl/nrm
2
Niels Malotaux

• Electronics 1974
• Development of computers, embedded systems and
  software
• Since 1998 Quality On Time consultant
• Optimising outsourcing
• Optimising way of working RD organisation
• Optimising way of working software organisation
• Current activities training coaching
• Evolutionary Project organisation (Evo)
• Requirements generation
• Reviews en Inspections

3
Immediately OK?

• Is everything you are doing 100 OK?
• Why not?
• What can you do about it?

4
Agreed time

• Is everything you are doing done on time?
• Why not?
• What can you do about it?

5
Problems with development

• It takes too much time
• It is not immediately right
• It costs too much

6
Goal

• The right product
• The right quality
• Within the time and budget agreed
• Pleasantly for everyone involved

Quality On Time
7
When is the product ready?
8
What should exactly be ready by then?
9
Dependencies
10
Time box or feature box
featurebox
timebox
time to market
11
Priorities

• Better 80 100 done,than 100 80 done
• It should be the most important 80

12
The requirements paradox

• Requirements must be stable
• Requirements always change
• Use a process that can cope with the
  requirements paradox

13
The 2nd requirements paradox

• We dont want requirements to change
• Because requirements change is a known riskWe
  try to provoke requirements change as early as
  possible

14
Product constraints

• Purpose of the product
• Reason for building the product
• Customer, User and other Stakeholders
• People with interest in the product
• Constraints
• Limitations, restrictions
• Cultural, ethical, political
• Legal
• Relevant facts
• Assumptions

15
Functional requirements

• Sope of the product
• Product boundaries
• Connections to adjacent systems
• Functional requirements
• Things the product must do
• Data requirements
• Data manipulated by the functions

16
Non-functional requirements

• Look and feel
• Usability
• Performance
• How fast, big, accurate, safe, reliable,
• Operational
• Operating environment
• Maintainability and portability
• Security

17
Non-functional requirements

• Description (e.g. deliciousness of our cakes)
• Scale ( people liking it) (number of cakes sold
  per week)
• Meter (weekly sold)
• Benchmarks
• Past (200 dec2000)
• Record (700 competition around the corner,
  dec2000 ? market survey)
• Requirements
• Must (500 march2001)
• Wish (1500 2003 ? CEO, New Year speech)
• Plan (800 march2001)

18
The waterfall model
19
The V development model
requirements
system test
Testspecs
integration test
architecture
unit test
design
code
20
Waterfall problems

• If we are late, the customer has no choice
• It doesnt work
• Big bang delivery causes debug mode

start date
fatal end date 80 done no product
21
(No Transcript)
22
Development cycles
23
Evo complete waterfall each week
24
Inseparable activities

• Estimation
• Planning
• Tracking

25
How much can you do in 5 days?

• Estimation
• Effort
• Leadtime
• How many hours are there in a week?

26
Apples and oranges

• Estimation of effort
• Estimation of effort/leadtime ratio

27
How are we going to work

• Short cycles 1 week (Thu Wed)
• Every week define
• What should we work on now (and why)
• In which order (priorities)
• To which level of detail for now
• Tasks are defined and estimated
• At the end of a cycle, every task is really done
• 1 week has about 26 effort hours
• At least once per two cycles, a completed,
  working product is delivered (CD!)

28
Structure of a cycle
29
Task selection criteria

• Most important requirements first
• Highest risks first
• Most educational or useful for development first
• Synchronise with other developments (e.g.
  hardware)
• Every cycle delivers a useful, completed,working,
  functional product

30
Priorities

• 5 Highest priority
• 4
• 3
• 2
• 1 Lowest priority
• 0 Forget about it now

31
Delivery selection criteria

• Every delivery must have symmetricalstakeholder
  values (features, qualities)
• Start program ?? exit program
• Load ?? save
• Add ?? delete
• Copy ?? paste (past needs clear destination)
• Every new delivery must have clear extras
• 1 increase in performance is not clearly visible
• 50 increase may be visible
• 90 is usually be visible and nice
• Every delivery delivers smallest clear increment
• If a delivery takes more than two weeks,it can
  usually be shortened
• Try harder

32
(No Transcript)
33
(No Transcript)
34
(No Transcript)
35
requirements
derivedtasks
newly defined tasks
changerequests
problemreports
database
CCB

• Reject
• Later
• Analysis task
• New task

Anything that must be done goes through
thecandidate task mechanism
36
How to start

• Take the requirements, architecture and design
• Make a list of things to do
• Split in tasks of 3 days max (use estimation)
• Put on Candidates List
• Define priorities
• CRs,PRs and NewTasks are also candidates
• Select ca. 26 hrs of tasks from top of the list
• Agree and commit to your work package (100
  done!!!)
• Use TaskSheets to avoid extra work
• Do the work
• Learn

37
How does testing fit in Evo?

• Final validation shouldnt find any problems
• Earlier verifications mirror quality level to
  developers how far from goal and what to learn

38
Evolutionary Delivery (Evo)

• Many very short development cycles (one week)
• Time boxed (not feature boxed)
• Solves the requirements paradox
• Most important requirements first
• Highest risks first
• Every cycle is a complete waterfall
• Every cycle delivers a useful, completed,working,
  functional product
• Customer has choice

39
Setting up Evo planning with team (1 day)

• Evo theory
• Product
• Product voor 5 nov
• Making subtasks
• Hours estimation
• Prioritising
• Goal for the day Defining the first cycle

40
Documents

• Wish spec
• Requirements
• Architecture - design
• Test spec
• Design log
• Code
• CRPR database
• Intranet shell?

41
Result of Evo

• Solid control of development projects
• Faster results
• Better quality
• Less stressed developers
• Happy customers
• More profits

Quality On Time
Internet www.malotaux.nl/nrm
42
Estimation form
43
If we allow 5 days for 3 days work