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

ValidateSolution

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

ValidateSolution

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 verification and validation


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 control16/03/2015 ©odd.enterprises 16

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 verification and validation

• 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 verification and validation

• 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


CustomerUtilisation

Situation Analysis

ElicitCustomers

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

SpecifyBehaviour

Validate Specification

Requirement

ODD Specification Flowchart

Flow chart designed to explain 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

PassTest

Behaviour

ODD Solution Flowchart

Flow chart designed to explain creation of ODD Solution stage.

1. Behaviour selected to be covered by a solution

2. Unit test is created

3. Solution is designed


5. Repeat Stages 1 – 4 until all 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 ProductQuality

Solution

ODD Production Flowchart

Flow chart designed to explain creation of ODD Production stage.

1. Solution selected to be produced

2. Quality assurance test created

3. Production process


5. Repeat Stages 1 – 4 until all 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


http://odd.enterprises/

http://www.odd.enterprises/odd-presentations.html

https://www.facebook.com/odd.enterprises

https://twitter.com/odd_enterprises

mailto:[email protected]

Legal Stuff

ReferencesTest 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

DisclaimerThe 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.


http://agile.dzone.com/articles/digging-fail-fast-fail-often

http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-your-web-development-project

http://illustratedagile.com/2011/12/13/the-scrum-master-performance-review-preparation/

http://www.mountaingoatsoftware.com/agile/scrum/scrummaster

ODD is not Agile or Waterfall

Engineering

Transcript of ODD is not Agile or Waterfall