We would all like to complete our projects on time, on budget and on scope. Agile software development frameworks have been embraced by many pursuing those goals, and for good reason. In its 2011 CHAOS Manifesto report surveying the success of software projects between 2002 and 2010, the Standish Group found that projects based on the traditional waterfall methodology succeeded 14 percent of the time, whereas agile-based projects had a success rate of 42 percent.
I am one of those project managers who have found that agile methods fulfill their promise. Specifically, I have had great success with Scrum, a 25-year-old, agile, iterative development framework that has gained most of its industry adoption in the past decade. With Scrum, you think differently, you collaborate differently, you perform differently -- and you succeed differently. Is Scrum a magic bullet for all problems? Of course not. But Scrum is a focused, value-based option, one that could add insightful transparency, periodic inspection and incremental adaptation to your software projects.
Where projects fail
Waterfall projects often fail due to a lack of inspection, adaptation, and communication. In serial fashion, software products get spec'd, designed, coded and tested. Usually, the team doesn't show the product to the stakeholders until near the end of the project timeline -- a terrible time to learn that they made the wrong product, or that it doesn't work as expected, or that there are some new features that need to be added. Inevitably, more time is needed, and the project ends up late and over budget.
With Scrum, the work is divided up into iterations, or "sprints," that are time-boxed. The team focuses on those features that provide the highest business value, and stakeholders can inspect the product after each sprint, giving feedback to the team when it's really needed. The input is prioritized, and the product evolves organically.