Engineering Collaboration Practices
Extreme Programming Orientation
XP predates the Agile Manifesto. Beck was one of the seventeen people who wrote and signed the manifesto in 2001, and much of what the industry now calls "agile engineering practice" is XP by another name. Scrum, which most organizations adopted instead, is a management framework: it says how work is planned and inspected, but almost nothing about how code is written. XP fills exactly that gap, which is why mature teams often run Scrum-shaped planning with XP-shaped engineering underneath.
Values Before Practices
XP names five values: communication, simplicity, feedback, courage, and respect. The practices below are only mechanisms for those values. A team that pairs all day but never says what confuses them has the practice without the value, and gets little from it.
The Practices
<?php
declare(strict_types=1);
$practices = [
'test-driven development' => 'write the failing test before the code that passes it',
'pair programming' => 'two developers, one task, continuous review',
'continuous integration' => 'merge and run the full test suite many times a day',
'small releases' => 'ship small increments frequently instead of big batches',
'simple design' => 'build for the current requirement, not an imagined future one',
'refactoring' => 'improve structure continuously while tests stay green',
'collective ownership' => 'anyone may improve any part of the codebase',
'coding standards' => 'one shared style so the code reads as one voice',
'sustainable pace' => 'no permanent overtime; tired developers write defects',
'on-site customer' => 'someone who can answer requirement questions immediately',
];
foreach ($practices as $practice => $meaning) {
echo $practice . ': ' . $meaning . PHP_EOL;
}
// Prints:
// test-driven development: write the failing test before the code that passes it
// pair programming: two developers, one task, continuous review
// continuous integration: merge and run the full test suite many times a day
// small releases: ship small increments frequently instead of big batches
// simple design: build for the current requirement, not an imagined future one
// refactoring: improve structure continuously while tests stay green
// collective ownership: anyone may improve any part of the codebase
// coding standards: one shared style so the code reads as one voice
// sustainable pace: no permanent overtime; tired developers write defects
// on-site customer: someone who can answer requirement questions immediately
The practices reinforce each other. Refactoring is only safe because tests exist. Collective ownership only works because coding standards and pairing spread context. Small releases are only possible because integration happens continuously. Adopting one practice in isolation gives a fraction of the benefit, and most teams that "tried XP and it didn't work" tried exactly one piece of it.
XP In A Modern PHP Team
Every XP practice has a concrete modern PHP form. Test-driven development is PHPUnit or Pest with a red-green-refactor loop. Continuous integration is a pipeline that runs the suite on every push. Coding standards are a shared ruleset enforced by PHP-CS-Fixer or PHP_CodeSniffer rather than argued about in review. Small releases are frequent deploys behind feature flags. Collective ownership shows up as the absence of "that is Maria's module" as a reason a bug stays unfixed.
The practices that need the most deliberate effort today are the human ones: pairing, sustainable pace, and real customer access. The Pair Programming and Mob Programming lessons cover the first in depth; the testing and tooling tracks cover the mechanical ones.
What To Check
Before moving on, make sure you can:
- place XP historically: late 1990s, Kent Beck, before and feeding into the 2001 Agile Manifesto
- explain the difference between Scrum's planning focus and XP's engineering focus
- name the five values and several core practices
- explain why the practices depend on each other rather than working alone
- map each practice to its modern PHP-team equivalent
What You Should Be Able To Do
After this lesson, you should be able to recognize XP practices inside a modern team's workflow, explain which value each practice serves, and argue for adopting practices as a reinforcing set rather than piecemeal.
Practice
Practice: Plan An XP Adoption
A six-developer PHP team has no automated tests, no CI, and reviews by emailing diffs. They want to adopt XP.
Task
Pick the first three XP practices they should adopt, in order. For each, explain why it comes at that position and which later practice it unlocks. Name one practice they should explicitly postpone and why.
Show solution
A defensible order starts with the practices that make the others safe.
First, continuous integration: a pipeline that runs on every push, even while the test suite is nearly empty. It creates the place where every later practice reports, and it kills the emailed-diff workflow as a side effect.
Second, test-driven development on new and changed code only. Retrofitting tests across the whole legacy codebase first is the classic stall; writing the failing test before each change grows coverage exactly where the code is riskiest — where it changes.
Third, coding standards enforced by PHP-CS-Fixer in the pipeline, not by humans. This removes style debate from review before a review culture forms, so reviews start life focused on behavior.
Postpone pair programming until the pipeline and tests exist: pairing pays most on risky work, and right now every change is risky for reasons tooling should fix first. A team pairing over an untested codebase spends the second brain compensating for missing safety nets instead of on design.
The wrong answer is adopting all ten practices on Monday. The practices reinforce each other, but adoption has an order: safety nets first, human practices once there is a net.
Practice: Diagnose A Stalled XP Adoption
Task
Explain why adopting TDD alone produced this result. Name the missing practices and what each would change.
Show solution
TDD was adopted without the practices it is designed to combine with, so its main payoff — cheap, safe change — never arrived.
Refactoring is still feared because tests alone do not create the habit; the team writes tests, then leaves structure untouched. Refactoring as a named, continuous practice uses the green suite as a license to improve design, which is where the speed comes from.
Defects still ship because the tests run on developers' machines, not as a gate. Continuous integration makes the suite the merge gate and catches integration breakage the moment it happens rather than at release.
Two single-person modules persist because nothing spreads context. Collective ownership plus pairing or mobbing on those modules moves knowledge; high coverage does not, because tests document behavior, not reasoning.
The diagnosis pattern generalizes: when one XP practice underdelivers, look for the reinforcing practices it was separated from.
Practice: Verify XP Is Actually Running
A team claims to practice XP. Define six observable checks — things you could verify from their repository, pipeline, and calendar without interviewing anyone — that would confirm or refute the claim.
Show solution
- The pipeline runs the full test suite on every push, and the default branch is green in its recent history.
- Commits that change behavior include test changes in the same commit or pull request; test-after-the-fact shows up as test-only commits trailing by days.
- Merges to the default branch happen multiple times per day, not in week-long batches.
- Style is enforced by a fixer or sniffer in the pipeline; review threads contain no formatting comments.
- Commit authorship and review activity are spread across the team rather than one name per module, which is collective ownership visible in the log.
- Deploys or releases are small and frequent in the release history, not quarterly.
Notice what is not on the list: a wall poster of XP values, a practices page in the wiki, or anyone's job title. XP is a set of behaviors, and behaviors leave evidence.