ODD is not Agile or Waterfall

Obstacle Driven Development
ODD is not Agile or Waterfall
©odd.enterprises
16/03/2015

Obstacle Driven Development
16/03/2015 ©odd.enterprises 2

ODD Circle Model

ODD Process

ODD Combined Model

ODD Process Flowchart

ODD Process Flowchart with Feedback

What is ODD? v. What do you want ODD to be?

Background
Ideas of Obstacle Driven Development (ODD) are based on
numerous development processes including:
• ISO V-model
• Test Driven Development
• ISO specifications
• Requirements analysis spiral
• Agile principles

Obstacle Driven Development 1
Tests used to verify and validate
code in TDD are extended and
adapted to create a new
development model.
• Applications to hardware,
software and embedded
• Links stages with tests used for
verification and validation
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

Obstacle Driven Development finds
solutions to obstacles.
An obstacle is solved and product
created through four stages of
development.
• Analysis
• Specification
• Solution
• Production
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

An ODD Process is expressed using
four stages in sequence.
The diagram is simplified to
demonstrate a basic ODD process.
• Analysis
• Specification
• Solution
• Production
Specification
Solution
Production
Analysis

Verification and validation are
applied to link stages and provide
feedback.
• Verification is ensuring a product
is built in the right way
• Validation is ensuring a product is
built right
• Creating and solving tests give

ODD Flow Chart
Flow chart to demonstrate a
generic ODD process implemented
with appropriate testing.
• Flow chart is adapted to give
testing required for each stage
• Select Obstacle refers to an
element from a previous stage
• Create Test and Create Solution
are adapted for verification and
validation of each element

ODD M-model 1
M-models demonstrate how
development is divided into stages
and testing processes.
Each stage also has a checkpoint.
• Requirements
• Documents
• Prototype
• Product

ODD M-model 2
Testing processes are to the left of
each stage.
• Analysis
– Utilisation and elicitation
• Specification
– Verification and validation
• Solution
– Testing and design
• Production
– Quality assurance and control

Waterfall Development
Waterfall development is
considered a traditional method of
software development.
• Each stage is “fixed” before
moving to the next
• Flexibility is an issue with fixed
stages
• Testing is late in the development

ODD is not Waterfall
ODD is different to Waterfall in a
number of ways.
• Development stages are not fixed
• Testing is implicit throughout
with unit tests
• Testing implemented between
each stage

Agile Development
Agile is a relatively recent approach
to product development designed
to be efficient and adaptable.
• 12 principles to guide
development teams in
implementing Agile projects
• Various methodologies including
SCRUM and Feature Driven
Development

ODD is not Agile
ODD is different to Agile in a
number of ways.
• Specification implemented
• Tests are created first
• ODD is suitable for hardware,
software and embedded
• Four stages to product
development

Agile Manifesto
The Agile manifesto describes what
is important for an Agile project.
• Invented by Kent Beck, James
Grenning et al.
• While both are important Agile
values the left over the right
• ODD uses a modified version
• Individuals and interactions over
processes and tools
• Working software over
comprehensive documentation
• Customer collaboration over
contract negotiation
• Responding to change over
following a plan
© Kent Beck, James Grenning et al.

ODD Manifesto
The manifesto used for ODD is a
reworking of the Agile manifesto.
• Over is replaced by terms
illustrating how one can help
with others
• Emphasis on linking and
encouraging ODD processes
• Processes and tools which
encourage individuals and
interactions
• Working software through
comprehensive documentation
• Contract negotiation through
customer collaboration
• Following a plan which responds
to change

Success from Failure
Obstacle Driven Development can
be described as an attempt to:
Achieve success by identifying,
correcting and preventing failures
as early, effectively and efficiently
as possible.

Learning from Failure
ODD is different to traditional and
achieves success by identifying,
correcting and preventing failures.
• Success is a lack of failure
• Failure is easy to prove and
understand
• Tests give definitive answers for
success or failure

The Tests Are Out There
If you don’t test your product then
your customers will.
• Tests are out there and waiting
for your product
• Product utilisation has wider
scope than testing
• Single failure has potential to
cause failure of a product

Fail Early, Fail Often
Achieving success with ODD is
through identifying, correcting and
preventing failure.
• Undiscovered errors can cost 10x
more to fix in the next
development phase
• Errors become expensive to solve
• 2 stages missed ≈ 100x
• 3 stages missed ≈ 1000x

ODD Specification Importance
A specification can improve
development of a product.
• Product cost is reduced with an
improved specification process
• Using a full specification can
prevent errors from propagating
• Creating and editing a
specification is low cost

SCRUM 1
SCRUM is a developmental method
for Agile developments.
SCRUM was first defined in 1986 as
• a flexible, holistic product
development strategy where a
development team works as a
unit to reach a common goal
• Teams organised to achieve
required result

