The document discusses 12 common myths and misconceptions about agile practices. It summarizes that agile is based on principles and values rather than rigid methodologies. Additionally, it emphasizes that agile focuses equally on engineering practices as project management. Iterative development aims to evolve working software incrementally rather than view a project in isolated milestones. Budgets are fixed while scope is variable to allow for adapting to feedback. Problems are expected to surface earlier when using agile to allow for easier fixing compared to later discovery in waterfall approaches. Documentation and design are evidence-based rather than speculative upfront plans. Adopting agile is an ongoing cultural shift rather than a single change and continuous improvement is key.

1. Agile Myths and Misconceptions

2. Myth #1:
Agile is a Methodology

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. 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. Agile is Principles & Values
Customer Satisfaction, Customer Value
Evidence-Based Decision-Making
Technical Excellence
Feedback, Visibility, Courage
Eliminating Waste
Human Interaction
Etc...

6. Myth #2:
Agile is Project Management

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. “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. 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. Team Capacity
Team Capacity
Requirements FeaturesDevelopment

11. Team Capacity
Team Capacity
Requirements FeaturesDevelopment
Bugs Bug Fixing

12. Team Capacity
Team Capacity
Requirements FeaturesDevelopment
Technical Debt
Bugs Bug Fixing
Technical Debt

13. Team Capacity
Team Capacity
Requirements FeaturesDevelopment
Technical Debt
Bugs Bug Fixing

14. Myth #3:
Agile is Short Milestones

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. Module Milestones
(Multiple Short Waterfalls)
Phase 1: Ordering Module
Phase 2: Order Processing Module
Phase 3: Billing Module
Phase 4: User Management

17. Iterative Development
It's not just about frequent deliveries

18. Software is Evolved

19. Software is Evolved
Reach potentially-shippable state as quickly as possible.
All succeeding deliveries should maintain to be
potentially-shippable state.

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. Myth #4:
Agile Cannot Work with Fixed
Budgets

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. 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. Myth #5:
Agile is Unpredictable

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. Waterfall Decision-Making is...
...Creative Writing

27. Myth #6:
Agile Means
No Upfront Design

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. Myth #7:
Agile Means
No Documentation

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. 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. Myth #8:
Agile Will Prevent Problems

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. Myth #9:
Agile Means No Managers

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. 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. Myth #10:
Agile Means Weak Control

38. Traditional Control
Status Reports
– “We are 90% done.”
• Based on what?

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. Myth #11:
Agile is Easy

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. Myth #12:
You're Agile or
You're Not Agile

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. Recommended Readings

45. Interested in learning more?
facebook.com/orangeandbronze
Online Magazine:
orangeandbronze.com/orange-orchard
www.orangeandbronze.com