Waterfall Methodology Shortcomings: The Rise Of Agile Methodology

The high cost of changing requirements and software defects late in the life-cycle of a project has been one the driving forces behind the rise of Agile methodologies.

These methodologies attempt to address what are perceived as the main traditional

Waterfall methodology shortcomings. In Waterfall, all steps are sequential and rarely

(or sometimes briefly) overlapping. Small projects are not usually adversely affected by this, However, due to larger projects usually having more significant time-lines, this often leads to the discovery that requirements have either been misunderstood or changed. Additionally pieces of functionality can be found to be defective. These discoveries, especially when late in the project’s life-cycle, are commonly

As it can be inferred from the above passages, there are some major players in

FDD. Coad et al. (1999) state the most significant are the chief programmers, which are in charge of leading the DF and BF, and have a major role in the other steps as well, and the class owners, which are actually doing the coding. Additional roles are the architect, and domain experts. Furthermore, as clients use features rather than classesCoad et al. (1999), feature teams play a crucial role in the methodology implementation.

Moreover, FDD promises improved metrics for status tracking. This is achieved by assigning sequential milestones to each of the steps (Joshi, Agarwal, & Goel, n.d.).

Coad et al. (1999) suggest a percentage of overall time for each step therefore allowing the extrapolation of project progress depending on the completed step. For example the propose that the 2 week iteration of DF and BF should amount to about 77% with DF and BF being 44% and 56% respectively. Therefore, it can be inferred that an iteration in the DF phase and just beginning the Inspect the Design sub-phase

(about 3%) is about 41% complete.

Analysis

Some practitioners believe it to superior to other agile methodologies in

Tan, Tan, and Teo (2010) believe FDD strikes a balance between the programming and the management aspect whereas other methodologies emphasize one or the other.

However, Ismail et al. (2015) compared SCRUM to FDD and found that the former required less team members and was more responsive to changes mid development. FDD can produce quality results but is better suited for larger teams, larger projects, with heavy customer and domain expert involvement (Ismail et al.,

2015). A comparison of SCRUM and FDD by Umbreen, Abbas, and Shaheed (2015) paint FDD at a disadvantage because, although producing high quality, it lacks risk analysis, has unclear cost estimations, and only provides an estimate of delivery time.

Umbreen et al. (2015) also points out that SCRUM delivers portion of functionality sooner which lead to increased customer satisfaction.

As some of these reports show contrasting results some authors have proposed that hybridizing FDD with other agile methodologies (e.g. SCRUM or XP) may sinergistically positively enhance the results (Tan et al., 2010; Tirumala, Shahid, &

Anjan, 2016)