Agile Methodology Is Making “Scope Creep” Obsolete

Project managers often list scope creep as one of their biggest headaches. But is documenting all the requirements of a solution before work ever commences truly reasonable? Perhaps what we refer to as scope creep is merely scope refining or scope development, and real issue lies with our own project management methods.

Let’s say that you need to replace your car’s starter motor. After hours of digging into the engine block to remove other components and just access this piece, the mechanic tells you that you also need a new solenoid. Declining to replace the solenoid would be foolish. It would mean another breakdown in the near future and a repeat all of the preliminary labor. So you add the new solenoid to the scope. In a project sense this represents scope creep (plus you will finish over your original budget and with a delayed schedule.) But was it the wise choice? Undeniably.

Traditional project management has long been rooted in “waterfall” development methodogy, a linear, structured approach. This method assumes that almost all requirements are locked down before a line of code is written. Progress is marked more by documents and artifacts such as a DDD (Detailed Design Document) than working code. But this approach can be inflexible and unrealistic when it comes to the demands of 21st century software development projects.

The answer in recent years has been Agile development methods such as Scrum and Extreme Programming. These methods aim at handing over the highest valued functional code elements as soon as possible, and continually improving these elements with each new iterative cycle (AKA “timebox” or “sprint”.) The iterations, which may be only a couple of weeks long, can encapsulate all of the steps of a regular development lifecycle (planning, analysis, design, coding, testing.) In an Agile world the highest development risks are frontloaded, and priorities are reassessed after each turnover.

Agile methods are naturally less bureaucratic, embedding only the minimum processes and controls necessary to manage the effort. Visa visionary Dee Hock once noted that “simple, clear purpose and principles give rise to complex, intelligent behavior…. complex rules and regulations give rise to simple, stupid behavior;” an Agile culture exemplifies this spirit. In this new world, the bywords are collaboration and rapid adaptability. Customer-developer interaction (a big taboo in the tightly controlled waterfall world) is encouraged, delivery of working code is emphasized over technical documents, and even 11th hour changes to requirements are par for the course.

Unsurprisingly, not all organizations have welcomed Agile methods with open arms. Some have characterized it as “cowboy coding” and are reluctant to deviate from their own highly codified and disciplined methodologies. But the stereotype that Agile equates to a lack of discipline or planning are beginning to fade. As current economic circumstances force companies to reassess the business value of complex and burdensome project management methods, more organizations are turning to Scrum, XP or Agile UP. A track record of success stretching back over a decade helps to convince the doubters.

IT projects that have fully fleshed out requirements up front are a rare exception, but too many organizations still run projects based on this premise. Agile methods simply recognize the reality that customers can change their minds. Concepts such as “scope creep” or “requirements churn,” the bane of the waterfall world, no longer have any meaning in this new context. And when working software is the primary measure of progress, what’s not to like?