The  Agile  vs.  Waterfall  Debate  

Who  Is  Right?  
White  Paper  
   
Forrester  notes  the  ability  of  Agile  to  deliver  "improvements  in  time-­‐to-­‐benefits,  overall  quality  and  
efficiency,   team   morale,   the   relationship   between   IT   and   business   staff   and   responsiveness   to  
change".  
Over   the   past   few   years   many   companies   have   started   to   turn   to   agile   software   development   to  
replace   more   traditional   waterfall   software   development   methodologies   that   have   often   failed   to  
deliver.  
dŚĞ͞ĂŐŝůĞ͟ǀƐ.  ͞wĂƚĞƌĨĂůů͟ĚĞďĂƚĞŚĂƐĐĂƵƐĞĚŵƵĐŚdiscussion  in  the  software  development  arena.  
There  are  many  evangelists  for  each  approach  that  often  have  very  polarized  views.  
Exponents   of   the   waterfall   or   plan-­‐driven   approach   describe   how   the   step-­‐by-­‐step   approach   to  
gathering   requirements,   creating   complete   specifications,   performing   detailed   technical   designs,  
developing   code   and   then   testing   in   a   sequential,   waterfall   manner   will   lead   to   a   successful   high  
quality   solution.   They   will   often   describe   agile   software   development   as   a   hackers   paradise,   an  
approach  where  you  do  not  know  what  functionality  you  will  actually  get  until  it  is  too  late;  in  effect,  
they  will  often  describe  Agile  as  a  high  risk  proposition  without  any  realistic  level  of  control  where  
the  deliverables  are  uncertain.  
However,  exponents  of  agile  development  will  point  to  the  relatively  high  level  of  failure  in  waterfall  
or   plan-­‐driven   development   projects.   They   will   describe   how   it   is  very   hard   for   users   to   know   the  
detail  of  absolutely  everything  that  they  want  at  the  start;  how  all  projects  will  have  an  element  of  
change   in   them;   how   people   spend   lots   of   time   on   waterfall   projects   creating   documents   that  
quickly  become  out  of  date  and  unused.  In  summary  they  will  describe  a  waterfall  project  as  a  turgid  
affair,  where  it  takes  a  long  time  and  a  large  cost  to  implement  a  system  that  is  probably  not  what  
the   user   originally   envisaged   and   is   incapable   of   accommodating   change.   They   will   then   describe  
how  taking  an  agile  approach  will  ensure  high-­‐quality,  flexible  solutions  that  are  delivered  at  great  
speed  and  at  low  cost  where  changes  can  be  incorporated  with  no  problems.  
Is  either  of  these  two  polarized  positions  totally  accurate?  In  reality,  of  course  they  are  not.  
We   have   probably   all   seen   projects   where   the   analysis   phase   goes   on   forever   in   an   attempt   to  
capture   all   the   users   requirement   in   one   go.   In   turn,   users   often   believe   that   this   is   their   only  
opportunity  to  get  requirements  in  to  the  scope  of  the  project  so  they  try  and  cover  every  possible  
eventuality  that  can  conceivably  think  of  for  functionality  that  may   never  actually   be   needed.  This  
subsequently  leads  to  a  very  complex  design  and  a  very  hefty  development  phase  to  deliver  what  is  
promised   as   being   a   highly   flexible,   future-­‐proof   solution.   We   will   have   all   seen   examples   where  
these  highly  flexible,  future  proof  solutions  are  very  complex  to  use,  hard  to  change  and  costly  when  
compared   to   the   original   budget.   Often   these   systems   bear   very   little   resemblance   to   the   simple,  
powerful  system  that  was  originally  envisioned.  
So,   does   this   mean   that   Agile   is   the   one   true   solution   to   all   software   development   issues?   The  
answer   to   this   can   be   a   resounding   no.   In   the   above   section   we   have   described   an   example   of   a  
development  project  bogged  down  by  complex  analysis  with  noticeable  knock-­‐on  effects.  For  those  
of  us  who  have  been  in  the  software  development  industry  for  a  number  of  years,  we  will  have  all  
often  seen  system  built  without  the  right  level  of  analysis  where  the  end  result  has  simply  not  met  

