• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Is Not Fragile
 

Agile Is Not Fragile

on

  • 649 views

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

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

Statistics

Views

Total Views
649
Views on SlideShare
649
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Is Not Fragile Agile Is Not Fragile Presentation Transcript

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