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

1. Agile Is Not Fragile
Sunil Mundra
© ThoughtWorks 2008
Addressing Agile Myths and Criticisms

2. Agile Lacks Discipline
© ThoughtWorks 2008
Facts:
• CI, TDD, Refactoring, Stand Ups and other
Agile practices are based on discipline
• Interdependencies among Agile practices
promote as well as demand discipline
• Consistently delivering high quality, valuable
and working software at frequent and regular
intervals requires discipline
• Discipline is bottom up, not imposed

3. Agile Teams Do Not Plan
© ThoughtWorks 2008
Facts:
• Planning effort is spread throughout the entire
project duration and is not compressed at the
beginning
• Continuous planning helps to adapt to changes
• Teams learn from incremental planning, which
increases planning accuracy

4. Agile Development Does Not Scale
© ThoughtWorks 2008
Facts:
• Smaller teams proven to be more efficient and
effective than larger teams
• Agile promotes breaking large projects into
smaller ones, which results in early exposure of
risk and delivering business value
• Functional and technical compatibility of work
done by smaller teams is ensured through
Continuous Integration

5. Agile Development Is Not Predictable
© ThoughtWorks 2008
Facts:
• Traditional activity-based plans often offer
‘perception of predictability’
• Agile planning is feature-based, resulting in
higher adaptability to change
• Iterative planning based on historical data leads
to greater reliability of metrics for future plans
• Agile metrics are very visual, which facilitate re-
planning quickly, thereby increasing their
predictability

6. Pair Programming Is Effort Duplication
© ThoughtWorks 2008
Facts:
• Leads to defect prevention, resulting in saving
of costs involved in fixing defects subsequently
• Significantly decreases chances of slackness
• Ensures knowledge sharing, thereby eliminating
person dependency
• The benefits of pair programming, though
always not tangible, outweigh the marginal loss
of producctivity

7. Too Many Meetings At Customers’
Expense
© ThoughtWorks 2008
Facts:
• Meetings foster collaboration not only between
team but with customer as well
• Higher collaboration leads to early identification
of risks and bottlenecks, shorter feedback
cycles and better alignment with customer
expectations
• Time spent on meetings is transparent to
customers
• Meetings are focused and short

8. Iterative Development Causes Waste
© ThoughtWorks 2008
Facts:
• Reduces project risk as functionalities of higher
risk and complexity are developed early
• Eliminates mismatch between customer
expectations and the developed solution
• Gives customer the opportunity to modify
requirements, before the modifications become
too costly to incorporate
• Allows customer to derive business value early

9. Estimates Are Unitless
© ThoughtWorks 2008
Facts:
• Story Points are a composite reflection of size
and complexity
• Time based estimation at story level is
consciously 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 To
Relativity
© ThoughtWorks 2008
Facts:
• Humans better at comparative rather than
absolute measurements
• Easier to reach consensus
• Estimates, by definition, are not accurate
• Triangulation ensures consistency

11. Skewed Towards Coding Activity
© ThoughtWorks 2008
Facts:
• Coding is the biggest constraint to throughput
• Development time includes time towards
Quality Assurance and Continuous Integration
• Focus on delivering business value is
maintained as throughput is measured based
on completing user stories

12. TDD Is Unnecessary Extra Work
© ThoughtWorks 2008
Facts:
• Writing tests before coding makes design
robust
• Facilitates seamless integration of code
• Prevents propagation of errors, which are costly
to correct subsequently

13. Disregards Documentation
© ThoughtWorks 2008
Facts:
• Uses richer forms of communication and
collaboration
• Emphasis is on executable specifications rather
than bulky details
• Focus is on producing working software,
enabled by just enough and just in time
documentation

14. Unsuitable For Fix Bid Projects
© ThoughtWorks 2008
Facts:
• Issue is not methodology specific
• Customers generally unhappy due to:
• Project size larger than necessary as customers
contract for every requirement they can think of
• Solution provider charges risk premium to take
care of uncertainties
• Issue can be resolved through collaboration on
re-prioritization, and collaboration is core to
Agile philosophy

15. Loss Of Management Control
© ThoughtWorks 2008
Facts:
• Accountability is not lost, it is just moved from
individual level to team level
• Nature of management control changes from
command and direction to facilitation
• Comprehensive set of metrics can be used for
monitoring progress

16. Not Process Driven
© ThoughtWorks 2008
Facts:
• Recognizes that ‘one size fits all’ philosophy is
ineffective
• Believes in team empowerment, rather than
process enforcement
• Focus is on automation of repetitive processes

17. Agile Is A Silver Bullet
© ThoughtWorks 2008
Facts:
• Not a remedy for incompetence and poor
organization
• Choice of tools and practices is context
dependent
• Adaptable to requirement changes, but within
reasonable 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 and
development practices
• While Agile has guiding principles (manifesto), the
extent and nature of practices should be adopted based
on context
• Agile adopters have reported immediate and noticeable
improvements in managing requirements change,
stakeholder collaboration, accelerated delivery,
improved quality and project visibility

19. Questions?
© ThoughtWorks 2008

20. Thank You
© ThoughtWorks 2008