XP, Kanban and DevOps

XP: four activities, and the practices hanging off them

Extreme Programming (XP) organises a set of rules and practices inside four framework activities: planning, design, coding and testing. Where Scrum is opinionated about management and silent about engineering, XP is the reverse.

Planning — sometimes called the planning game — begins with listening, which produces user stories: short descriptions of required output and function, written by the customer on index cards. The customer assigns each story a value based on business priority; the team assigns it a cost in development weeks. Customer and team then group stories into the next release, and order them one of three ways: everything at once, highest-value first, or riskiest first. After the first release the team computes project velocity — the number of customer stories actually implemented — and uses it to estimate the releases that follow. Velocity is what makes the plan self-correcting: it replaces an argument about how fast the team should be with a measurement of how fast it is.

Design follows the keep-it-simple principle, and building extra function because you assume you will need it later is explicitly discouraged. CRC cards are the only design work product XP produces. When a design problem is genuinely hard, XP prescribes an immediate operational prototype of just that part — a spike solution. And design continues after coding starts, through refactoring: modifying code to improve its structure without changing its external behaviour.

Coding writes the unit tests first, so the developer aims at a defined target before writing the implementation. Pair programming puts two people at one machine, buying real-time problem solving and real-time review. Completed work is merged through continuous integration, which surfaces interface and compatibility errors in hours instead of at a milestone. Testing automates those unit tests into a regression suite — necessary, because refactoring changes code constantly — and adds acceptance tests, specified by the customer and derived from the user stories.

Kanban: the differentiator is the WIP limit

Kanban is a lean method for improving an existing process rather than replacing it. Its six core practices: visualise the workflow on a board whose columns are development stages and whose cards are stories or defects; limit the work in progress (WIP); manage the flow to remove waste by finding where value stalls; make process policies explicit — write down how you choose what to work on and what done means; drive improvement from measured feedback; and change the process collaboratively. The daily standup is walking the board, and leadership of it rotates.

The common error is to call Kanban "Scrum without sprints". Its real differentiator is the WIP limit: developers finish what they have started before starting anything else. That is a fundamentally different control mechanism from a time-box — a time-box limits how long you may take, a WIP limit limits how many things may be in flight.

DevOps: a loop, not a tool chain

DevOps applies agile and lean principles across the whole software supply chain, from planning to production operation, by putting development and operations staff on the same team. Its stages loop continuously: continuous development (increments handed straight to testing), continuous testing (automated, several increments at once), continuous integration (new code joined to the existing code and run-time environment), continuous deployment (installed into production, possibly across many sites), and continuous monitoring (operations people on the team watching the running product and finding problems before users do). Monitoring is the stage that closes the loop, feeding what production actually does back into the next plan. Describing DevOps as a set of tools is the standard marked-down answer: the tools are the implementation, the loop is the idea.

Worked example — BorrowBox runs Scrum and borrows from all three

BorrowBox runs Scrum, and by sprint 9 the ceremonies were immaculate and the codebase was not. The late-fee routine had grown to the point where every change to it broke something else, because nothing in Scrum requires a test to be written first or a design to be refactored. The team adopted three XP practices inside the Scrum frame — tests before code on the fee and hold logic, pair programming on the locker interface, and continuous integration on every push. More Scrum would not have fixed it; the defect was in engineering practice, and Scrum has nothing to say there.

The librarians' inspection queue had a different problem: work piled up as five part-finished inspections while the depot waited on tools that were physically present but not yet re-shelved. The fix was Kanban's, not Scrum's — a board with an explicit WIP limit of two inspections per librarian, and a written policy for what inspected means. Lead time from return to available fell without anyone shipping faster.

Finally, the locker firmware releases were dangerous: a bad build meant doors that would not open on a public street. The team ran the DevOps loop for that component — automated deployment to one depot, continuous monitoring of door-open latency and failure counts, and an automatic rollback trigger — so that operations telemetry fed the next sprint's backlog directly. Three frameworks, three different problems, one project. They compose because they answer different questions.