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

2. Simplify Systems Methodology Modeling Architecture

3. Agile: Cary Millsap

4. Waterfall: Marc de Oliveira Strategy Analysis Design Implementation

5. Don't Think – just do it Think – don't just do it “You have to break some eggs...”“Understand the business”

6. 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

7. 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

8. 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

9. 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)

10. 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

11. Discover Defects Early

12. 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

13. 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

14. Example (1) Application for educational organization Priority 1: Students and their courses

15. Example (2) Then: Personal information, address etc Then: Payments, grades, issue tracking

16. Example (3) Students may return and study more

17. Example (4) Then: HR management

18. Example (5) Many employees are former students  It would be nice to know that earlier...

19. Problem 3: Refacturing

20. Agile – without refacturing

21. Agile – with refacturing

22. So In The End - Who Wins? “Just Do It” or “Don't Just Do It”

23. 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

24. 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

25. 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

26. 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 ?

27. Conclusion 3 (2) Agile Waterfall Methodology Strategy Analysis Design Implementation

28. Agile Waterfall Marc@SimplifySys.com Agile Waterfall