Obstacle Driven Development
Extending Agile Development
©odd.enterprises
07/01/2015
Obstacle Driven Development
07/01/2015 ©odd.enterprises 2
ODD Process
07/01/2015 ©odd.enterprises 3
ODD Traffic Light Model
07/01/2015 ©odd.enterprises 4
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
07/01/2015 ©odd.enterprises 5
Waterfall Development
Waterfall development can be considered the traditional method of software development.
• Stages are fixed between stages and flexibility is an issue
• Each stage is “fixed” before moving to the next
• Testing is late in the development
07/01/2015 ©odd.enterprises 6
Agile Development
Agile is a more recent approach to product development which is designed to be efficient and adaptable.
• 12 principles used to guide development teams to implement Agile projects
• Implemented as various methodologies including SCRUM and Feature Driven Development
07/01/2015 ©odd.enterprises 7
Agile Manifesto
The Agile manifesto is used to describe 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.
07/01/2015 ©odd.enterprises 8
Fail Early, Fail Often
Achieving success when using ODD is through identifying, correcting and preventing failure.
• If an error is not discovered in a development phase it can cost 10x more to fix in the next
• Errors not identified can become very expensive to solve
• 2 stages missed ≈ 100x
• 3 stages missed ≈ 1000x07/01/2015 ©odd.enterprises 9
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.
07/01/2015 ©odd.enterprises 10
Learning from Failure
An ODD process is different from the traditional and is more concerned with preventing failure to achieve success.
• Failure is easy to prove and understand
• Using tests give definitive answers for success or failure
• Success when using ODD is the absence of failures
07/01/2015 ©odd.enterprises 11
The Test Is Out There
If you don’t test your product then your customers will.
• The tests are out there and waiting for your product
• Product utilisation of customers will have a wider scope than testing processes
• A single failure has the potential to cause failure of the product
07/01/2015 ©odd.enterprises 12
SCRUM 1
SCRUM is a developmental method of achieving Agile processes.
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
• Used to organise a team to achieve required result
07/01/2015 ©odd.enterprises 13
SCRUM 2
A SCRUM is used to plan and manage the sprints which facilitate development.
• Sprints can be between a week and a month (30 days shown)
• Each day a meeting to demonstrate progress and discuss problems is held
• Sprints allow consistent and sustained progress
07/01/2015 ©odd.enterprises 14
SCRUM Master
A Scrum Master is responsible for making sure a team works to the values and practices of Scrum.
• Facilitates Scrum events
• Process owner for team
• Ensures Scrum is understood and followed
• Removes impediments to progress
07/01/2015 ©odd.enterprises 15
Sprints
Sprints are used in order to ensure a smooth flow of work over the duration of a development.
• Projects are divided into smaller projects with separate development
• Each sprint has discovery, design, development and testing
• Each sprint is required to be integrated
07/01/2015 ©odd.enterprises 16
Burndown Chart 1
Burndown charts are used to measure and plan development.
• Green line is the ideal or expected development schedule
• Effort is measured using time
• Tasks completed or remaining measure progress
• If remaining tasks and effort are above the ideal then development is behind schedule
07/01/2015 ©odd.enterprises 17
Burndown Chart 2
A simpler burndown chart is shown where the blue line is the ideal or expected burndown.
• Using this chart it is simple to see if the project is expected to overrun
• If the actual tasks line is above the ideal tasks then the project is behind schedule
07/01/2015 ©odd.enterprises 18
Tests as Sprints
Sprints can be created from ODD by creating and passing tests for the various stages.
• Creating a test ensures the obstacle to be solved is known
• Passing a test ensures the obstacle is solved
• Measurable progress is achieved
07/01/2015 ©odd.enterprises 19
ODD M-model
The ODD M-model is used to demonstrate how a development process can be divided into stages and testing processes.
• Analysis
• Specification
• Solution
• Production
07/01/2015 ©odd.enterprises 20
ODD Process 1
The ODD process is centred around a traffic light model with each stage linked through creation and solution of tests.
• Describes the testing process and linkage of the previous stage
• Process uses unit tests to ensure all obstacles are solved
• Easy to understand and view progress
07/01/2015 ©odd.enterprises 21
ODD Process 2
The ODD process uses feedforward and feedback to ensure the stages are linked.
• Feedforward processes are creating tests to link next stage
• Feedback processes are solving obstacles and passing tests from previous stage
• Allows full linking of all stages
07/01/2015 ©odd.enterprises 22
Verification and Validation
Verification and validation is used in order to link the stages of development.
• Each stage is used to verify the next by creating tests
• Previous stage is used to validate by passing tests
• Each stage has been given an appropriate name for verification and validation
07/01/2015 ©odd.enterprises 23
ODD Traffic Light Model
Combining the ODD process and M-model gives the ODD Traffic Light model.
• Demonstrates how each stage is linked to the next through creating and passing tests
• Each traffic light set should model a unit testing process
• Linking of each stage is achieved when all green lights
07/01/2015 ©odd.enterprises 24
ODD Agile Manifesto
The manifesto used for ODD is a reworking of the Agile manifesto.
• Over is replaced with other terms to illustrate how a process can help with others
• Emphasis is on how processes can link and encourage Agile and 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
07/01/2015 ©odd.enterprises 25
ODD Organisation
Using the four stages gives good structure to the organisation of development.
• Overview of all stages and verification and validation
• Each stage and linking can be observed and managed
• Partnerships between colleagues on each stage can be managed and maintained
07/01/2015 ©odd.enterprises 26
ODD Master
An ODD master is given the title as similar to a SCRUM master.
• Suggested to have management control over development stages
• Interacts and supervises each and all of the stages
• Attention paid to linking the stages through verification and validation
07/01/2015 ©odd.enterprises 27
ODD Sprints
Creating a test and solution to pass are used to give ODD Sprints.
• Measurable and testable progress in the sprint
• Tests completed and remaining give an estimate of progress
• Tests completed are a more accurate way of measuring progress than jobs completed
07/01/2015 ©odd.enterprises 28
ODD Flow Chart
A flow chart has been designed to demonstrate an ODD process.
Problems or obstacles to be overcome are divided into 4 stages.
• Analysis
• Specification
• Solution
• Production
07/01/2015 ©odd.enterprises 29
ODD Analysis Flowchart
A flow chart has been designed to explain the creation of an ODD Analysis.
1. Product feature is selected
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until elicitation is complete
07/01/2015 ©odd.enterprises 30
ODD Specification Flowchart
A flow chart has been designed to explain the creation of an ODD Specification.
1. A requirement is selected which is to be covered by a behaviour
2. Verification test is created
3. Behaviour is specified
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
07/01/2015 ©odd.enterprises 31
ODD Solution Flowchart
A flow chart has been designed to explain the creation of an ODD Solution.
1. A behaviour is selected which has to be covered by a solution
2. Unit test is created
3. Solution is designed
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
07/01/2015 ©odd.enterprises 32
ODD Production Flowchart
A flow chart has been designed to explain the creation of an ODD Production.
1. A solution is selected which has to be produced
2. Quality assurance test created
3. Production process
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all production is assured
07/01/2015 ©odd.enterprises 33
ODD Burndown Chart
An ODD burndown chart simply replaces the tasks to be completed with tests to be passed.
• Tests to pass can be used as a reliable estimate for time remaining
• Tasks which are not tested may result in errors and mistakes leading to overrun
07/01/2015 ©odd.enterprises 34
ODD Process Flowchart 1
Combining the flowcharts gives a process which can be presented similarly to Waterfall development.
• Process begins with selecting a situation from the analysis which is used to specify behaviours
• Each ODD flowchart has been combined to produce flowchart for entire process
• More Agile flowcharts possible
07/01/2015 ©odd.enterprises 35
ODD Process Flowchart 2
07/01/2015 ©odd.enterprises 36
ODD Process Flowchart with Feedback
07/01/2015 ©odd.enterprises 37
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.
07/01/2015 ©odd.enterprises 38