In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled." So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself? Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP? This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about. The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020. Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/

1. XP: Revisited
Mike Harris

2. My Plan
• Introduce myself
• Give the background to why I think this is important
• Introduce eXtreme Programming
• Look at how XP works alongside other methodologies
• Outline some XP-like practices I use and think are helpful
• Sum up

3. Me
• Developed The Fractal Engine for Atari ST in
GFA BASIC and 68000 assembler
• Degree in Computing for Real-Time Systems
• On and off software engineer since then
• Developed CMS systems through the nineties
and noughties in ColdFusion, Perl, and PHP
• Heard about XP first in 2005; dismissed it!
• Finally started to pay attention to XP in 2013
• Have since evangelised it wherever I’ve
worked in software development teams
• Recently I’ve been working in ColdFusion
again!
FOR a&=line_start& TO line_end&
'
temp%=real%(a&)
reg%(0)=temp%
temp=temp%
temp_2%=temp*temp/jul_div% ! x2
reg%(4)=temp_2% ! 16 BIT ONLY
reg%(8)=temp_2% ! 32 BIT ONLY
temp%=imag%(line_pos&)
reg%(1)=temp%
temp=temp%
temp_2%=temp*temp/jul_div% ! x2
reg%(5)=temp_2% ! 16 BIT ONLY.
reg%(9)=temp_2% ! 32 BIT ONLY.
reg%(7)=max_it&
reg%(10)=c_re%
reg%(11)=c_im%
RCALL address%,reg%()
'
it%=reg%(7)
IF NOT it%=65535
it%=(2+max_it&-it%) DIV spread|
PSET a&,line_pos&,col_index|(it% MOD 14+2)
ENDIF
'
NEXT a&

4. Why this talk?
If you’re not practising XP, you’re probably not writing your best software.

5. Project X – From the Outside
• Experienced crew on same platform for years
• Huge backlog of unprioritized work
• Unavailable in the mornings
• Customer had no faith in team’s ability to deliver
• Strong lead developer with clear vision
• Delivery unpredictable
• Large spreadsheet of backlog representing “The Grand Scheme”
• Plan to stop all other work and deliver TGS

6. Project X – From the Inside
• Almost all code is legacy code (no tests at all)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• Priorities based on biggest manager ego
• Master developer telling everyone what to do
• Other developers unable to make decisions for themselves
• No version control
• Single shared dev environment
• Dev was never equal to Prod

7. Project Y – From the Outside
• A high performing delivery team
• Experienced crew on same platform for years
• Great relations with customer
• Excellent inter-personal relations in team
• Perception of delivery fast and on time
• Well managed customer relations and expectations
• Lovely cycle-time graphs produced
• Nice burn-up charts delivered
• Excellent Scrum ceremony management

8. Project Y – From the Inside
• Almost all code was legacy code (not tested)
• Complex tightly-coupled system (hard to change)
• Dragon infested areas of the code (can’t be changed)
• BDD test suite was retro fitted and took a long time to run, often failing
unpredictably (and therefore was not run often)
• Large overhead of story writing, development, QA hand-offs
• Deployment took up to a day to arrange
• And several hours to do
• Production version of code did not exist in version control
• Lots of siloed knowledge amongst developers
• SysOps and Devs siloed; not shared understanding of full tech stack

9. My Conclusion
We’re totally flying

10. So, what is XP?
A brief recap of eXtreme Programming

11. Hang on, but what is Agile?
Agile is not about going fast,
it’s about knowing, as early as possible,
just how screwed we are.
- Robert C. Martin

12. Agile Values
• Individuals and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

13. So, what is XP?
A brief recap of eXtreme Programming

14. What is XP?
• Coined by Kent Beck approx. 1996-03-06
• Who had worked previously with Ward Cunningham at Tektronix
in the 1980s
• Refined methodology he’d used on the payroll project
Chrysler Comprehensive Compensation System (C3)
• Into his book ”Extreme Programming Explained”
• Which was published way back in October 1999
• (The 2nd Edition of the book was published in 2004)
• He didn’t invent all the practices (such as TDD)
• He codified them into an umbrella methodology: XP

15. XP Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect

