ODD: Extending Agile 1.3

Obstacle Driven Development
ODD Extending Agile

Obstacle Driven Development
28/06/2016 ©odd.enterprises 2

Testing First?
Answering a
question before
its asked is like
creating a
solution before
a test.

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

Agile Development
Agile is a development
method which is
efficient and adaptable.
• 12 principles guide
developers to
implement Agile
• Methods include
SCRUM and Feature
Driven Development

Extending Agile
ODD is different to Agile in a
number of ways.
• Full specification stage
implemented
• Tests created first
• Suitable for hardware, software
and embedded

Agile Manifesto
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
• 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 Principles
Principles are a reworking of the
Agile manifesto.
• Over substituted to illustrate how
both can support development
• Stages are adapted and models
created to facilitate aims
• Focus on linking obstacles and
tests to solutions and elements
• 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

Principle 1
Processes and tools which
encourage individuals and
interactions.
• Identifying and solving problems
is encouraged
• Individuals empowered to use
full ability of process and tools
• Interactions are simplified with
tests helping communication

Principle 2
Working software through
comprehensive documentation.
• Describing products and systems
helps create tests and solutions
• Working software designed
according to tests
• Comprehensive documentation
prevents basic errors

Principle 3
Contract negotiation through
customer collaboration.
• Specification helps meet
customer requirements
• Behaviours easy to describe and
understand
• Creating a specification is cheap,
testable and adaptable

Principle 4
Following a plan which responds to
change.
• Stages and elements are subject
to change as required
• No stages are frozen and
adaptable to requirements
• Failing tests can result in
modifying previous stages

Obstacle Driven Development 1
Tests to verify and validate code
adapted to create a new
development model.
• Applications to hardware,
software and embedded
• Links stages with tests for
verification and validation

Obstacle Driven Development finds
solutions to obstacles through four
stages of development.
• Analysis
• Specification
• Solution
• Production
Specification
Solution
Production
Analysis

Obstacles and solutions linked
through creating and solving tests.
• Obstacles help create tests to link
the next stage
• Elements are the solutions to
tests for a stage
• Elements become obstacles to
link next stage of development

Verification and validation links
stages with feedback and
feedforward methods.
• Verification is ensuring a product
is “built in the right way”
• Validation is ensuring a product is
“built right”
• Creating and solving tests give
verification and validation

Testing links adjacent stages
through creating and solving tests.
• Analysis
– Utilisation and elicitation
• Specification
– Verification and validation
• Solution
– Testing and design
• Production
– Quality assurance and control

Verification and Validation
Tests link stages of
development and
verify and validate.
• Stages given
appropriate
verification and
validation
• Obstacles become
tests to verify and
direct solutions

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

Fail Early, Fail Often
Achieve success through
identifying, correcting and
preventing failure.
• Undiscovered errors cost 10x
more to fix by next stage
• Errors become expensive to solve
• 2 stages missed ≈ 100x
• 3 stages missed ≈ 1000x

ODD Specification Importance
Specification help improve
development of a product.
• Product cost reduced with
specification process
• Detailed specification prevents
errors from propagating
• Creating and editing a
specification is low cost

SCRUM 1
SCRUM is a developmental method
for Agile developments.
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 helps 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 responsible for
ensuring a team works to values
and practices of Scrum.
• Process owner for team
• Ensures Scrum is understood and
followed
• Removes impediments to
progress

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

Burndown Chart 2
Simple burndown chart
where a blue line is an
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

Sprints
Sprints ensure a smooth
flow of work for duration
of development.
• Development work
divided into smaller
sprints
• Sprint has analysis,
planning, development
and testing stages
• Sprints required to be
integrated into projects

Tests as Sprints
Creating and solving tests measure
progress and ensure obstacles are
solved.
• Creating a test ensures an
obstacle becomes an objective
• Passing a test ensures an
obstacle is solved
• Measurable progress achieved
without unnecessary debugging

ODD Sprints
ODD Sprints select an obstacle to
create a test and solution.
• Measurable and testable
progress in a sprint
• Tests completed and remaining
give estimate of progress
• Tests completed are accurate
measure of progress

ODD Burndown Chart
ODD burndown replaces
tasks to be completed
with tests to be solved.
• Tests to solve is
estimate for time
remaining
• Difficulty of passing
tests helps estimate
time required
• Untested tasks may
result in errors
leading to overrun

ODD Flow Chart
Flow chart demonstrates generic
testing process for each stage.
• Flow chart adapted to give
testing required
• Select Obstacle refers to element
from previous stage
• Create Test and Create Solution
are adapted as necessary

Creating Tests 1
We create solutions similar to
Behaviour Driven Development.
• Tests created by rewriting a
behaviour and creating test
• Designing solutions according to
tests reduces debugging
• Testing and design continue until
behaviours are enabled

Creating Tests 2
Test suites created through
behaviours contained in a
specification.
• Creating tests first ensures an
objective is understood
• Design according to passing tests
reduces ambiguity
• Passing a test ensures behaviour
is enabled

ODD Organisation
Four or more stages structure a
developments organisation.
• Overview of stages and testing
• Stages observed and managed
• Colleague partnerships managed
and maintained
• Stages added as necessary e.g.
for hardware/embedded

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: Extending Agile 1.3

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ODD: Extending Agile 1.3

Similaire à ODD: Extending Agile 1.3 (20)

Plus de Jonathan Herring

Plus de Jonathan Herring (12)

Dernier

Dernier (20)

ODD: Extending Agile 1.3