Waterfall vs Agile: Choosing The Right Fit


The wa­ter­fall method­ol­ogy is a lin­ear ap­proach to soft­ware de­vel­op­ment. Initially, the pro­ject re­quire­ments are com­pre­hen­sively scoped out. This is crit­i­cal in a wa­ter­fall pro­ject as the fi­nal soft­ware will re­flect the re­quire­ments out­lined at the be­gin­ning. Once com­pleted, the soft­ware will be de­signed, de­vel­oped, tested and de­ployed. Each of these is a dis­tinct stage in the process where the pre­vi­ous stage must be com­pleted be­fore the next can be­gin. This means a pro­jec­t’s time­frame is gen­er­ally longer when us­ing the wa­ter­fall method­ol­ogy but at the end of de­vel­op­ment you’re left with a pol­ished, fi­nal ver­sion of the soft­ware.

In con­trast, ag­ile is an it­er­a­tive ap­proach to soft­ware de­liv­ery that builds in­cre­men­tally from the start of the pro­ject. It em­pha­sises rapid de­liv­ery in com­plete func­tional com­po­nents. These are sep­a­rated into sprints and pri­ori­tised based on their im­por­tance. The fo­cus is on the end user. Through early and con­tin­u­ous de­liv­ery, ag­ile teams aim to in­clude the cus­tomer and end user in the process. For a more de­tailed analy­sis of the ag­ile method­ol­ogy check out this ar­ti­cle.

The best fit will de­pend on your pro­ject and per­sonal pref­er­ence. To en­sure you’re well in­formed, we’ve in­cluded the top risks ap­plic­a­ble to soft­ware pro­jects and the de­vel­op­ment ap­proach that may mit­i­gate that risk.


In an ag­ile pro­ject, both the cus­tomer and de­vel­oper face risks. The cus­tomer is likely work­ing off a time and ma­te­ri­als pric­ing model (to be dis­cussed be­low), mean­ing the price can fluc­tu­ate. The pro­jects time­frame is also un­cer­tain as re­quire­ments are sus­cep­ti­ble to change. As cus­tomer in­volve­ment is a pre­req­ui­site for ag­ile de­vel­op­ment, there is a high risk that the re­sponse time from the cus­tomer may be slow and im­pede time­frames. However the cus­tomer is able to de­crease the po­ten­tial for poor end user en­gage­ment as user ac­cep­tance tests, which will ei­ther val­i­date or mod­ify the pro­ject are con­ducted reg­u­larly. The de­vel­oper also car­ries risk. Due to the flex­i­bil­ity of an ag­ile pro­ject, it’s dif­fi­cult to ac­cu­rately al­lo­cate re­sources. Development teams may spend more or less time on a pro­ject than ini­tially an­tic­i­pated which may im­pact fu­ture pro­jects in the pipeline.

To dis­cover more about how we work with ag­ile, down­load our Way of Working for free be­low.

In a wa­ter­fall pro­ject, the risks faced by both par­ties dif­fer. Fixed pric­ing and time­frames help cre­ate cer­tainty for the cus­tomer. However de­vel­op­ers risk un­der­quot­ing a pro­ject. As men­tioned above, the cus­tomer is ca­pa­ble of con­duct­ing user ac­cep­tance tests and mod­i­fy­ing a pro­ject when adopt­ing the ag­ile method­ol­ogy. This is not the case for wa­ter­fall de­vel­op­ment. As a re­sult, cus­tomers risk poor end user en­gage­ment, or fu­ture costs adding/​mod­i­fy­ing fea­tures. The na­ture of the method­ol­ogy means that nei­ther party risks scope creep. There are also risks around the se­quence of processes. Because test­ing only oc­curs af­ter de­vel­op­ment is com­pleted, there is an added el­e­ment of risk. The test­ing phase is the first event for which tim­ing, stor­age, in­put/​out­put trans­fers are ex­pe­ri­enced as dis­tin­guished from analysed.


One of the great­est ad­van­tages of the wa­ter­fall ap­proach is that de­vel­op­ment teams and cus­tomers agree pre­cisely what will be de­liv­ered at an early stage. This re­moves the risk of scope creep and al­lows de­vel­op­ers to ac­cu­rately fore­cast the pro­ject com­ple­tion date. In ad­di­tion, a cus­tomer pres­ence is only needed at the be­gin­ning of the pro­ject (when scop­ing the re­quire­ments). The wa­ter­fall method­ol­ogy also al­lows for mea­sur­able progress. Because the en­tire pro­ject is scoped out, it’s eas­ier to de­ter­mine where you are in the pro­jec­t’s life­cy­cle. It re­moves the risk of a dis­jointed ap­pli­ca­tion as it adopts a wholis­tic ap­proach to de­vel­op­ment.

Unfortunately it also means pro­jects aren’t as flex­i­ble. A com­pre­hen­sive list of re­quire­ments are for­mu­lated at the be­gin­ning. Consequently it be­comes much more dif­fi­cult to al­ter or add fea­tures once the de­sign stage has be­gun. There is min­i­mal cus­tomer col­lab­o­ra­tion as the cus­tomer does not play an ac­tive role in de­vel­op­ment once the re­quire­ments back­log has been com­pleted. The fact the cus­tomer only re­ceives a fi­nal prod­uct lim­its the op­por­tu­nity to re­ceive user feed­back dur­ing de­vel­op­ment. However if you know what your end user wants, wa­ter­fall is of­ten an ef­fec­tive choice.


