1. Mythical XP-
Dealing with XP Rules, Myths, Anti-Patterns and Controversies
Ravi Tadwalkar and Max Spring
10-July-2012
Abstract:
How does one apply XP?
This interactive workshop is about XP Rules, Myths, Anti-Patterns and Controversies agilists "deal" with.
If we understand XP myths and bust them, we will learn how to apply XP at the core of your corporate process!

2. Agenda
● Business Case for XP
● Scope of XP Myths: Categories
○ Managing (the process): "Team Room"
○ Designing: "Model Driven Architecture"
○ Coding: "Ownership"
○ Testing: "Test Automation"
○ Planning (the product): "Small Releases"
● Q&A

3. Business Case for XP
● How to apply XP at the core of traditional waterfall,
RUP, agile/scrum or lean/kanban processes?
○ XP best practices are like a color palette, once you
learn what each color in the palette means to you,
you can mix and match what works.
○ XP just appears heavyweight, so phase it in.
It’s like weight training. XP is spectrum of practices.
● XP is a continuum, in that we need to apply XP rules to
today's context
● XP from a newcomer’s perspective can involve myths
that can come out of not having exposure to XP rules

4. Scope of XP Myths: Categories
Managing:
team room
Coding:
Ownership Testing:
Automation
Designing:
MDA
Planning:
small releases
sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming

5. Managing (the process): "Team Room"
● What is a team room?
○ A room for "Whole Team" for collaboration

6. Team Room
Myth:
"Team room does not work for us, since I cannot be
sure a) whether people are really working, or
b) people are doing private work."
This functional manager called for yet another all-hands.
Team is fuming over too many and too long meetings.
● Micro-management
● Lack of mutual trust
● Not knowing team/project state causes anxiety

7. Team Room
● A better visualization or materialization of this state
would be helpful
● Team room can be remedy for underlying trust factor
● Team room enables transparent view of all agile
artifacts to all team members and stakeholders
● Human brain mapping capability
○ spatial
○ persistent
○ tactile

8. Team Room
● Large companies create “model team-room"
○ Not just a small “lean startup” aspect anymore
● Colored Sticky Notes
● Geo-distribution
○ cameras (for TP sessions)
○ Wikis
○ Google Docs (shared editing)
● Multi-purpose room
○ gamestorming supplements brainstorming
○ highlight impediments / blockers / obstacles

9. More "Managing" myths
● XP is only for engineers
● Scrum/Kanban can live without XP
● Standup meetings do not work for us,
we need MoM (minutes of meetings)
● Moving people around cannot work,
because we need IC (individual contributors)

10. Scope of XP Myths: Categories
Designing:
MDA
sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming

11. Design (the product): "MDA"
● MDA - Model-Driven Architecture
○ Single Point of Truth (SPOT)
● Domain model
● System metaphor
○ orthogonal to domain model

12. MDA (Model Driven Arch.)
Myth:
"MDA takes too much time."
○ Domain knowledge hardcoded all over the place
○ Often in scripting environments
○ Lack of consistent domain terminology
i.e. (lack of glossary)
○ Inadequate architecture
■ Pieces of architectural "views" exist
○ MDA is BDUF? (big design upfront)

13. MDA - Done Right
● More emphasis on tool chain
● The earlier, the better:
start introducing an explicit domain model early on
● Even if late:
start introducing a small abstract model with concrete
mappings into your existing system
○ model should be an ever-growing SPOT!

14. MDA - Done Right
● Have a true Architecture Driven by Model(s)
● Ideal scenario: Product roadmapping is a starting point
● Avoid (yet another) worst case scenario of being "late"
● Just another layer
of an "inside-out"
approach

15. More "Designing" myths
● We refactor our codebase at the end, after code reviews
● “Simplicity rule for us works this way”:
○ We implement specialized optimizations early on-
knowing that this may end up optimizing “algo”
despite usage pattern
● Spike solutions need to be managed just like any other
engineering work or contract, a spike is used for more
than just doing “feasibility study”!

16. Scope of XP Myths: Categories
Testing:
Automation
sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming

17. Test Automation
Myth:
"Automated tests are impossible for our domain."
● Domain can be difficult to virtualize
Large legacy codebase with little or no test automation
● Very few regressions may have happened thus far, so
there might be over-confidence in code quality

18. Test Automation
● Invest in simplifying domain virtualization
○ simulators/emulators
○ automated runtime materialization (e.g. Puppet)
● Put test CI & reporting site in place to increase
motivation for putting tests in place
○ e.g. Sonar
● Start small, but start putting test automation in place
● Have a software engineer in test & test architect; don't
just resort to getting build-monkeys!

19. More "Testing" myths
● We have never found this working: All code must have
unit tests. Ideally, when you find a bug, you create tests.
● CI does not need TDD, just CI is enough.
● Documentation should be in place before automation
● Prior to “first customer ship”, we cannot dictate that “All
code must pass all tests before it can be released.”
● Ideally, acceptance tests are run often and the score
should be published. We keep little conservative outlook
on this one. We never make our scores public.

20. Scope of XP Myths: Categories
Coding:
Ownership
sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming

21. "Coding" Myth: Ownership
Myth (fact or crap?):
Few XP practices may need face-lift. Specifically:
○ Collective code ownership have an unintended
consequence: "tragedy of the commons".
○ Pair programming works best with developers who
love community service.
● Team ownership creates expertise impedance mismatch:
○ One engineer has contradictory view & conflicting style than others.
This mature developer has passion for longer term view of big picture.
● Pair programming has perceived interchangeability:
○ management "myth" of cross-training team.
○ no respect for specialization

22. Ownership- Done Right
● Ideal: "team structure matches with component graph"
○ each component has an owner (and a backup)
● Distributed teams use proactive pre-commit code review
(e.g. Gerrit) and collaboration tools (e.g. WebEx or vnc),
fulfilling similar purpose as collective code ownership
and pair programming
● Tighter collaboration during design (of interface
contract) between producer & consumer (backed with
TDD)

23. More "Coding" myths
● Customer is always there for you
● Coding standard & style are a must and better be
automated
● we always write unit test last, usually as
“int main(argc[], argv[])” wrapper
● We never do pair programming, since we have
standards for code reviews, walkthroughs and
inspections
● I do scripting, I don’t need CI
● Complex (fancy) “Branch & Merge“ strategy needed for
better CI

24. "Planning" myths
Here are possible "Planning" myths:
● “Small releases” is a misnomer for large-scale product
development teams
● User stories are written upfront, all of them.
● Release planning creates the release schedule that we
can stick to
● The project is divided into iterations, and we change
iteration length at will

25. Scope of XP Myths: Categories
Managing:
team room
Coding:
Ownership Testing:
Automation
Designing:
MDA
Planning:
small releases
sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming

26. Q&A