SCRUM 2
SCRUM is used to plan and manage
sprints which facilitate
development.
• Sprints can be between a week
and a month (30 days shown)
• Meetings to demonstrate
progress and discuss problems
• Sprints allow consistent and
sustained progress

SCRUM Master
Scrum Master is responsible for
ensuring a team works to values
and practices of Scrum.
• Facilitates Scrum events
• Process owner for team
• Ensures Scrum is understood and
followed
• Removes impediments to
progress

Sprints
Sprints ensure a smooth flow of
work for the duration of a
development.
• Developments are divided into
sprints
• Each sprint has discovery, design,
development and testing
• Each sprint is required to be
integrated

Burndown Chart 1
Burndown charts help measure and
plan development through tasks
completed and remaining.
• Green line is expected
development schedule
• Effort is measured using time
• If remaining tasks and effort are
above ideal then development is
behind schedule

Burndown Chart 2
Simple burndown chart where the
blue line is an ideal or expected
burndown.
• Easy to see if a project is
expected to overrun
• If actual tasks line is above ideal
tasks then a project is behind
schedule

Tests as Sprints
ODD Sprints are creating, solving
and passing tests for various stages.
• Creating a test ensures an
obstacle to be solved is known
• Passing a test ensures an
obstacle is solved
• Measurable progress achieved

ODD Elements 1
• Elements are generic and
describe all parts of
development
• Elements of each stage are
situations, behaviours,
solutions and production

ODD Elements 2
• Elements are practical levels
of a product and integrated
or decomposed
• Elements are solutions of
tests generated by a previous
stage

Linking Elements 1
Elements ensure development links
throughout the stages.
• Each stage has different and
separate elements
• Height of elements indicates level
from material to product
• Unit testing links each stage

Linking Elements 2
Elements are used to create a test
and link elements in the next stage.
• Unit testing implemented
through traffic lights
• Levels should link to related
elements of next stage
• Short distance between stages
indicates a close link

Linking Elements 3
Production stage allows elements
to link up for continuous
development.
• Product analysis for identification
of remaining errors
• Informs future developments
• Solution is created many times
with quality assured and
controlled

Linking Tests 1
Tests link behaviours with solutions
through testing and design.
• Solutions are designed according
to tests created from behaviours
• Each solution is a single element
of a product
• Unit testing is applied
• Test suite created and ran when
changes occur

Linking Tests 2
Testing and design concerns
solutions created from behaviours
in a specification.
• Customers are involved for
utilisation and elicitation
• Each solution implements 1 or
more behaviours
• Tests suite ran for any changes or
additions

Creating Tests 1
Creation of solutions from a
specification is inspired by
Behaviour Driven Development.
• Often tests can be created by
simply rewriting a behaviour
• Designing a solution according to
tests reduces debugging
• Creation of tests and designs may
continue until all behaviours are
implemented

Creating Tests 2
Full test suite created using each
behaviour contained in a
specification.
• Creating a test first ensures an
objective is understood
• Design according to passing tests
reduces ambiguity
• Passing a test ensures behaviour
is implemented

ODD Process 1
ODD uses a traffic light model with
each stage linked through creating,
solving and passing tests.
• Demonstrates links to elements
from a previous stage
• Process uses unit tests to ensure
all obstacles are solved
• Easy to understand and view
progress

ODD Process 2
Feedforward and feedback
processes are used to ensure stages
are linked.
• Feedforward is creating tests to
link next stage
• Feedback is solving and passing
tests from previous stage
• Allows full linkage of stages

Verification and Validation
Testing processes are used for
verification and validation and to
link stages of development.
• Stages given appropriate
• Each stage used to verify next
through creating tests
• Previous stage used for validation
by solving and passing tests

ODD Combined Model
An ODD process and an M-model
give a combined model.
• Demonstrates how each stage is
linked to next
• Each traffic light set models a
unit testing process
• Linking of a stage is achieved
when all green lights

ODD Organisation
Four stages structure a
developments organisation.
• Overview of all stages and
• Each stage and linking is
observed and managed
• Partnerships between colleagues
are managed and maintained

ODD Master
An ODD master is given a title and
responsibilities similar to a SCRUM
master.
• Attention paid to linking stages
through verification and
validation
• Has management control over
development stages
• Interacts and supervises each
and all stages

ODD Sprints
ODD Sprints are creating, solving
and passing a test.
• Measurable and testable
progress in a sprint
• Tests completed and remaining
give estimate of progress
• Tests completed are an accurate
way of measuring progress

ODD Burndown Chart
An ODD burndown chart simply
replaces tasks to be completed with
tests to be passed.
• Tests to pass used as an estimate
for time remaining
• Tasks not tested may result in
errors leading to overrun

