why agile development is bad issues of complex application development odtug kaleidoscope 2012 san...
TRANSCRIPT
Why Agile Development Is Bad
I
Waterfall
Issues of complex Application Development
ODTUG Kaleidoscope 2012San Antonio, Texas, June 24-28
Marc de Oliveira, Simplify Systems
SimplifSimplifyy SystemsSystems
MethodologyModeling
Architecture
Agile: Cary Millsap
Waterfall: Marc de Oliveira
Strategy
Analysis
Design
Implementation
Don't Think
– just do it
Think– don't just do
it“You have to break some eggs...” “Understand the business”
Discussion Points
3 Agile misconceptions about waterfall Agile evangelists use the term
“Waterfall” as a synonym for “Bad” which makes it hard to understand the real differences between Agile and Waterfall
3 Problematic Agile ideas Areas where Agile ideas are slow, more
costly or delivers lower quality than Waterfall
3 Conclusions
Misconception 1:Agile – the term
Agility is good It does not come from calling it Agile Development agility
Short code release cycles
Few programming constraints
Business Agility Fast reaction to business change
Having a consistent understanding of the business and how it is supported by software
Business Agility
Agile Waterfall
Scope Single process Holistic architecture
Involvement Reflect few key usersReflect the entire
business
Quality Quick decisions Thorough decisions
Documentation
Implicit documentation
Explicit documentation
ConclusionHard
for business to navigate
Easyfor business to
navigate
Misconception 2:Show Your Work to Other People
Cary Millsap (Agile): Release Early
Release Often
Marc de Oliveira (Waterfall): Get feedback on analysis
Get feedback on design
Get feedback on implementation
Showing Design Can cloud users' ability to focus on the
big picture (improving the business)
Misconception 3:Welcome Changing Requests
Cary Millsap (Agile Manifesto): Welcome changing requirements even
late in the development
Marc de Oliveira (Waterfall): Even if they conflict with other
requirements?
It does not make sense to spend time working on outdated requirements
Salmon jumps … but the earlier you identify a problem the
cheaper it is to fix it
Discover Defects Early
Analysis Design Implementation Test Post Release
1 3 510
100Cost to fix
Problem 1:How or What?
Both are important: How: The activities to be supported
What: Things of interest to the business
Cary prioritizes How over What To focus on one problem area at a time
Data can be changed later if it is wrong
Marc prioritizes What over How As Data is more stable and reusable than
Process
Activities are easier to change
Problem 2:The Product Owner
Agile methodology handles the issue of “understanding the business” by defining the role of a Product Owner
The Product Owner represents the collective requirements
understands the inter dependencies
knows how to prioritize requirements
Ie Scrum “outsources” the responsibility of having a consistent view of the business
Example (1)
Application for educational organization
Priority 1: Students and their courses
Example (2)
Then: Personal information, address etc
Then: Payments, grades, issue tracking
Example (3)
Students may return and study more
Example (4)
Then: HR management
Example (5)
Many employees are former students It would be nice to know that earlier...
Problem 3:Refacturing
Agile – without refacturing
Agile – with refacturing
So In The End - Who Wins?
“Just Do It”or
“Don't Just Do It”
Conclusion 1 (1)Understanding of the
Business Cary Millsap's methodology (Agile)
Start with the primary requirement
Discuss it with key users
Develop a prototype
Get acceptance
Repeat with next requirement
Conclusion 1 (2) Understanding of the
Business Marc de Oliveira's methodology
(Waterfall) Identify all the things of interest (terms)
… and their relationships Consolidate conflicting understandings
Understand all essential activities … based on consolidated terminology Consolidate conflicting understandings
Design and implement processes to support the business
Conclusion 2Agile is a Coding Methodology
Every Sprint must result in running code
“Working software is the primary measure of progress”, The Agile Manifesto
All requirement questions are deferred to the Product Owner
It is not part of Scrum methodology how the product owner establishes an understanding of the overall business requirements
Conclusion 3 (1)Understanding vs Speed
We have to understand the business
to build the right system
to discover defects early
Conclusion: use Waterfall
We want to deliver faster Conclusion: use Agile
Is there a compromise?
Conclusion 3 (2)Agile Waterfall Methodology
Strategy
Analysis
Design
Implementation
