Computerworld -
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% of the time, whereas agile-based projects had a success rate of 42%.
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.
To continue reading, register here to become an Insider
It's FREE to join
Computerworld - 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% of the time, whereas agile-based projects had a success rate of 42%.
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.
In my experience, companies that have not been successful using Scrum have merely believed that they were following Scrum's project parameters, but truly weren't. The definitions of "done" and "ownership" are crucial in Scrum. If a project team defines "done" in a sprint to mean stopping at "code complete," then the team will establish the defeatist rhythm of postponing testing to the following sprint; in effect, they have fallen into waterfall. What Scrum requires is a team attitude of fiercely owning the successful outcome of each sprint. The idea of "done" in Scrum means designed, coded and tested within a sprint -- the whole package, not a partial one -- and potentially shipped upon review. "Done" means commitment with attainment through ownership.
You are previewing premium content. 
Free Insider Guide