The pro­ject team spends a short pe­riod of time (a it­er­a­tion) build­ing a small part of the pro­ject to in­te­grate into the ap­pli­ca­tion. This al­lows the team and busi­ness owner to build, mea­sure and learn from it­er­a­tions. The cus­tomer has an early op­por­tu­nity to see com­pleted work and is able to make changes through­out de­vel­op­ment. However, this opens the door for scope creep. Between the scop­ing phase and the com­ple­tion of the de­vel­op­ment phase, cus­tomers will of­ten want to in­clude new fea­tures in the pro­ject. These fea­tures aren’t planned or as­signed to it­er­a­tions and are not in­cluded in cost­ing/​time es­ti­mates.

Agile al­lows de­vel­op­ers to pri­ori­tise cer­tain fea­tures, hence an MVP (minimum vi­able prod­uct) can be pro­duced quite quickly. The cus­tomer can then be­gin plan­ning fur­ther it­er­a­tions to im­prove on the MVP af­ter user ac­cep­tance test­ing (UAT) is com­pleted. The di­a­gram be­low is an overview of the soft­ware de­vel­op­ment process for an ag­ile pro­ject. The prod­uct back­log is com­pleted and sub­se­quently bro­ken down into it­er­a­tion back­log’s. Each it­er­a­tion is de­ployed to beta and de­vel­op­ment en­vi­ron­ments. Once the pro­jec­t’s tests pass, it can be re­leased to a pro­duc­tion en­vi­ron­ment.


A wa­ter­fall pro­ject is more lin­ear than the graphic above. Rather than in­clud­ing a feed­back loop where you it­er­ate to the next sprint, every­thing is com­pleted based on the prod­uct back­log and de­ployed to the test­ing en­vi­ron­ments be­fore it’s de­ployed to the pro­duc­tion en­vi­ron­ments.

Fixed Price Fixed Scope (Waterfall) Versus Flexible Scope or Flexible Time (Agile)

There are two com­monly used meth­ods for pric­ing a pro­ject. A de­vel­op­ment com­pany can ei­ther of­fer a fixed price or a vari­able price dic­tated by time and ma­te­ri­als. As men­tioned above, the wa­ter­fall method­ol­ogy lends it­self to fixed pric­ing. The model is ideal for small and medium level pro­jects with clear and well-de­fined re­quire­ments. With a fixed pric­ing strat­egy the cus­tomer knows ex­actly what the pro­ject will cost, al­low­ing them to ac­cu­rately al­lo­cate bud­get. This makes it ap­pear low-risk op­tion for the cus­tomer with well de­fined re­quire­ments. However, the risk around User Acceptance test­ing and un­known un­knowns e.g tech­ni­cal debts, de­ci­sions and shift­ing per­cep­tion means that the de­vel­oper has to fac­tor in this risk to the price on top of their es­ti­ma­tions. The pros and cons of the fixed price model are out­lined in the table be­low.


The time and ma­te­ri­als pric­ing model is most ben­e­fi­cial for cus­tomers that want a flex­i­ble and ag­ile pro­ject. The model al­lows soft­ware providers to adopt an ag­ile method­ol­ogy. At the be­gin­ning of the pro­ject, es­ti­mates are given based on how much the de­vel­oper be­lieves it may cost. However the fi­nal fig­ure is cal­cu­lated at the end of a pro­ject, and will re­flect the time spent in de­vel­op­ment and any ma­te­ri­als used. This is scary! However, there is a so­lu­tion. If the time is fixed and every­one agrees upon the fixed time the scope can be var­ied back to en­sure the most value is be­ing de­liv­ered within the timer pe­riod. This means the scope can ad­just per it­er­a­tion. New items can be added or re­moved.

Requirements can change fre­quently with­out the de­vel­op­ment com­pany at­tempt­ing to fore­cast these changes at the be­gin­ning of a pro­ject. The risks are low for a soft­ware provider un­der this model as their time is com­pen­sated so they aren’t mo­ti­vated to mul­ti­ply or in­flate es­ti­ma­tions. However, the cus­tomer has a greater de­gree of con­trol. By keep­ing the re­quire­ments rel­a­tively sim­i­lar to those scoped at the be­gin­ning of the pro­ject, the price won’t fluc­tu­ate too much from any es­ti­mates given. Keep in mind that if new re­quire­ments need to be added, then this can be done at the cus­tomers re­quest. WorkingMouse utilises the ag­ile scrum de­vel­op­ment method­ol­ogy. This en­ables for a back­log of re­quire­ments to be or­dered by pri­or­ity with time. This en­ables the cus­tomer to see and choose what is of value for the next it­er­a­tion. The im­age be­low rep­re­sents what a scrum back­log looks like. The items can be pri­ori­tised up and down. They also usu­ally have time es­ti­ma­tions if they where orig­i­nally es­ti­mated. This en­ables the prod­uct owner and team to de­cide value in mov­ing re­quire­ments from the back­log into the next it­er­a­tion.


Each method­ol­ogy has its own strengths and weak­nesses. Early on, WorkingMouse es­sen­tially op­er­ated as an ag­ile evan­ge­list. We be­lieved there was one right an­swer when it came to a de­vel­op­ment ap­proach and it was ag­ile. However we’ve grown since then. In do­ing so we’ve recog­nised that wa­ter­fall is a valid de­vel­op­ment ap­proach with its own ad­van­tages. We’ve al­lowed our part­ners to de­cide which method­ol­ogy they would like to use, pre­sent­ing the ad­van­tages and dis­ad­van­tages of each ap­proach.

If you’re strug­gling to de­cide, or have a ques­tion we’d love to lend our ex­per­tise. Contact us with your ques­tions.


Eban Escott

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book an con­sul­ta­tion