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


http://odd.enterprises/

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

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

https://twitter.com/odd_enterprises

mailto:[email protected]

http://www.odd.enterprises/home.html

http://www.odd.enterprises/home.html



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

Engineering