Methodology as Tool, Not Dogma

Definition

A common failure pattern is to adopt a methodology—whether traditional (Waterfall) or agile (Scrum)—and treat it as a fixed, prescriptive template that every project must follow. The opposite approach is to view methodology as a toolkit of principles and practices that should be deliberately customized to fit the specific business environment, project complexity, and risk profile. This requires practitioners to understand the principles behind a methodology deeply enough to apply them intelligently, rather than mechanically following the rules.

In the Book

Cobb's personal experience sets the stage: In the 1990s, he was charged with getting an acquired, multi-site company to adopt a single, uniform Waterfall methodology. He discovered that "forcing people to adopt one methodology like the Waterfall wasn't going to work—it was overkill, it had way too much overhead for many of the company's projects." Instead, he enabled project managers to select from multiple lifecycle models and tailor them as needed. He reflects: "No methodology (agile or non-agile) should ever be taken as absolute dogma. Project managers must have some ability to apply it intelligently and make changes as needed."

He contrasts "cooks" who follow recipes by the book with "chefs" who customize and innovate. The book argues that the future requires project managers to become "chefs" who can "prepare a much broader range of dishes and go beyond preparing standard recipes by the book to create highly customized and innovative recipes tailored to fit a particular business and project environment."

Sapient exemplifies this principle. Rather than adopting Scrum or XP in isolation, they recognized that "each discrete methodology, when taken in isolation, leave[s] something to be desired from an enterprise delivery perspective" and instead "creatively combined" elements of XP, Lean Development, Agile Modeling, and Scrum-based practices, scaled and customized to fit their large, complex projects and fixed-price contracting model.

Why It Matters

This concept is essential because it converts methodology adoption from a binary compliance exercise (do we use this methodology or not?) into a strategic design exercise (what combination of practices actually serves our context?). It legitimizes the hybrid approaches that many organizations are already attempting but framing as "failures to go pure agile." It also prevents the common trap of implementing a methodology mechanically while ignoring the underlying principles—which leads to superficial adoption. Understanding principles—not memorizing procedures—is what enables intelligent customization and is what transfers across contexts.