Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Myths and Misconceptions


Published on

12 Agile Myths and Misconceptions corrected. Presented at SofTech, the first software engineering conference of the PSIA.

Published in: Software, Technology, Business
  • Be the first to comment

Agile Myths and Misconceptions

  1. 1. Agile Myths and Misconceptions
  2. 2. Myth #1: Agile is a Methodology
  3. 3. Methodology - pretentious misused term for “process” - If situation X, do Y... - Do activity A, then B, then C... - Use template 1, diagram 2... - The output of M is the input of N... Methodologies: Scrum, XP, Kanban...
  4. 4. Agile is Principles & Values Agile Manifesto 12 Agile Principles 4 XP Values 7 Principles of Lean Software Development Agile reduces process, which must be replaced by values to work.
  5. 5. Agile is Principles & Values Customer Satisfaction, Customer Value Evidence-Based Decision-Making Technical Excellence Feedback, Visibility, Courage Eliminating Waste Human Interaction Etc...
  6. 6. Myth #2: Agile is Project Management
  7. 7. Agile Has Equal (or greater) Focus on Engineering Early Agile methodologies were heavy on engineering – Test-Driven Development, Coding Practices, Design Patterns, etc. Scrum originally focused on just project management, but lately is reemphasizing engineering
  8. 8. “There's a mess I've heard about with quite a few projects recently. It works out like this: “They want to use an agile process, and pick Scrum “They adopt the Scrum practices, and maybe even the principles “After a while progress is slow because the code base is a mess” - - Martin Fowler Agile Manifesto Signatory, ThoughtWorks Chief Scientist, Author
  9. 9. The Cost of Bad Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 20 25 30 35 40 45 Iteration Velocity
  10. 10. Team Capacity Team Capacity Requirements FeaturesDevelopment
  11. 11. Team Capacity Team Capacity Requirements FeaturesDevelopment Bugs Bug Fixing
  12. 12. Team Capacity Team Capacity Requirements FeaturesDevelopment Technical Debt Bugs Bug Fixing Technical Debt
  13. 13. Team Capacity Team Capacity Requirements FeaturesDevelopment Technical Debt Bugs Bug Fixing
  14. 14. Myth #3: Agile is Short Milestones
  15. 15. Waterfall with Many Short Milestones ● Iterations 1 – 4: Requirements Gathering ● Iterations 5 – 8: Design ● Iterations 9 – 16: Implementation ● Iterations 17 – 20: SIT/UAT ● Iterations 21 – 24: Production Support
  16. 16. Module Milestones (Multiple Short Waterfalls) Phase 1: Ordering Module Phase 2: Order Processing Module Phase 3: Billing Module Phase 4: User Management
  17. 17. Iterative Development It's not just about frequent deliveries
  18. 18. Software is Evolved
  19. 19. Software is Evolved Reach potentially-shippable state as quickly as possible. All succeeding deliveries should maintain to be potentially-shippable state.
  20. 20. Working software produced at each iteration Progress measured by working features ● No such thing as “X% complete”, only done and not done at the end of a sprint Done means tested, ready to deploy
  21. 21. Myth #4: Agile Cannot Work with Fixed Budgets
  22. 22. Fixed-Budget, Fixed-Scope Typical Scenario: 1. Project budget and detailed requirements are set in beginning. 2. Requirements are achieved, with plenty of overtime, and usually delays. 3. System is unusable because of mismatch to business needs and bugs. 4. Additional project phases needed to accommodate actual business needs and fix bugs. 5. Repeat X times. So what happened to the fixed budget?
  23. 23. In Agile... Budgets are fixed. – Based on team composition and duration. Business objectives are defined. – First to market? Win customers from competition? Reduce cost? Integrity of financial transactions? Reduce human error? Reduce process time? Scope is variable. Deliver something early that meets business needs. – Early ROI Base succeeding iterations on feedback. – Customer uptake, stakeholder feedback, etc. When project ends, organization is left with a valuable, useful product, within a fixed budget.
  24. 24. Myth #5: Agile is Unpredictable
  25. 25. Agile is Evidence-Based Decision-Making ● Requirements of future iterations based on user feedback from previous iterations. ● Schedules are based on experience from previous iterations. ● Architecture based on Spikes, not literature.
  26. 26. Waterfall Decision-Making is... ...Creative Writing
  27. 27. Myth #6: Agile Means No Upfront Design
  28. 28. Agile Design is Evidence-Based Architectures are based on Spikes – Subjected to tests (ex. performance) Enough detail for team to get started. – Design expected to evolve, collaboratively. Waterfall design is... yes, creative writing. – Designs are not validated by code. – Details not based on feedback.
  29. 29. Myth #7: Agile Means No Documentation
  30. 30. Agile Means Documentation that is Actually Read User Stories are in a form that is meaningful to all parties, expresses business objectives. Acceptance Tests removes ambiguity from requirements. Unit Tests describe the behavior of methods.
  31. 31. Traditional Requirements... Use Cases, etc, are devoid of business context. – Developers & stakeholders do not have basis to discuss better solutions that still meet business objectives. No automated way to validate if requirements and code are aligned.
  32. 32. Myth #8: Agile Will Prevent Problems
  33. 33. Agile will make problems visible, early and often. …so that they are easier to fix. – Expect to initially experience more problems, not less. Waterfall reveals problems only later, when they are hard to fix.
  34. 34. Myth #9: Agile Means No Managers
  35. 35. “Self-Organizing Teams” “There’s a reason we use the term 'self-organizing' rather than 'self-organized' or 'self-managed.' “That’s because it’s a process and a characteristic, not something that is done once and for all.” - Esther Derby
  36. 36. Self-Organizing Team: Mature, responsible, self-directed courageous people. – Aligned with company objectives – Solicits and provides feedback – Productivity visible to the organization – Works within financial and regulatory boundaries. To get there: Different people/teams need different management approaches. – Maturity, culture, motivation, discipline, awareness, etc.
  37. 37. Myth #10: Agile Means Weak Control
  38. 38. Traditional Control Status Reports – “We are 90% done.” • Based on what?
  39. 39. Agile Control Feedback Working Features Customer Satisfaction! Test Coverage Performance Tests Velocity / Burndown Charts Fine-grained commits, commit logs Continuous Integration Static Analysis – Cyclomatic Complexity – Coding Standards – Common Bugs – Technical Debt Web Analytics
  40. 40. Myth #11: Agile is Easy
  41. 41. Most companies think it will only take months to adopt Agile... … it usually takes years … because it is mainly a cultural shift. Painful mistakes will be made along the way. Organizational changes will need to be made, throughout the company. ● Performance Management process, Marketing involvement, Budgeting Cycles, etc.
  42. 42. Myth #12: You're Agile or You're Not Agile
  43. 43. Agile is a Continuum No such thing as a “perfectly Agile” team. ● Constraints – other departments, maturity of team members, clients, schedules, regulation, etc. ● Continuous improvement – always something that can be done better Be iterative in your Agile adoption. ● Take small steps that will achieve quick wins. ● What one value or practice can you adopt this week/month that will show visible gains?
  44. 44. Recommended Readings
  45. 45. Interested in learning more? Online Magazine: