Mob programming: the whole team on one computer, one task, one piece of flow at a time

Around 2011 a software team at Hunter Industries in San Diego found itself facing the usual agile dramas — context lost in handoffs, status meetings that repeated what everyone already knew, and knowledge locked in individual heads. The team practiced test-driven development and ran coding dojos, and one dojo experiment changed everything: everyone worked on the same problem at the same computer at the same time. It felt so productive they asked why they ever worked any other way — and mob programming was born.

The mechanics are deliberately simple: the whole team works on one task, at one time, in one space, on one computer. One person drives; everyone else navigates — reviewing, suggesting, catching typos. The driver changes every few minutes. Work proceeds in one-piece flow with continuous review built into every keystroke, tests written first, and working software delivered every day. Woody Zuill, the team's guide, described the goal as 'all the brilliant people working on the same thing at the same time in the same space on the same computer.'

What disappeared was the striking part: communication problems, decision deadlocks, technical debt, estimation waste, thrashing between tasks, and most of the meeting load. Because everyone had context, nobody needed status updates; because the whole team reviewed as it wrote, mistakes were caught within seconds. None of the ingredients was new — pairing, TDD, retrospectives — but collapsing the team into one unit made the coordination costs of software development largely disappear.