Agile Engineering Practices: Beyond Scrum Ceremonies

Agile works when engineering practices support the methodology.

Extreme Programming (XP) Core Practices

Continuous Integration

# CI runs on every commit to main
# Never let main stay broken
on:
  push:
    branches: [main, 'feature/**']

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: npm test
      - run: npm run build
    # Build must stay under 10 minutes

Test Automation

// Automated test pyramid:
// Many unit tests (fast, isolated)
// Some integration tests (medium speed)
// Few E2E tests (slow but critical paths)

// Target: 80% code coverage
// But coverage is a floor, not a ceiling

Pair Programming

Driver: writes code
Navigator: reviews, thinks ahead, asks questions

Benefits:
- Knowledge sharing
- Fewer bugs (two pairs of eyes)
- Better design (talking through it)
- No bus factor (knowledge shared)

Practical:
- Switch roles every 30 minutes
- Use VS Code Live Share or Tuple
- Remote pairing works too

Sustainable Pace

Anti-patterns:
- Heroic sprints (unsustainable overtime)
- Technical debt accumulation under pressure
- Skipping tests when "behind"

Better approach:
- Consistent velocity over time
- Protect time for tech debt reduction
- No overtime as a normal practice
- "Yesterday's weather" for planning

Story Slicing

INVEST criteria for user stories:
Independent - can be deployed alone
Negotiable - details can be discussed
Valuable - delivers user/business value
Estimable - team can estimate it
Small - completable in 1-2 days
Testable - clear acceptance criteria

Vertical slicing (good):
"User can log in with email and see their dashboard"
= tiny end-to-end slice

Horizontal slicing (bad):
"Build the database layer for authentication"
= no user value on its own

Definition of Done

## Definition of Done

A user story is done when:
- [ ] Code written and passing all tests
- [ ] Unit test coverage >= 80%
- [ ] Code reviewed and approved
- [ ] Acceptance criteria met (manual verification)
- [ ] Deployed to staging environment
- [ ] No new critical/high security vulnerabilities
- [ ] Documentation updated (if API changed)
- [ ] Product owner accepted

Sprint Retrospectives

What worked well?
- Celebrate successes

What didn't work?
- Problems encountered

What will we do differently?
- ONE specific action item per retro
- Assign owner and due date

Review last retro's action items first

Metrics That Matter

Lead time: commit to production (hours, not weeks)
Deployment frequency: how often you can deploy safely
Change failure rate: % of deployments causing incidents
Mean time to recovery: how fast you fix incidents

These DORA metrics correlate strongly with team performance.

Agile succeeds when the engineering practices are as strong as the process.