Scope Creep – Love it or Leave it
February 4, 2013
Countless studies have been performed that identify scope creep as the number one reason why so many software development projects fail.
Prior to 1990 planning the scope of an entire project from analysis to implementation worked because the pace of change was much slower than it is today. In most cases teams had time to analyze, design, code, test, and deploy the product before the customer would change their mind. A change of a requirement after design begins meant scope creep. Scope creep usually meant an extension of the project timeline.
With the introduction of the PC, email, the web, and mobile devices the speed of communication escalated immensely and in turn this increased the speed at which information was obtained. The increased speed of information is the primary driver of “the speed of change”. Traditional waterfall project management approaches can not accommodate this new speed of change.
Technological advances over the past couple decades have increased a technical team’s efficiency and ability to deliver new products to the marketplace. Software developers now have OO programming languages and sophisticated desktop software which help developers design and build products faster. Stakeholders assumed this meant that the delivery of products should keep pace with the speed of change, but this is rarely the case.
The combination of the speed of change and a technical team’s ability to develop more efficiently didn’t equal faster delivery of value to the marketplace. The combination doesn’t deliver faster value to the marketplace because the negative impact that change has on traditional approaches to scope definition and planning. The philosophy that change is bad must be abolished. The speed of change must be embraced in order to compete in today’s marketplace.
In order to embrace change, a new approach is required to take advantage of the technological advancements that created the increased pace of change. An approach is needed that gives teams the flexibility to react to change.
The ability to adequately respond to change requires agile work disciplines and practices. “For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people’s personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal (Extreme Programming Explained, p. 27).”
Nonetheless, a team needs some sense of what it will do in the near future. The subject of my next blog will be about how to use the “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable.
My Agile Motto: Work in smaller chunks. Deliver business value often. Collaborate with the software owner/sponsor very closely throughout the process. Accept that change is inevitable in software development – accommodate and encourage it. Ensure that everyone on the development team trained and mandated to maximize business value on behalf of the software sponsor/owner. Everyone on the team is both developer and analyst.