Mike Harris discusses the importance of Extreme Programming (XP) in software development, highlighting its values, principles, and practices that contribute to better software quality. Through various case studies, he contrasts experiences of teams using different methodologies, emphasizing that XP helps mitigate legacy code issues and enhances team dynamics. He concludes that while adopting project management frameworks like Scrum or Kanban is useful, they are insufficient without integrating XP practices.

1. It’s XP, Stupid!
AOTB On Tour - Birmingham . 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 newer practices I think are helpful
• Sum up

3. • Developed The Fractal Engine for Atari ST in GFA BASIC and 68000 assembler
• Degree in Computing for Real-Time Systems back in 1993
• On and off software engineer since then
• Developed CMS systems through the nineties and noughties in ColdFusion, Perl,
and PHP
• Used pretty much the methodology I took from Uni with embellishments:
“adapted agile waterfall method”.
• Heard about XP in the mid-noughties; dismissed it!
• Finally started to learn about it in 2013: converted
• Have since evangelised it wherever I’ve worked in software development teams
• Now programming in ColdFusion again!

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

5. Case Study: 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. Case Study: Project X – From the Inside
• Almost all code is legacy code (not tested)
• 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
• Shared dev environment
• Dev was never equal to live

7. Case Study: 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

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

9. My Conclusion
We’re totally flying

10. LEAN
AGILE
SCRUM
XP

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

12. What is XP?
• Coined by Kent Beck circa 1996
• Chrysler Comprehensive Compensation System (C3) (payroll)
• Refined methodology used on project
• 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

13. What is XP?
• Values
• Principals
• Practices

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

15. 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

16. XP Practices
• Co-Located
• Whole Team
• Informative Workspace
• Energised Work
• Pair Programming
• Stories
• Weekly Cycle (iterations)
• Quarterly Cycle (releases)
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design

17. How does XP fit?
In Agile, Scrum, Lean, Kanban, PRINCE2, etc?

18. Comparison of methodologies
More Project Management Orientated
• Scrum
• Kanban
• PRINCE2
• SAFe
• ScrumBan
• Lean
More Development Orientated
• XP

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

20. Does XP work with Kanban?
• Co-Located
• Whole Team
• Informative Workspace
• Energised Work
• Pair Programming
• Stories
• Weekly Cycle (iterations)
• Quarterly Cycle (releases)
• Continuous Delivery
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design


21. Does XP work with Scrum?
• Co-Located
• Whole Team
• Informative Workspace
• Energised Work
• Pair Programming
• Stories
• Weekly Cycle (iterations)
• Quarterly Cycle (releases)
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design


22. Does XP work with Waterfall?
• Co-Located
• Whole Team
• Informative Workspace
• Energised Work
• Pair Programming
• Stories
• Weekly Cycle (iterations)
• Quarterly Cycle (releases)
• Slack
• Ten-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design


23. But hang on a 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).

24. Applying XP in 2019
Eight techniques I’ve practised that you ought to try

25. Eight techniques you ought to try
1. Doing Mob Programming
2. Writing Self-Documenting Code
3. Knowing Your Tool
4. Automating Deployment
5. Trying Tiny Tasking
6. Systematically Checking Assumptions
7. Taking on Intelligent Technical Debt
8. Providing Regular Feedback

26. 1. Do Mob Programming
• More than two people share the keyboard
• Take it in turns to be the driver
• Swapping every 10-20 minutes
• Take breaks regularly
• Break off to avoid ‘mob googling’
• Hold daily retros on your mobbing
• Mob to write a mobbing charter for your team
• Great for on-boarding new team members
• Great for new project/work inception

27. 2. Write Self-Documenting Code (SDC)
• 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
• Apply as many SOLID and Clean Code principles as possible
• Use your IDE to help improve your code’s readability
• Spend time refactoring every bit of code you touch

28. 3. Know Your Tool
• Use your tool’s support for refactoring
• Learn your tool’s most useful keyboard shortcuts
• Learn how to configure your tool
• Ensure you can run tests from within your tool
• Use the best tool for the code base you’re working on
• Get a better IDE if the one you’re using is crap
• Insist on licences for the best tool for your team

29. 4. Automate Deployment
• Could be a stretch goal in your project
• SysOps may be siloed and traditional
• Platform and/or stack might not permit it
• Allow developers to learn the platform
• Cloud computing makes this much more possible
• Infrastructure as code (CloudFormation, Terraform)
• Means your infrastructure can be version controlled
• Ensure QA, Dev, Staging environments are same as Prod

30. 5. Use Tiny Tasking
• Great technique to use with pair programming
• Break a small story into baby steps
• Plan out and agree what you’re going to do 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

31. 6. Systematically Check Assumptions
• When you get stuck on something
• Pair or swarm with your colleagues
• Use a board and ask each other
• What do we know?
• What do we not know?
• What do we think we know (assumptions)?
• Agree on next steps to confirm what you think
you know
• Timebox and regroup to measure progress

32. 7. Take on Intelligent Technical Debt (ITD)
• 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

33. 8. Provide Feedback
• Regularly schedule time with your
colleagues
• To give face-to-face feedback
• Discuss what you feel your
colleague’s strengths are
• Discuss what you feel your
colleague could do to improve
• Use real examples from your
experience working with them
• It’s respectful to your colleague to
have thought about them
• So, make sure you prepare

34. Outcomes
What we found when we applied the practices

35. Case Study: Project Z – Where we were
• We were doing most of the XP practices plus the Eight I’ve 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

36. Case Study: 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 devs 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

37. In Summary
• Adopting Scrum, Kanban, or a hybrid, on it’s own is not enough
• They won’t lead you to do Agile/Lean Software Development
• As they are simply methods for doing project management
• XP helps you to mitigate against legacy code
• XP helps you write better software
• 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 well with Waterfall methodologies
• The Fractal Engine was the best software project I’ve been involved in
• ColdFusion is still a thing

38. Thank You
Mike Harris . ssrn.com . elsevier.com . m.harris@elsevier.com
mbharris.co.uk/fe3