Mythical XP-      Dealing with XP Rules, Myths, Anti-Patterns and Controversies                                        Rav...
Agenda●   Business Case for XP●   Scope of XP Myths: Categories    ○   Managing (the process): "Team Room"    ○   Designin...
Business Case for XP● How to apply XP at the core of traditional waterfall,   RUP, agile/scrum or lean/kanban processes?  ...
Scope of XP Myths: Categories                                                                                             ...
Managing (the process): "Team Room"●   What is a team room?    ○   A room for "Whole Team" for collaboration
Team RoomMyth:   "Team room does not work for us, since I cannot be   sure a) whether people are really working, or   b) p...
Team Room● A better visualization or materialization of this state   would be helpful● Team room can be remedy for underly...
Team Room● Large companies create “model team-room"  ○ Not just a small “lean startup” aspect anymore● Colored Sticky Note...
More "Managing" myths● XP is only for engineers● Scrum/Kanban can live without XP● Standup meetings do not work for us,  w...
Scope of XP Myths: Categories                                                                                             ...
Design (the product): "MDA"● MDA - Model-Driven Architecture  ○ Single Point of Truth (SPOT)● Domain model● System metapho...
MDA (Model Driven Arch.)Myth:   "MDA takes too much time."   ○ Domain knowledge hardcoded all over the place   ○ Often in ...
MDA - Done Right● More emphasis on tool chain● The earlier, the better:   start introducing an explicit domain model early...
MDA - Done Right● Have a true Architecture Driven by Model(s)● Ideal scenario: Product roadmapping is a starting point● Av...
More "Designing" myths● We refactor our codebase at the end, after code reviews● “Simplicity rule for us works this way”: ...
Scope of XP Myths: Categories                                                                                             ...
Test AutomationMyth:   "Automated tests are impossible for our domain."● Domain can be difficult to virtualizeLarge legacy...
Test Automation● Invest in simplifying domain virtualization   ○ simulators/emulators   ○ automated runtime materializatio...
More "Testing" myths● We have never found this working: All code must have  unit tests. Ideally, when you find a bug, you ...
Scope of XP Myths: CategoriesCoding:Ownership   sources: http://www.extremeprogramming.org/rules.html   http://xprogrammin...
"Coding" Myth: OwnershipMyth (fact or crap?):   Few XP practices may need face-lift. Specifically:   ○ Collective code own...
Ownership- Done Right● Ideal: "team structure matches with component graph"   ○ each component has an owner (and a backup)...
More "Coding" myths● Customer is always there for you● Coding standard & style are a must and better be   automated● we al...
"Planning" mythsHere are possible "Planning" myths:● “Small releases” is a misnomer for large-scale product   development ...
Scope of XP Myths: Categories                                                                                             ...
Q&A
Upcoming SlideShare
Loading in …5
×

Managing xp

196
-1

Published on

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

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

No notes for slide

Managing xp

  1. 1. Mythical XP- Dealing with XP Rules, Myths, Anti-Patterns and Controversies Ravi Tadwalkar and Max Spring 10-July-2012Abstract: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. 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. 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 todays context● XP from a newcomer’s perspective can involve myths that can come out of not having exposure to XP rules
  4. 4. Scope of XP Myths: Categories Managing: team room Coding: Ownership Testing: Automation Designing: MDAPlanning:small releases sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
  5. 5. Managing (the process): "Team Room"● What is a team room? ○ A room for "Whole Team" for collaboration
  6. 6. Team RoomMyth: "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. 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. 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. 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. 10. Scope of XP Myths: Categories Designing: MDAsources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
  11. 11. Design (the product): "MDA"● MDA - Model-Driven Architecture ○ Single Point of Truth (SPOT)● Domain model● System metaphor ○ orthogonal to domain model
  12. 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. 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. 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. 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. 16. Scope of XP Myths: Categories Testing: Automationsources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
  17. 17. Test AutomationMyth: "Automated tests are impossible for our domain."● Domain can be difficult to virtualizeLarge 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. 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; dont just resort to getting build-monkeys!
  19. 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. 20. Scope of XP Myths: CategoriesCoding:Ownership sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
  21. 21. "Coding" Myth: OwnershipMyth (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. 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. 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. 24. "Planning" mythsHere 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. 25. Scope of XP Myths: Categories Managing: team room Coding: Ownership Testing: Automation Designing: MDAPlanning:small releases sources: http://www.extremeprogramming.org/rules.html http://xprogramming.com/what-is-extreme-programming
  26. 26. Q&A

×