odd is not agile or waterfall
TRANSCRIPT
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
16/03/2015 ©odd.enterprises 9
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
16/03/2015 ©odd.enterprises 10
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
Obstacle Driven Development 2
Obstacle Driven Development finds solutions to obstacles.
An obstacle is solved and product created through four stages of development.
• Analysis
• Specification
• Solution
• Production
16/03/2015 ©odd.enterprises 11
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
Obstacle Driven Development 3
An ODD Process is expressed using four stages in sequence.
The diagram is simplified to demonstrate a basic ODD process.
• Analysis
• Specification
• Solution
• Production
16/03/2015 ©odd.enterprises 12
Specification
Solution
Production
Analysis
Obstacle Driven Development 4
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
16/03/2015 ©odd.enterprises 13
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
16/03/2015 ©odd.enterprises 14
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
16/03/2015 ©odd.enterprises 15
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
16/03/2015 ©odd.enterprises 17
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
16/03/2015 ©odd.enterprises 18
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
16/03/2015 ©odd.enterprises 19
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
16/03/2015 ©odd.enterprises 20
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.
16/03/2015 ©odd.enterprises 21
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
16/03/2015 ©odd.enterprises 22
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.
16/03/2015 ©odd.enterprises 23
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
16/03/2015 ©odd.enterprises 24
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
16/03/2015 ©odd.enterprises 25
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
16/03/2015 ©odd.enterprises 26
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
16/03/2015 ©odd.enterprises 27
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
16/03/2015 ©odd.enterprises 28
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
16/03/2015 ©odd.enterprises 29
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
16/03/2015 ©odd.enterprises 30
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
16/03/2015 ©odd.enterprises 31
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
16/03/2015 ©odd.enterprises 32
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
16/03/2015 ©odd.enterprises 33
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
16/03/2015 ©odd.enterprises 34
ODD Elements 1
• Elements are generic and describe all parts of development
16/03/2015 ©odd.enterprises 35
• Elements of each stage are situations, behaviours, solutions and production
ODD Elements 2
• Elements are practical levels of a product and integrated or decomposed
16/03/2015 ©odd.enterprises 36
• 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
16/03/2015 ©odd.enterprises 37
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
16/03/2015 ©odd.enterprises 38
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
16/03/2015 ©odd.enterprises 39
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
16/03/2015 ©odd.enterprises 40
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
16/03/2015 ©odd.enterprises 41
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
16/03/2015 ©odd.enterprises 42
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
16/03/2015 ©odd.enterprises 43
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
16/03/2015 ©odd.enterprises 44
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
16/03/2015 ©odd.enterprises 45
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
16/03/2015 ©odd.enterprises 46
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
16/03/2015 ©odd.enterprises 47
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
16/03/2015 ©odd.enterprises 48
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
16/03/2015 ©odd.enterprises 49
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
16/03/2015 ©odd.enterprises 50
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
16/03/2015 ©odd.enterprises 51
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
16/03/2015 ©odd.enterprises 52
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
16/03/2015 ©odd.enterprises 53
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
16/03/2015 ©odd.enterprises 54
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
16/03/2015 ©odd.enterprises 55
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
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
16/03/2015 ©odd.enterprises 56
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
16/03/2015 ©odd.enterprises 57
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
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all behaviours are specified
16/03/2015 ©odd.enterprises 58
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
16/03/2015 ©odd.enterprises 59
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
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all production is assured
16/03/2015 ©odd.enterprises 60
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
16/03/2015 ©odd.enterprises 61
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
16/03/2015 ©odd.enterprises 63
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
16/03/2015 ©odd.enterprises 65
Further Information and Questions
• Website
• Presentations
16/03/2015 ©odd.enterprises 67
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.
16/03/2015 ©odd.enterprises 68