Be Quick, But Don't Hurry: Agility vs. Rushed Speed

Definition

A widespread misconception is that agility means "just do it faster"—compressing schedules, cutting staff, or reducing budget without actually changing how work is done. In reality, this produces "death march" projects: brutal, exhausting, high-failure-rate initiatives. True agility is rapid and disciplined—it comes from improving the process, enabling teams, and responding intelligently to change, not from brute force acceleration. The distinction, drawn from basketball coach John Wooden's famous maxim "Be quick, but don't hurry," is that being quick requires discipline and training, while hurrying is a brute-force approach with a much lower success rate.

In the Book

Cobb defines a "death march" project, citing Edward Yourdon: a project whose parameters exceed the norm by at least 50%, typically involving a compressed schedule (12 months of work in 6), reduced staff (half of what's needed), cut budget, and doubled functionality—all at once. "Basically, a death march project amounts to pressuring project teams to just do the same work faster without necessarily changing anything about the process and methodology of how the work is done. It's a brute force approach to compress the project schedule, which is fraught with many potential problems."

He then invokes John Wooden, the legendary UCLA basketball coach who won ten NCAA championships in twelve years without a losing season. Wooden's wisdom was precise: "Be quick, but don't hurry." Being quick requires discipline and training. Hurrying is a brute-force way to "get it done faster" and is likely to have a much lower success rate. This distinction is essential: agility, from an operational standpoint, is achieved through changing how work is done—improving processes, enabling teams, reducing waste, and responding to change intelligently. It is not achieved by simply working harder or faster without changing the process.

Why It Matters

This concept prevents a common organizational mistake: attempting to become "agile" by simply demanding that teams move faster, then being surprised when quality drops, people burn out, and projects fail. It also protects organizations from the snake oil of "speed for its own sake." It recognizes that true agility requires investment in process improvement, team capability, and organizational change—not just exhortation. The concept applies beyond software development to any domain where speed-without-discipline is a recurring temptation and trap. Understanding that how you achieve speed matters as much as the speed itself is what distinguishes agility from mere rush.