2
the  needs  of  the  users.  We  have  all  seen  developers  who  can  cobble  together  a  system  very  quickly  
where  the  bug  list  seems  to  go  on  forever.  
The   summary   of   all   of   this   is   that   to   simply   say   that   an   agile   approach   will   work   and   a   waterfall  
ĂƉƉƌŽĂĐŚǁŽŶ͛ƚǁŽƌŬŽƌ  vice-­‐versa  is  just  not  true.  We  can  all  find  examples  of  success  and  failures.  
The  key  itself  is  to  recognize  the  strengths  and  weaknesses  of  an  approach  on  an  individual  project  
and  choose  the  right  approach  for  the  given  project.  
However,   we   should   also   recognize   that   there   is   a   considerable   amount   of   value   in   a   lot   of   the  
principles   that   an   agile   approach   brings   (we   cover   this   in   more   detail   later).   Indeed,   whilst   some  
Agile  evangelists  (or  indeed  some  Waterfall  evangelists)  might  not  want  to  admit  to  this,  it  is  clearly  
the   case   that   a   lot   of   the   principles   behind   an   agile   approach   have   come   from   the   experience   of  
successful  waterfall  projects.  
For  example,  one  of  the  key  principles  of  an  agile  approach  is  to  create  automated  tests  to  check  the  
functionality  of  the  code.  On  many  waterfall  projects,  we  have  all  experienced  problems  when  the  
lengthy,  large-­‐scale  testing  that  is  needed  identifies  a  number  of  bugs.  We  then  pass  the  results  back  
to  the  development  team  who  fix  them  and,  given  we  are  all  human,  introduce  a  few  more.  We  then  
go   through   another   lengthy   testing   phase   and   so   on.   Successful   waterfall   projects   often   create  
automated   unit   tests   so   that   we   can   quickly   and   repeatedly   check   that   code   works   and   that   we  
hĂǀĞŶ͛ƚďƌŽŬĞŶŝƚǁŚĞŶǁĞĐŚĂŶŐĞŝƚ͘  
Whilst   there   are   a   number   of   subtly   different  methodologies  that   fall   under  the   Agile   banner,   the  
Agile  Alliance  identified  four  key  principles  that  underpin  all  agile  projects.  It  is  perhaps  easy  to  look  
at  these  and  draw  the  conclusion  that  Agile  is  a  high  risk,  uncontrolled,  informal  methodology  but  
this   is   not   the   case.   Under   each   of   the   key   principles,   we   have   set   out   how   these   principles   are  
applied   on   successful   agile   projects   in   the   real   world.   We   go   into   this   in   more   detail   when   we  
describe  our  agile  approach.  
 

Individuals  and  interactions  over  processes  and  tools  

The   essence   of   this   principle   is   that   we   recognize   that   good   people   are   needed   to   build   good  
systems.  This  might  seem  obvious  but  it  can  be  the  case  (perhaps  more  so  in  a  waterfall  project)  that  
there  is  a  belief  that  good  process  makes  up  for  having  average  people  ʹ  experience  shows  that  this  
ŝƐŶ͛ƚƚŚĞ  case.  
This   key   agile   principle   also   stresses   the   value   of   interaction   over   process   and   tools.   Again,   it   is  
common  sense  that  a  successful  project  will  need  people  who  can  interact  with  each  other;  people  
who   can   explain   clearly   and   understand   the   needs   of   the   user.   Some   waterfall   exponents   will  
describe   how   documents   can   be   created   that   describe   what   is   needed   and   it   is   common   for   a  
developer   on   a   waterfall   project   to   have   to   work   only   with   written   documentation   and  
specifications,  rather  than  interacting  with  users.  
Our  belief  is  having  good  people  is  critical  to  the  success  of  a  project.  AT  DB  Consulting  we  have  over  
15   years   software   development   experience   and   have   a   very   strong,   proven,   experienced   and  
dedicated  group  of  technical  resources.  Typically,  the  developers  that  we  employ  on  an  agile  project  

3
will   have   in   excess   of   7   years   development   experience   and   are   normally   accredited   Microsoft  
designers   and   developers.   All   of   our   consultants   who   work   on   an   agile   project   have   strong  
communication   and   analysis   skills.   Whilst   it   is   sometimes   possible   for   developers   to   work   without  
having  much  interaction  with  the  key  users,  it  is  common  sense  that  a  greater  level  of  understanding  
will  be  obtained  if  the  developer  interacts  directly  with  the  user.  
However   (and   this   is   often   ignored   by   people   who   wish   to   disprove   the   viability   of   an   agile  
approach),   all   Agile   methodologies   (whether   they   be   SCRUM,   Test   Driven   Development,   XP   etc)  
make  use  of  processes  and  tools  to  help  ensure  the  success  of  a  project.  The  key  difference  between  
processes   on   a   waterfall   project   and   an   agile   project   is   that   the   processes   on   an   agile   project   are  
totally  geared  towards  helping  the  project  members  deliver  the  solution  ʹ  i.e.  to  help  good  people  
build  a  good  system.  On  a  waterfall  project  there  is  a  stronger  emphasis  on  using  processes  to  better  
manage  and  understand  the  status  of  a  project  ʹ  i.e.  not  all  of  the  processes  actual  help  the  team  
create  a  good  system.  
 

