The document outlines Mike Harris's presentation on eXtreme Programming (XP). It begins by introducing the structure of the presentation, which will explain why XP is important and outline some of its key development practices. It then provides two case studies of projects, one that was underperforming and one that appeared high performing but had similar underlying issues. The document dives into what XP is, outlining its values, principles and practices. It concludes by discussing outcomes the speaker found when applying XP practices.

1. It’s XP, stupid!
Mike Harris

2. The Plan
• Introduce myself
• Explain why I think this is important
• Introduce eXtreme Programming
• Outline my favourite development practices
• Story of the example of outcomes
• Summarise that if you’re not doing XP, you’re not really being Agile

3. Why this talk?
The point is that if you’re not doing XP then it doesn’t matter what methodology
you’re using to manage the project, you’re not writing good software.

4. Case Study: Project X – From the Outside
• A under performing delivery team
• 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
• Master developer telling everyone what to do
• Delivery unpredictable
• Large spreadsheet of backlog representing “Grand Scheme”

5. 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
• No version control
• Shared dev environment
• Dev was never equal to live

6. Case Study: Project Y – From the Outside
• A high performing delivery team
• Experienced crew on same platform for years
• Excellent 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

7. 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)
• Large overhead of story writing, development, QA hand-offs
• Deployment takes up to a day to arrange
• And up to a day to do
• Production version of code does not exist in version control
• Lots of siloed knowledge
• SysOps folks do not understand the App

8. My Conclusion
We’re totally flying

9. LEAN
AGILE
SCRUM
XP

10. What is XP?
A brief recap of eXtreme Programming

11. What is XP?
• Kent Beck
• Chrysler Comprehensive Compensation System (C3) (payroll)
• Became project leader in March 1996
• 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

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

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

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

15. Software Engineering in 2018
Twelve development practices I’ve been doing that I think you should try

16. Twelve development practices
1. Pair Programming & Mob Programming
2. Test-First Test-Right Development
3. Tiny Tasking
4. Self-Documenting Code
5. Trunk Based Development
6. Systematically Check Assumptions
7. Minimum Viable Product
8. Intelligent Technical Debt
9. Automated Deployments
10. Testers are Developers
11. Know Your Tool
12. Regular Feedback

17. 1. Do Pair and Mob Programming
• Two (or more) people share the keyboard
• Taking it in turns to be the driver
• Swapping every 10-20 minutes
• Or whenever it feels right
• Taking breaks when it feels right (and people need to)
• Breaking off to avoid ‘mob googling’
• Rotating on and off on longer stories
• Holding retros on your mobbing
• Writing a mobbing/pairing charter for your team

18. 2. Do Test-First Test-Right Development (TDD)
• Write a test first; then write the code to make the test pass
• Refactor the code and ensure the test still passes
• Repeat
• Test at the most appropriate level of the test pyramid
• Ensuring that all code is tested once
• Unit tests are faster than high-level behavioural tests
• Don’t write unnecessary tests (for example defensive programming)
• Be careful of your code coverage tools; they can mislead

19. 3. Use Tiny Tasking
• 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

20. 3. Tiny Tasking Example

21. 4. Write Self-Documenting Code (SDC)
• Comments should document whys not whats or hows
• Code should be self-explanatory
• Use meaningful names for classes, methods, variables, etc.
• 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
• Get a better IDE if it can’t help you with this (see rule 11)

22. 5. Do Trunk Based Development (TBD)
• Everything we do ought to be production ready
• Merge to trunk as soon as possible
• Ideally multiple times daily
• Branches should only survive overnight
• Delete branches when you start work again
• Use expand and contract techniques
• Spike (experiment) branches may live a little longer
• But they too should be as short-lived as possible
• And they should never become production code (rewrite using TDD)

23. 6. Systematically Check Assumptions
• When you get stuck on something
• Pair or swarm with your colleagues
• Use a board and ask each other
• What you know
• What you don’t know
• What you think you know
• Agree on next steps to confirm what you think
you know
• Timebox and regroup to measure progress

24. 7. Aim for a Minimum Viable Product (MVP)
• Keep the stories small
• Do the smallest thing to prove an idea
• Minimise defensive programming
• Use spikes, showcase prototypes, use the command line
• Stories are placeholders for conversations
• Practice Just In Time Analysis (JITA) where possible
• Descope continually

25. 8. Take on Intelligent Technical Debt (ITD)
• It’s about knowing what the risks are
• Keep a Tech Debt Wall
• 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

26. 8. ITD example (using Trello)

27. 9. Aim for Automated Deployment (AD)
• May be a stretch goal in your organization
• 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 same as Prod

28. 9. Automated Deployment example

29. 10. Testers are Developers
• Testers are developers; developers are testers
• May work best with smaller teams
• Developers pair to write tests
• Developers pair to write code
• Last pair on story do not do QA; another pair does
• Avoids hand-offs (contracts between Dev & QA)
• Enforces developers’ responsibility for writing quality code
• Developers who do QA also see the code (mob effect)
• Get faster feedback

30. 11. 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
• Insist on licences for the best tool for your team

31. 12. Feedback
• Regularly schedule time with your collegaues
• To give face-to-face feedback
• Discuss what you feel your colleague’s strengths are
• Discuss what you feel your colleagure could do to improve
• Use real examples from your experience working with them
• Make sure you prepare

32. 12. Feedback - Example
Observed Behaviour Observed Result Remarks
Was patient with colleague
who didn’t understand the
reasons why we write the
test first. Spent time to work
with them using coding
dojos.
Colleague felt they were
listened to and their
concerns met; was more
open to pairing.
Supportive and
understanding approach a
great asset to the team.
Helps make people feel safer
when challenged by new
ideas and ways of working.
Regularly arrives at stand-ups
late.
Flow of stand-up is often
disrupted, and colleagues
often have to repeat
themselves.
Arriving late is an anti-
pattern and, even if not
intentionally, shows a lack of
respect.

33. Outcomes
What we found when we applied the practices

34. Case Study: Project Z – Where we were
• We were doing the Twelve Practices I’ve outlined
• Our Tech Lead and founding architect left for a smaller company
• 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

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

36. In Summary
• Adopting Scrum or Kanban, or a hybrid, on it’s own is not enough
• It alone doesn’t lead to doing Agile or Lean Software Development
• But rather they are simply ways of 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
• Keep at it, you’ll get there

37. Thank You
Mike Harris . mbharris.co.uk . mike@mbharris.co.uk
ssrn.com . m.harris@elsevier.com . +44 7811 671 893