In this post
Your reviewer is asleep when your pull request lands, and you will be asleep when the review comes back. Extreme Programming was written for a team in one room, so the question is which of its practices still work when overlap shrinks to an hour or none.
The Agile Manifesto states the tension itself: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” (Principles behind the Agile Manifesto). An async team gives that up on purpose. What replaces it has to be written down, and the practices below are the ones that produce something written as a side effect of the work.
What carries over unchanged #
Small, frequent integration. DORA’s research describes continuous integration as developers merging into the main line regularly, with automated tests run before and after the merge, and the team stopping to fix a red build immediately (DORA: continuous integration). It cites the 2015 State of DevOps Report, which found that teams perform better when developers merge their work into trunk at least daily, and DORA’s trunk-based development page describes branches that last hours rather than days. For a team across time zones this is the main coordination mechanism: the person who wakes up in Warsaw can read what the person in San Francisco merged, and the build tells them whether it works.
Tests as the written contract. XP’s “code the unit test first” rule (Extreme Programming Rules) turns into a handoff tool when nobody is online to explain what the code should do. A failing test tells the next person what is wanted without a call. Test behavior a user can see, not internals, or a refactor by someone in another time zone will break tests for reasons nobody can discuss until the next day.
Sustainable pace. XP lists “set a sustainable pace” as a management rule, and the Agile Manifesto’s version is that sponsors, developers and users “should be able to maintain a constant pace indefinitely.” Async work is a way to honor that: nobody is expected to join a call at 11 p.m. to keep a project moving.
What has to change #
Pair programming becomes a written review loop #
Two people at one keyboard has no async equivalent, and pretending otherwise produces ceremony. What carries the same value is a review that explains itself: a pull request description that says what changed and why, a reviewer who asks questions in the diff, and a written next step. DORA lists working in small batches as a capability that predicts delivery performance (DORA: working in small batches). The smaller the change, the faster someone half a day away can understand it.
If you want live pairing for hard problems, schedule it in the overlap hours and write down what you decided afterward. Treat the overlap as scarce and spend it on the work that needs voices.
Stand-ups become a short written post #
A written stand-up is a few lines: what shipped, what is next, what is blocked. We cover it in how to make small, valuable async standups. The rule that matters is on the blocked line: write what you tried, so the next person in the chain can start from there instead of from zero.
Screenshot baselines let you review UI without watching it #
Reviewing a CSS or layout change by eye is hard to do async. A visual-regression test turns “does it look right?” into a diff in the pull request. snap_diff-capybara is a visual-regression gem where Paul Keen of JetThoughts is the top contributor. It stores baseline screenshots in git, so a UI change shows up as a changed image in review (README). On naming: the README tells new projects to install snap_diff-capybara, pinned to a prerelease (2.0.0.beta4 when we read it on 30 October 2026), while the 1.x line ships on RubyGems as capybara-screenshot-diff. As of 4 October 2026 capybara-screenshot-diff held the download history (871,835 total, per the RubyGems API) and snap_diff-capybara was a name reservation. Check which name your version needs. Setup per the README:
# Gemfile
gem 'snap_diff-capybara', '2.0.0.beta4'
gem 'ruby-vips'
# test/test_helper.rb
require "snap_diff/integrations/minitest"
# test/application_system_test_case.rb
require "test_helper"
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
driven_by :selenium, using: :headless_chrome, screen_size: [1400, 1400]
include SnapDiff::Minitest::Assertions
end
# test/system/homepage_test.rb
require "application_system_test_case"
class HomepageTest < ApplicationSystemTestCase
test "homepage" do
visit "/"
assert_matches_screenshot "homepage"
end
end
The README says the first run saves baselines and always passes, and that in CI fail_if_new defaults to true, so a missing baseline fails the build instead of silently passing. Its VIPS comparison defaults to a tolerance of 0.001, which allows a 0.1 percent pixel difference (configuration docs). Because the baselines are files in the repository, the reviewer in another time zone sees the before and after images next to the code.
Two caveats. Screenshots differ across machines unless you pin the browser and window size, which the README calls out. And a tolerance loose enough to hide real changes defeats the purpose, so loosen it only after looking at the diff images. We have not measured how much this reduces review time; the claim is only that it gives the reviewer something concrete to look at.
When this does not fit #
The Agile Manifesto’s face-to-face principle still applies. If your team shares four hours of the day, use them: a short call resolves misunderstandings in minutes that a pull request thread can stretch to days. Written coordination costs time at both ends, and the post-hoc documentation is only as good as the people writing it. For a two-person team in one time zone, most of the above is overhead. Start with the one practice that fits your pain, usually small merges plus a CI gate, and add others when a specific delay justifies them.
Where to go next #
- The async communication advantage covers the communication side.
- A delivery flow for distributed teams shows how work moves across the board.
- Onboarding AI agents and humans alike covers the written context a new person needs.
If you need an embedded team that already works this way, see how we work.
Sources #
- Principles behind the Agile Manifesto - face-to-face conversation, constant pace.
- DORA: continuous integration, trunk-based development and working in small batches.
- Extreme Programming Rules - “Set a sustainable pace”, “Code the unit test first”.
- snap_diff-capybara README and configuration docs, read 30 October 2026.
