SCRUM or agile development was originally designed for “typical” software development. The goal of any software company is to release high-quality software to market as soon as possible.

In my extensive experience in software product management, I can tell you that in this type of “typical” software development environment:

• Scope is often not clearly defined and changes frequently. This is because there are more “unknowns” than in most corporate IT projects.

• Rather than tracking the budget closely (as is often the case in corporate IT projects), software companies will spend as many resources as they need to, to release the software to market as soon as possible.

SCRUM works well in this scenario because it enables the software company to be flexible with the project scope by defining a prioritised list of features (called the product backlog). The developers commit to a set of features they will complete within a time period of less than 30 days, which is called a sprint.

At the end of each sprint they must produce “demonstrate-able”, “release-able” software. After just a few sprints, the software is used in sales demonstrations and if sales succeed, the product can be released to market early with only the highest priority features.

What if the project is not “typical” software development? What if it is a change to an existing system and it has a strict deadline, scope and tight budget — can your project leverage the SCRUM methodology?

Previously, for this type of corporate IT project, I would fall back on the traditional “waterfall approach” to development; meaning the project manager would create a detailed plan up-front outlining estimates for design, development and testing.

This approach is called “waterfall” because each phase is reliant upon the completion of the previous phase before it can commence (i.e. design before development before testing). A lot of time is spent up-front analysing the solution before any development starts.

Waterfall’s primary shortcoming is that issues do arise, like it or not. As a result, the analysis phase includes wasted effort, the development phase takes longer than planned, and the testing phase must be shortened. Because a “release-able” solution is only produced at the end of the project, too frequently, the project runs beyond the deadline!

Due to the nature of this methodology, the waterfall approach can frequently produce late or poor-quality solutions.