Why Agile Development Is Bad Issues of complex Application Development ODTUG Kaleidoscope 2012 San Antonio, Texas, June Marc de Oliveira, Simplify Systems

Simplify Systems Methodology Modeling 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 AgileWaterfall ScopeSingle processHolistic architecture InvolvementReflect few key users Reflect the entire business QualityQuick decisionsThorough decisions Documentation Implicit documentation Explicit documentation Conclusion Hard for business to navigate Easy for 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

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 2 Agile 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

Agile Waterfall Agile Waterfall