16. XP Principles
• Humanity
Safe space for collaboration and growth
• Economics
Must be affordable, must meet business values
• Mutual Benefit
What we do we do for the benefit of everyone
• Self-Similarity
Reuse solutions even at different scales
• Improvement
Perfect your process; not a perfect process
• Diversity
Team members have a variety of skills, celebrate this
• Reflexion
Think about how and why we’re working in the way we are
• Flow
Deliver a steady flow of valuable software
• Opportunity
Problems are opportunities for change and improvement
• Redundancy
Solve critical difficult to solve problems in several different ways
• Failure
Don’t be afraid of it
• Quality
Do not accept lower quality to make products go faster
• Baby Steps
Do things a little bit at a time
• Accepted Responsibility
You decide if you are responsible or if you’re not

17. XP Practices
Planning
Game
Acceptance
Tests
Small
Releases
Whole
Team
Consistent
Metaphor
Sustainable
Pace
Collective
Ownership
Continuous
Integration TDD
Refactoring
Simple
Design
Pairing
Business Facing
Team Facing
Technical
The XP Circle of Life – Ron Jeffries

18. Returning to My Conclusion

19. XP Practices
Planning
Game
Acceptance
Tests
Small
Releases
Whole
Team
Consistent
Metaphor
Sustainable
Pace
Collective
Ownership
Continuous
Integration TDD
Refactoring
Simple
Design
Pairing
Business Facing
Team Facing
Technical
The XP Circle of Life – Ron Jeffries

20. How does XP fit?
In comparison with Agile, Scrum, Kanban and Waterfall

21. Comparison of methodologies
Project Management Software Development
SAFe
Scrum
Kanban
Lean Software Development
Waterfall
Lean
XP
PRINCE2

22. XP and the Agile Manifesto
• Individuals and Interactions over processes and tools
• Whole Team, Metaphor, Collective Ownership, Pairing, Sustainable Pace
• Working software over comprehensive documentation
• Acceptance Tests, TDD, Simple Design, Refactoring, Continuous Integration
• Customer collaboration over contract negotiation
• Small Releases, Planning Game, Acceptance Tests, Consistent Metaphor
• Responding to change over following a plan
• Small Releases, Planning Game, Sustainable Pace, TDD, Refactoring,
Acceptance Tests

23. Kanban with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Game
看
板

24. Scrum with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Games Delivery

25. Waterfall with XP
• Whole Team
• Consistent Metaphor
• Collective Ownership
• Pairing
• Sustainable Pace
• Acceptance Tests
• TDD
• Simple Design
• Refactoring
• Continuous Integration
• Small Releases
• Planning Game

26. But hang on one minute….
Winston W. Royce's final model illustrated that feedback could (should, and often
would) lead from code testing to design and from design back to requirements. In the
same paper Royce also advocated large quantities of documentation, doing the job
"twice if possible" (a sentiment similar to that of Fred Brooks, famous for writing the
Mythical Man Month, an influential book in software project management, who
advocated planning to "throw one away"), and involving the customer as much as
possible (a sentiment similar to that of Extreme Programming).

27. Royce: Revisited

28. Managing the Development
of Large Software Systems
Dr Winston W. Royce. Proceedings, IEEE WESCON, August 1970, pages 1-0 © IEEE

29. Royce’s Final Model
Dr Winston W. Royce. Proceedings, IEEE WESCON, August 1970, pages 1-0 © IEEE

30. Royce’s Five Practices
1. Design Comes First
- Customer should know roughly what they want.
- Stories should be minimally scoped
2. Document the Design
- Document architecture and integration points
- Code should be self-documenting
3. Do It Twice
- Spikes, MVPs, Prototypes
- Cross-functional teams
4. Plan, Control, Monitor Testing
- This is most changed, due to CI/CB and move away from siloed QA
5. Involve the Customer
- Customer collaboration over contract negotiation

31. XP’s Technical & Team Practices
Filling in the Software Project Hole

32. Simple Design
• Keep your design as simple as possible (KISS)
• Only implement what you need
• Practise YAGNI (You Ain’t Gonna Need It)
• Practise the Rule of Three
• Domain Driven approaches will help you
• Test Driven Development will make your code simpler
• Don’t write code unless you really need to

33. Do TDD. Like really do it.
• Write your test first
• Make it pass
• Refactor
• Write another test
• Repeat

34. Test driven developers
are not skilled at
operating a debugger.
- Robert C. Martin