Working  software  over  comprehensive  documentation  

This  key  principle  states  a  fact  that  should  be  obvious  on  any  project,   that  the  working  software  is  
the  most  important  deliverable  (from  an  IT  development  perspective).  
In  waterfall  projects,  there  is  an  emphasis  on  creating  many  different  types  of  documentation  from  
requirements  specifications  to  technical  design  documents.  It  is  often  the  case  that  the  project  loses  
sight   of  the   fact   that  these   documents  should  really  be   only  an  interim   deliverable  on  the  road  to  
building  a  working  system.  
/ƚ͛ƐŝŵƉŽƌƚĂŶƚƚŽŶŽƚĞƚŚĂƚƚŚŝƐƉƌŝŶĐŝƉůĞŝŶĐůƵĚĞƐƚŚĞǁŽƌĚ͞ĐŽŵƉƌĞŚĞŶƐŝǀĞ͘͟^ŽŵĞĐƌŝtics  of  an  agile  
approach  will  say  that  documents  are  not  created;  this  is  not  the  case.  There  is  always  the  need  to  
create  the  right  level  of  documentation  for  the  circumstances  of  the  project.  
 

Customer  collaboration  over  contract  negotiation  

This   is   an   important   principle   that   is   often   misunderstood.   Critics   of   an   agile   approach   where   the  
development  team   is  made   up  of  external   developers   from   a  third   party  will  often  mistakenly   say  
that  adopting  this  principle  means  that  it  is  the  customer  who  takes  the  risk  on  a  project.  This  does  
not  need  to  be  the  case.  
The   most   important   fact   to   take   from   this   principle   is   that   a   strong   level   of   collaboration   with   a  
customer  is  very  important  on  a  project.  If  everyone  is  working  towards  the  same  goal,  the  chances  
of  success  are  far  higher.  
However,   we   recognize   that   there   are   contract   considerations   that   must   come   into   play.   Some  
software  development  companies  have  tried  to  use  Agile  as  an  attempt  to  engage  customers  on  a  
time   &   materials   project   with   no   defined   deliverables   ʹ   i.e.   to   put   the   risk   on   the   customer.   We  
simply  do  not  do  this  as  we  recognize  that  this  is  commercially  untenable  for  many  customers.  
   

4
  

Responding  to  change  over  following  a  plan  

It   is   a   fact   of   life   that   most   software   development   projects   will   have   an   element   of   changing  
requirements.   In   Waterfall   projects   changing   requirements   are   often   seen   as   something   to   be  
avoided  at  all  costs.  This  can  lead  to  a  circumstance  where  the  initial  analysis  and  design  becomes  
bogged  down  as  users  and  the  project  team  attempt  to  cover  all  scenarios  in  huge  detail.  
The   emphasis   on   an   agile   project   is   to   identify   and   establish   the   key   requirements   first   and   then  
focus  on  delivering  the  known  requirements  quickly  and  robustly.  Whilst  there  may  not  be  a  large  
scale  Gantt  chart  containing  hundreds  of  tasks  in  a  plan,  a  good  agile  project  will  have  clear  visibility  
of   what   the   requirements   are,   their   relative   priority,   effort   to   implement   and   target   release   date.  
Indeed   we   have   found   that,   because   an   agile   project   works   in   short   iterations   (usually   1   month  
cycles)   it   is   often   the   case   that   there   is   more   certainty   when   a   key   piece   of   functionality   will   be  
delivered  in  an  agile  project  than  a  waterfall  project  with  much  less  frequent  code  releases.  
 

                     

 
  DB  Consulting  
Thames  Court  
1  Victoria  Street  
Windsor  
SL4  1YB  
 
T:  +44  (0)1753  626625  
E:  nhill@dbgroup.co.uk  
 
www.dbconsulting.co.uk  
5