Den från början mest kända agila metoden heter Extreme Programming och brukar förkortas XP.

Den fick tidigt stöd tack vare konkreta tips om hur programmering kunde förbättras, sett som hantverk, och hur man effektivt arbetar i team. Dessutom såg många XP som en välbehövlig protest mot de tunga processer, exempelvis RUP, som påstod sig vara iterativa, men som oftast havererade till smärtsamma vattenfallsprocesser.

Tillspetsat kan man säga att den utgår från bra saker och drar dem till sin extrem. Exempelvis:

  • Eftersom kodgranskning är bra låt oss göra det hela tiden. Det kallas par-programmering.
  • Eftersom automatiserade tester är bra, låt oss skriva dem först. Det kallas Test Driven Development – TDD.
  • Eftersom det är bra om fler än den ursprungliga programmeraren förstår koden, låt oss ha gemensamt ansvar för den. Det kallas Collective Code Ownership.
  • Eftersom integrering i slutet av projekt är en enda stor smärta, låt oss göra det hela tiden. Det kallas Continuous Integration.

Till skillnad från Scrum talar XP om hur arbetsflödet inom ett team bör se ut. Detta arbetsflöde har ett starkt fokus på kvalitet och samarbete kring kod. XP är därför en självklar kombination med Scrum. Det finns all anledning att bli oroad om ett Scrum team saknar de viktigaste metoderna i XP, såsom Continuous Integration, Pair Programming och Test Driven Development.

Sedan 2001 har vi utbildat i XP, och som konsulter infört dess delar inom många olika projekt. Flera av oss bloggar regelbundet om XP, bland annat

Läs mer om XP

Wikipedia har artiklar om XP på både svenska och engelska. Vidare finns TDD-gurun Ron Jeffries site XProgramming, Don Wells site som kan tankas ner i sin helhet som en zip fil (!), samt den lätt kaotiska sidan om XP på Ward Cunninghams c2 wiki.