35. Refactor
• Do it all the time
• Do it constantly
• Do it as soon as possible
• Don’t ask for permission
• Don’t make it a story
• Don’t leave doing it
• Your code will rot if you don’t!

36. Write Self-Documenting Code
• Our code should be self-explanatory
• Comments should document whys not whats or hows
• Classes, methods, variables, etc, should have meaningful names.
• When starting out, call something a foo; until you know what it does
• Use your IDE to help improve your code’s readability
• Spend time refactoring every bit of code you touch
• Even the code that isn’t yours
• In fact all code is yours if you’re working with it

37. Continuous Integration
• Learn how to use Git
• Like, really learn how to use the different Git commands
• Regularly merge/rebase master if using feature branch
• But, aim for trunk-based development
• Regularly merge back to master and push
• Like regularly, measured in minutes, not hours, nor days

38. Continuous Integration only works
if you integrate continuously
- Robert C. Martin

39. Pair Programming
• Reduces need for code reviews, QA checks, etc
• Helps share knowledge in the team
• Helps eliminate silos
• Two heads really are better than one
• Just do it!
• But it is a practice
• Make sure you do it right
• And don’t do it all the time

40. Tiny Tasking
• Great technique to use with pair programming
• Break a small story into baby steps
• Agree first with your pairing partner
• Put the critical path on sticky notes and place them on the desk in front
• Go into a correct level of detail
• Too many tiny tasks indicate:
• Too much up front planning
• A story that’s too big
• Tiny tasks are too small
• A new person rolling on to a story can catch up on the tasks left to do
• This gives you both a way of transferring knowledge and establishing context

41. Mob Programming
• Great for on-boarding new team
members
• Great for new project/work inception
• Take breaks regularly
• Avoid ‘mob Googling’
• Hold daily retros
• Have a mob programming charter

42. Collective Ownership
• You may have wrote it, but it’s not your code
• The team owns the code
• Not you
• Be prepared to work on other code
• Be prepared for someone to change, or even delete, your code
• Be prepared to jump onto a story when someone is away

43. Technical Debt Wall
• It’s about knowing what the risks are
• Keep a Tech Debt Wall (Trello is a good tool for this)
• Note down any technical debt you accrue as you develop
• Consider the risk of postponing resolution vs the cost of sorting now
• Don’t engineer the future: resolve in the next iteration
• Regularly review the Tech Debt Wall
• Categorise the debt on the wall
• Take highest risk technical debt into backlog and resolve
• Delete technical debt that no longer is, or is no longer relevant

44. Outcomes
What I found when we applied the practices

45. Project Z – Where we were
• We were doing pretty much all of the XP and other practices outlined
• Our Tech Lead and founding architect left for a Start Up
• Two other contracted developers moved on at the same time
• We took on two new developers shortly afterwards
• We were a small team with lots of risk
• Loosing critical mass on our dev practices was a possibility
• There was potentially a lot of overhead onboarding new folks
• And this would slow us down

46. Project Z – The Results
• The fact we’d done pair programming meant
• All developers had some knowledge of every part of the software
• Within weeks we were able to do a complete hand-over
• And made a smooth transition to a new tech lead
• Pairing and mobbing meant that new developers could do valuable
work from day one
• Our code was self-documenting and covered by descriptive tests
• Helped with onboarding new members
• No balls were dropped

47. In Summary
• Adopting Scrum, Kanban, or a hybrid, on it’s own is not enough
• They won’t lead you to do Agile Software Development
• As they are primarily methods for managing software projects
• XP helps you write better software
• XP helps you to mitigate against legacy code
• You may not be able to do everything
• But at least do some of the things
• It can be hard to change
• But keep at it; you will get there
• XP will even work with Waterfall methodologies
• The Fractal Engine was the best software project I’ve been involved in
• ColdFusion is still a thing

48. Perhaps Uncle Bob puts it better?
Without TDD, Refactoring, Simple Design,
and yes, even Pair Programming,
Agile becomes an ineffectual flaccid
shell of what it was intended to be.
- Robert C. Martin

49. What happened to Frank?
• The Author of GFA BASIC
• And Turbo-Basic XL for Atari 8 bit
• Atari ST support ended in 1991
• By 2002 GFA was Bankrupt
Frank Ostrowski 1960 - 2011

50. Thank You
Mike Harris . m.harris@elsevier.com
https://mbharris.co.uk/fe3