ODD Generic Flow Chart
Each stage of ODD has an adaption
of this generic flow chart.
Flow chart is adapted to provide:
• Analysis - Utilisation and
Elicitation
• Specification – Verification and
Validation
• Solution - Testing and Design
• Production – Quality Assurance
and Control

ODD Analysis
Utilisation and elicitation verify and
validate product features.
• Once product features are
utilised then elicitation can
proceed as validation
• Process links stages and allows
continuous improvement and
adaption
Customer
Utilisation
Situation
Analysis
Elicit
Customers
Feature

ODD Analysis Flowchart
Flow chart designed to explain
creation of ODD Analysis stage.
1. Product feature selected to be
analysed in situations
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until
elicitation is complete

ODD Specification
Specification describes behaviours
which cover expected situations
and requirements.
• Tests verify and validate whether
behaviours cover requirement
• Once expected situations are
covered and tests verified a
specification is complete
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

ODD Specification Flowchart
creation of ODD Specification stage.
1. Requirement selected to be
covered by a behaviour
2. Verification test is created
3. Behaviour is specified
5. Repeat Stages 1 – 4 until all
behaviours are specified

ODD Solution
Specification allows creation of
tests and solutions based on
described behaviours.
• Solution describes individual and
integrated designs
• If a solution is designed to pass
tests then testing becomes easier
• Unit testing and test suites used
Create Test
Design
Solution
Pass
Test
Behaviour

ODD Solution Flowchart
creation of ODD Solution stage.
1. Behaviour selected to be
covered by a solution
2. Unit test is created
3. Solution is designed
behaviours are specified

ODD Production
Production organised directly from
a solution to give assured and
controlled quality.
• Solution ensures continuous and
predictable quality
• Quality assurance tests are
created
• Number of passes a measure for
quality control
Assure
Product
Quality
Produce
Product
Control
Product
Quality
Solution

ODD Production Flowchart
creation of ODD Production stage.
1. Solution selected to be
produced
2. Quality assurance test created
3. Production process
production is assured

ODD Agile Flowchart 1
Combining flowcharts without
checkpoints gives a process similar
to Agile development.
• Begins by selecting a situation
from analysis to specify
behaviours
• Each ODD flowchart is combined
to produce flowchart for entire
process

ODD Agile Flowchart 2

ODD Waterfall Flowchart 1
Combining flowcharts gives a
process which can be presented
similarly to Waterfall development.
• Begins with selecting a feature to
process requirements
• Each ODD flowchart has been
combined with checkpoints

ODD Waterfall Flowchart 2

ODD Waterfall with Feedback 1
Full flowchart model of an ODD
development.
• Decisions added to give options
when tests are not passing
• Branch in lighter colour is a
repetition of analysis stage
• Indicates how development can
be continued or adapted

ODD Waterfall with Feedback 2

Further Information and Questions
• Website
• Presentations
• Facebook
• Twitter
• Email

Legal Stuff
References
Test Driven Development for Embedded C
James Grenning, 2011
Digging into “Fail fast, fail often.”
http://agile.dzone.com/articles/digging-fail-fast-fail-often
Agile vs. Waterfall: How to Approach your Web Development Project
http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-
your-web-development-project
The Scrum Master Performance Review
http://illustratedagile.com/2011/12/13/the-scrum-master-
performance-review-preparation/
ScrumMaster
http://www.mountaingoatsoftware.com/agile/scrum/scrummaster
Disclaimer
The ODD M-model and associated processes are provided by odd.enterprises and may be
used for any purpose whatsoever.
The names odd.enterprises and associated logos should not be used in any representation,
advertising, publicity or other manner whatsoever to endorse or promote any entity that
adopts or uses the model and/or associated processes.
odd.enterprises does not guarantee to provide support, consulting, training or assistance of
any kind with regards to the use of the model and/or processes including any updates.
You agree to indemnify odd.enterprises and its affiliates, officers, agents and employees
against any claim or demand including reasonable solicitors fees, related to your use,
reliance or adoption of the model and/or processes for any purpose whatsoever.
The model is provided by odd.enterprises “as is” and any express or implied warranties,
included but not limited to the implied warranties of merchantability and fitness for a
particular purpose are expressly disclaimed.
In no event shall odd.enterprises be liable for any damages whatsoever, including but not
limited to claims associated with the loss of data or profits, which may result from any
action in contract, negligence or other tortious claim that arises out of or in connection with
the use or performance of the model.

ODD is not Agile or Waterfall

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie ODD is not Agile or Waterfall

Ähnlich wie ODD is not Agile or Waterfall (20)

Mehr von Jonathan Herring

Mehr von Jonathan Herring (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

ODD is not Agile or Waterfall