<!––>Have agile methods won the ‘agile vs. waterfall’ debate? It certainly seems so. Confess to using waterfall and you risk hearing, “The ‘80s called and they want their methodology back.”

Over the years, Quintiq has developed its own approach – one that combines the best of agile and waterfall. This hybrid approach has enabled us to build a reputation for delivering projects on time and within budget, while remaining responsive to requests for changes and enhancements.

Here’s my take on combining agile and waterfall at each stage of an IT project.

Analysis phase: Create a detailed solution document

The scrum approach of creating high-level ‘to do’s’ and selecting the most important ones for a sprint can result in rework when items are analyzed in greater detail in subsequent sprints. To avoid this, apply the waterfall approach and create a detailed solution document before beginning the first sprint.

Build phase: Categorize items

Scrum often involves building certain areas thoroughly while leaving other functions to later sprints. Leaving an area undone can lead to an unworkable system, and this is particularly true with APS and supply chain applications.

To create a working system right from the beginning, divide the items you need to build into three categories: basic items, extensions, and refinements. Build the basic items first and start testing the system. Extensions and nice-to-have refinements can be added later.

Test phase: Ensure flexibility

Many an overrun in a waterfall-style project can be traced to requests for big changes during the test phase. Here agile comes to the rescue with its pragmatic acknowledgement of an obvious fact: It’s impossible to capture all the requirements of an IT implementation on paper. There will always be elements that the solution provider misunderstood, that the customer forgot to mention, or that simply didn’t crop up until key users started using the system.

Anticipate the need to make changes to the original design by incorporating agile development methods such as daily builds, careful issue management, and a modular approach that enables changes to be made without affecting other parts of the system.

Stabilization phase: Fix issues swiftly

Use this short phase to run the new system in parallel with the existing system. If showstoppers are encountered, apply agile methods from the test phase to fix issues swiftly.

And finally, keep things simple by focusing on business value

Agile methods are rightly valued for their no-frills approach. Solutions are built incrementally and features are only added if they provide real business value. This focus on business value ties in well with the agile-and-waterfall approach Quintiq favors.

To recap:

(i)   Limit scope to must-haves

(ii)  Go through the various phases from analyze to stabilize

(iii) Implement enhancements after the system is live

Agile, waterfall or both? What’s your view?