Agile Is Not Fragile


Published on

This deck attempts to address the common myths and misconceptions about Agile.

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Is Not Fragile

  1. 1. Agile Is Not FragileSunil Mundra© ThoughtWorks 2008Addressing Agile Myths and Criticisms
  2. 2. Agile Lacks Discipline© ThoughtWorks 2008Facts:• CI, TDD, Refactoring, Stand Ups and otherAgile practices are based on discipline• Interdependencies among Agile practicespromote as well as demand discipline• Consistently delivering high quality, valuableand working software at frequent and regularintervals requires discipline• Discipline is bottom up, not imposed
  3. 3. Agile Teams Do Not Plan© ThoughtWorks 2008Facts:• Planning effort is spread throughout the entireproject duration and is not compressed at thebeginning• Continuous planning helps to adapt to changes• Teams learn from incremental planning, whichincreases planning accuracy
  4. 4. Agile Development Does Not Scale© ThoughtWorks 2008Facts:• Smaller teams proven to be more efficient andeffective than larger teams• Agile promotes breaking large projects intosmaller ones, which results in early exposure ofrisk and delivering business value• Functional and technical compatibility of workdone by smaller teams is ensured throughContinuous Integration
  5. 5. Agile Development Is Not Predictable© ThoughtWorks 2008Facts:• Traditional activity-based plans often offer‘perception of predictability’• Agile planning is feature-based, resulting inhigher adaptability to change• Iterative planning based on historical data leadsto greater reliability of metrics for future plans• Agile metrics are very visual, which facilitate re-planning quickly, thereby increasing theirpredictability
  6. 6. Pair Programming Is Effort Duplication© ThoughtWorks 2008Facts:• Leads to defect prevention, resulting in savingof costs involved in fixing defects subsequently• Significantly decreases chances of slackness• Ensures knowledge sharing, thereby eliminatingperson dependency• The benefits of pair programming, thoughalways not tangible, outweigh the marginal lossof producctivity
  7. 7. Too Many Meetings At Customers’Expense© ThoughtWorks 2008Facts:• Meetings foster collaboration not only betweenteam but with customer as well• Higher collaboration leads to early identificationof risks and bottlenecks, shorter feedbackcycles and better alignment with customerexpectations• Time spent on meetings is transparent tocustomers• Meetings are focused and short
  8. 8. Iterative Development Causes Waste© ThoughtWorks 2008Facts:• Reduces project risk as functionalities of higherrisk and complexity are developed early• Eliminates mismatch between customerexpectations and the developed solution• Gives customer the opportunity to modifyrequirements, before the modifications becometoo costly to incorporate• Allows customer to derive business value early
  9. 9. Estimates Are Unitless© ThoughtWorks 2008Facts:• Story Points are a composite reflection of sizeand complexity• Time based estimation at story level isconsciously avoided,• To prevent over and under estimation• To recognize gains accruing from learning curve• To insulate from unknown external factors• To separate sizing from commitment
  10. 10. Estimates Are Inaccurate Due ToRelativity© ThoughtWorks 2008Facts:• Humans better at comparative rather thanabsolute measurements• Easier to reach consensus• Estimates, by definition, are not accurate• Triangulation ensures consistency
  11. 11. Skewed Towards Coding Activity© ThoughtWorks 2008Facts:• Coding is the biggest constraint to throughput• Development time includes time towardsQuality Assurance and Continuous Integration• Focus on delivering business value ismaintained as throughput is measured basedon completing user stories
  12. 12. TDD Is Unnecessary Extra Work© ThoughtWorks 2008Facts:• Writing tests before coding makes designrobust• Facilitates seamless integration of code• Prevents propagation of errors, which are costlyto correct subsequently
  13. 13. Disregards Documentation© ThoughtWorks 2008Facts:• Uses richer forms of communication andcollaboration• Emphasis is on executable specifications ratherthan bulky details• Focus is on producing working software,enabled by just enough and just in timedocumentation
  14. 14. Unsuitable For Fix Bid Projects© ThoughtWorks 2008Facts:• Issue is not methodology specific• Customers generally unhappy due to:• Project size larger than necessary as customerscontract for every requirement they can think of• Solution provider charges risk premium to takecare of uncertainties• Issue can be resolved through collaboration onre-prioritization, and collaboration is core toAgile philosophy
  15. 15. Loss Of Management Control© ThoughtWorks 2008Facts:• Accountability is not lost, it is just moved fromindividual level to team level• Nature of management control changes fromcommand and direction to facilitation• Comprehensive set of metrics can be used formonitoring progress
  16. 16. Not Process Driven© ThoughtWorks 2008Facts:• Recognizes that ‘one size fits all’ philosophy isineffective• Believes in team empowerment, rather thanprocess enforcement• Focus is on automation of repetitive processes
  17. 17. Agile Is A Silver Bullet© ThoughtWorks 2008Facts:• Not a remedy for incompetence and poororganization• Choice of tools and practices is contextdependent• Adaptable to requirement changes, but withinreasonable limits• Does not advocate short cuts to excellence
  18. 18. Conclusion© ThoughtWorks 2008• Agile is relatively new, resulting in ‘fear of unknown’• Agile combines the best of process, engineering anddevelopment practices• While Agile has guiding principles (manifesto), theextent and nature of practices should be adopted basedon context• Agile adopters have reported immediate and noticeableimprovements in managing requirements change,stakeholder collaboration, accelerated delivery,improved quality and project visibility
  19. 19. Questions?© ThoughtWorks 2008
  20. 20. Thank You© ThoughtWorks 2008