Your SlideShare is downloading. ×
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Agile Is Not Fragile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Is Not Fragile

393

Published on

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

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
393
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Is Not FragileSunil Mundra© ThoughtWorks 2008Addressing Agile Myths and Criticisms
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions?© ThoughtWorks 2008
  • 20. Thank You© ThoughtWorks 2008

×