This article is sent to you compliments of Dr Robert G.

Cooper
robertcoper@cogeco.ca
www.bobcooper.ca

Please respect the copyright laws (do not copy or distribute, or post on your webpage)

Stage-­‐Gate  and  Agile  Development:  Debunking  the  Myths  

R.G. Cooper

Progressive companies are combining three best of Agile and Stage-Gate® both for IT and physical product
development.

Summary: Many IT developers use the Agile method – a series of rapidly-executed sprints and scrums – as
outlined in the Agile Manifesto. But is Agile in conflict with Stage-Gate? Not at all! Progressive firms are
finding that Agile methods can be used within Stage-Gate, especially in the Development and Testing stages of
the project. And now some leading physical product developers are taking the best concepts from Agile and
incorporating these into their Stage-Gate system to get new physical products to market faster. Agile-Stage-
Gate combined with spiral development and dedicated teams may be the new best way to get the product right
and accelerate physical product development.

   
 Stage-­‐Gate  and  Agile  Development:  Debunking  the  Myths  
R.G.  Cooper  (©  2015)  
 
Some  months  ago,  I  facilitated  a  heated  meeting  between  software  and  hardware  developers  in  a  large  U .S.  firm,  where  
the   question   was:   for   software   development,   whether   Agile   development   and   Stage-­‐Gate   can   or   should   be   used  
together  (are  they  complementary?)  or  instead  of  each  other  (are  they  mutually  exclusive?).  This  firm  uses  Stage-­‐Gate  
very   successfully   for   the   development   of   its   physical   products;   but   some   software   developers   are   arguing   that   Agile,   not  
Stage-­‐Gate,   should   be   used   for   software   developments.   During   a   recent   trip   to   Europe,   the   same   question   arose   in   a  
major  telecommunications  firm,  but  they  seemed  to  have  resolved  the  issue,  and  in  a  positive  way.    
 
A   second   and   related   question   concerns   whether   hardware   developers   can   or   should   employ   aspects   of   Agile  
development…  for  example,  the  notion  of  sprints  and  scrums.  Both  questions  are  particularly  relevant  when  the  firm’s  
development  efforts  include  both  hardware  and  software,  and  where  the  two  must  be  integrated.  
 
The  Role  of  Agile  Within  Stage-­‐Gate  for  Software  Development  
 
Stage-­‐Gate  and  Agile  are  not  substitutes  for  each  other.  Rather  Agile  is  a  useful  micro-­‐planning  or  project  management  
method  that  can  be  used  within  Stage-­‐Gate  to  accelerate  certain  stages.  
 
Stage-­‐Gate   has   long  
been   popular   as   a  
method   for   driving   new  
products   to   market,   but  
it   is   not   a   project  
management   or   micro-­‐
planning   model   per   se.  
Rather   Stage-­‐Gate   is   a  
comprehensive   and  
holistic   idea-­‐to-­‐launch  
system   and   a   macro-­‐
planning   process   –   see  
Figure   1.   It   is   cross-­‐
functional   (i.e.,   involves  
technical   product  
developers,   but   also  
Marketing,   Sales   and  
Operations).   It   is   also   an  
investment   decision  
model   (or   a   Go/Kill  
decision   system),   where  
the  gates  pose  two  vital  questions:  Are  you  doing  the  right  project?  And  are  you  doing  the  project  right?    
 
By   contrast,   Agile   development   is   designed   specifically   for   product   developers   (technical   people)   as   a   way   to   rapidly  
develop  the  working  software  (see  box  insert  below).  In  practice,  the  Development  Stage  consists  of  a  number  of  sprints,  
where   each   sprint   or   iteration   produces   a   working   product   (executable   IT   code   or   software   that   works)   that   can   be  
demonstrated   to   stakeholders   (customers,   for   example).   An   iteration   may   not   add   enough   functionality   to   warrant   a  
market   release,   but   the   goal   is   to   have   a   potentially   Agile software development is a group of software
available   release   at   the   end   of   each   iteration.   development methodologies based on iterative and
Multiple   iterations   are   usually   required   to   release   a  
incremental development, where requirements and
product   or   new   features;   a   sprint   typically   lasts   2-­‐5  
solutions evolve through collaboration between self-
weeks.  
organizing, cross-functional teams. It promotes adaptive
 
planning, evolutionary development and delivery, a time-
Thus   Agile   is   a   micro-­‐planning   or   project  
boxed iterative approach, and encourages rapid and
management  tool  designed  for  writing  software  code  
flexible response to change. It is a conceptual framework
and   get   to   a   working   end-­‐product   quickly.   Agile   is  
that promotes foreseen interactions throughout the
best   used   during   the   Development   and   Testing  
development cycle. The Agile Manifesto introduced the
(alpha   and   beta)   Stages   of   a   new-­‐product   project   –  
term in 2001.
that   is,   for   two   stages  (Stages   3   and   4)   out   of   the   five  
or  six  stages  of  the  Stage-­‐Gate  model  in  Figure  1  –  but  not  for  the  entire  project  from  end-­‐to-­‐end.  And  it  is  principally  
used   by   the   technical,   IT   or   engineering   people  
developing  the  software  code  –  for  example,  it  would   Table  1:  Key  Characteristics  of  Stage-­‐Gate  and  Agile
not   make   much   sense   to   have   the   Marketing   or   Characteristic Stage-­‐G ate Agile

Operations   facets   of   new   product   projects   Type  of  model Macro-­‐p lanning Micro-­‐planning,  p roject  
management
undertaken   using   an   Agile   approach.   Table   1  
Scope Idea  to  launch,  end-­‐to-­‐ Development  &  Testing  
summarizes   some   of   the   differences   between   Agile  
end stages  only
and  Stage-­‐Gate.  
Organizational  b readth Cross  functional:   Technical  (software  code  
  Development  (RD&E  or   writers,  engineers,  IT  
Maelstrom   and   Runeson   studied   two   large   high-­‐ technical),  M arketing,   people)
Sales,  Operations
technology   firms,   in   particular   case   studies  
End  point A  launched  new  p roduct   Developed  and  tested  
integrating  Stage-­‐Gate  and   Agile  development  for  IT   in  the  market working  software  
projects.1   They   note   that   “….software   development   product
projects  are  not  isolated  activities.  They  usually  exist   Decision   m odel Investment   m odel:   Largely  tactical:  the  
Go/Kill actions  n eeded  for  the  
as   sub-­‐projects   in   an   environment   composed   of   Involves  a  senior   next  sprint  
hardware   development,   marketing,   production   governance  group
planning   etc.   which   all   must   be   managed   and  
coordinated   concurrently.”   The   authors   go   on:   “   [stage-­‐gate   methods]   gives   support   not   only   for   the   communication  
within  the  project,  but  also  for  decision  makers  sponsoring  the  project  or  acquiring  the  outcome  of  the  project.”  
 
Boehm  and  Turner  discuss  the  contrasts  between  plan-­‐driven  software  development  and  Agile  approaches  at  length  in  
their  book.2  Gate  models  in  general  are  a  form  of  “plan  driven  models”.  One  of  the  conclusions  drawn  in  the  book  is  that  
future   projects   will   need   both   agility   and   discipline,   which   can   be   implemented   by   containing   the   Agile   development  
methodology  within  the  gate  model.  

It’s  not  a  matter  of  either  Stage-­‐Gate  or  Agile.  Agile  is  a  very  useful  micro-­‐planning  or  project  management  tool    and  
can  be  used  e ffectively  within  the  Development  and  Testing  stages  of  Stage-­‐Gate.  But  a  new  product  p roject  is  much  
more  than  a  few  stages  in  Figure  1  and  involves  more  than  just  technical  people.  
 
What  about  Applying  Agile  to  Hardware  (or  Physical  Product)  Development  
 
With  Agile  and  software  development,  each  sprint  or  iteration  produces  a  working  product  (executable  software)  that  
can  be  demonstrated  to  stakeholders  (customers),  as  noted  above.  Furthermore  the  working  product  at  the  end  of  each  
sprint  is  potentially  releasable.  When  contrasted  to  hardware  development,  the  difference  is  that  software  development  
–  lines  of  code  -­‐-­‐  is  infinitely  divisible;  hardware  is  not  usually  not  divisible  (i.e.,  you  cannot  build  part  of  the  product  that  
actually  works  –  thus  it  is  usually  not  possible  to  have  anything  that  actually  functions  developed  within  a  few  weeks.  For  
example  if  your  product  is  beer  or  even  a  machine,  you  cannot  build  “part  of  the  beer”  or  “part  of  the  machine”  and  
demonstrate  it  working!).    
 
Nonetheless,   in   next   generation   versions   of   Stage-­‐Gate   designed   for   developing   physical   projects   (i.e.   hardware),  
starting  this  current  century,  we  began  to  build  in  spirals  which  are  somewhat  like  the  sprints3,4.  Spirals  were  introduced  
as  a  way  to  make  the  traditional  1990s  gating  model   more  adaptive  and  more  responsive  to  fluid  market  conditions  and  
changing  product  requirements  in  order  to  get  the  product  right.    

Physical  product  developers:  If  you  face  a  dynamic,  fluid  market  with  changing  needs  and  fluid  product  requirements,  
be  sure  to  employ  spiral  development  –  a  series  of  build-­‐test-­‐feedback-­‐and-­‐revise  iterations  –  with  each  iteration  
revealing  a  progressively  more-­‐complete  version  of  the  product.  
 
Here   an   iteration   (between   spirals)   does   not   build   a   working   product,   but   a   product   version   somewhere   between   a  
“virtual   product”   through   to   a   “ready-­‐to-­‐trial   prototype”.   Unlike   software,   each   product   version   will   not   be   a   working  
product  (until  the  end  of  the  development  stage),  but  will  be  something  to  show  the  customer  to  seek  feedback.  These  
product   versions   can   be   computer   generated   3D   drawings,   virtual   prototypes,   crude   models,   working   models,  
‘protocepts’,  rapid  prototypes,  or  early  prototypes;  i.e.  usually  something  physical  that  the  customer  can  respond  to  –  
see  Figure  15.  
 
The   benefits   of   spiral   development   are   many.   First,   it   gets   something   in   front   of   customers   early,   often   and   cheaply.  
Simply   stated,   customers   don’t   know   what   they’re   looking   for   until   they   see   it   (especially   in   the   case   of   more   innovative  
products).   So   do   it:   show   them   something   they   can   see,   and   do   it   often,   all   the   way   through   the   project,   beginning   even  
before   Development   commences.   Next,   by   building   something   physical   to   show   stakeholders,   a   solution   to   technical  
issues   and   even   early   “proof   of   concept”   is   the   often   result.   Next,   management   gets   a   chance   to   see   something   and  
becomes  more  comfortable  with  the  project  (often  management  is  the  impediment  to  moving  forward,  especially  in  the  
case  of  a  more  innovative  project  with  its  inherent  risks).  Finally,  one  gets  the  product  right:  If  the  customer  does  not  
see   something   they   like,   then   vital   changes   and   modifications   in   the   product’s   design   can   be   made,   early   in   the  
Development  stage  when  the  cost  of  change  is  lower  –  much  like  a  strategic  pivot  in  the  Lean  Start-­‐Up  method.  Thus  the  
system  is  more  adaptive.  
 
A  second  change  to  the  traditional  Stage-­‐Gate  system  goes  further  than  introducing  spirals:  yes  keep  spirals,  but  add  the  
concept  of  rapid  and  repetitive  sprints  into  the  process.  For  example,  break  the  Development  and  Testing  stages  into  a  
series  of  two-­‐to-­‐four  week  sprints,  with  each  sprint  yielding  a  physical  result.    
 
An  example:    
One  large  US  manufacuteurer  of  electronic  devices  for  homes  has  increasingly  moved  into  the  world  of  remote  control  
devices   –   for   example,   to   control   the   thermostat,  lighting   and   even   the   front   door   lock.   Thus,   an   ever-­‐larger   percentage  
of  each  new  product  project  entails  software  or  IT  development.  To  no  one’s  surprise,  the  invariable  conflict  been  the  
hardware  and  software  developers  arose  –  Stage-­‐Gate  or  Agile?  
 
The   VP   Engineer   led   an   initiative   to   solve   the   problem,   and   in   doing   so,   improved   development   efforts   considerably  
across   all   groups   and   all   project   types.   He   introduce   the   concept   of   “Agile   within   Stage-­‐Gate”,   whereby   the   firm   uses  
Agile  sprints  and  scrums  for  both  physical  and  IT  development.  Agile  is  employed  in  particular  in  the  Development  and  
Testing   stages   of   Stage-­‐Gate   (Stages   3   &   4   in   Figure   1).   There   is   a   “scrum   master”   in   place,   and   daily   scrums   are  
employed,  about  20  minutes  in  length;  the  firm  also  builds  in  design  reviews  into  some  scrums  (and  even  brings  in  peers  
for  a  peer  review  and  also  outsiders).  
                                                                                                                                                                                                                                                                                                         
Sprints   are   about   two   weeks   in   length.   For   this   firms   remote   control   physical   products,   it   is   usually   not   possible   to  
produce  a  “potentially  releasable  product”  every  two  weeks,  but  the  project  team  must  show  something  physical,  the  
result   of   a   completed   tasks   in   that   sprint   (and   not   just   a   PPT   show!).   The   result   at   the   end   of   a   sprint   could   be,   for  
example,  a  set  of  completed  design  drawings,  or  a  rapid  prototype,  or  an  early  working  model  of  the  product.    
 
Project  teams  in  this  firm’s  system  have  dedicated  team  members  for  each  project.  Given  that  dedicated  teams  are  not  
feasible   for   every   project,   the   firm   only   uses   this   Agile-­‐Stage-­‐Gate   approach   for   the   larger,   major   revenue   generator  
projects  –  about  20%  of  projects  in  their  development  pipeline.    
 
The  approach  is  still  in  the  early  days,  and  is  working  well.  The  only  problem:  Project  leaders  and  teams  lose  sight  of  the  
ultimate   goal,   because   they’re   so   focused   on   the   next   two   weeks!   So   the   senior   people   must   meet   with   team  
periodically  (more  frequently  than  at  gates)  and  ensure  that  the  longer  term  view  is  also  considered.  
 
 
Note  that  one  positive  requirement  of  this  Agile-­‐Stage-­‐Gate  approach  is  that  project  teams  be  100%  dedicated,  as  in  the  
IT   Agile   method.   This   one   step   alone   increases   speed   quite   dramatically   (most   traditional   project   teams   are   woefully  
under-­‐resourced,   with   team   members   working   on   too   many   different   projects   or   tasks,   the   result   being   that   the   project  
moves   painfully   slowly).   By   solving   the   resourcing   problem,   this   Agile-­‐Stage-­‐Gate   with   its   “dedicated   team   approach”  
helps  drive  product  to  market  much  more  quickly.    
 
Bottom   line:   For   physical   product   developers,   sprints   can   be   employed   for   maximum   speed,   consistent   with   the   IT   Agile  
model.   But   sprints   are   usually   restricted   to   the   Development   and   Testing   stages.   However,   the   result   at   the   end   of   each  
sprint  may  have  to  be  redefined  somewhat  to  include  “something  physical,  the  result  of  a  completed  task”.  Additionally,  
spirals   –   a   series   of   build-­‐test-­‐feedback-­‐and   revise   iterations   –   are   highly   recommended   to   make   the   system   more  
adaptive;  these  spirals  fit  well  into  the  Agile  sprinting  concept,  whereby  at  the  completion  of  some  sprints,  a  version  of  
the  product  can  be  demonstrated  to  stakeholders  (customers  and  management).  Finally  dedicated  teams  are  a  must  for  
this  system  to  work,  and  help  accelerate  the  project  even  more.  

1
D.   Karlstrom   &   P.   Runeson,   “Integrating   Agile   software   development   into   stage-­‐gate   managed   product   development,”   Empir  
Software  Eng  (2006)  11:  203–225.  
2
 B.  Boehm  &  R.  Turner.    Balancing  Agility  and  Discipline.  Addison  Wesley  (2004).  
3
  R.G.   Cooper   and   S.J.   Edgett,   Lean,   Rapid   and   Profitable   New   Product   Development,   Product   Development   Institute,   www.stage-­‐
gate.com  (2005).        
4 th
  R.G.   Cooper,   Winning   at   New   Products:   Creating   Value   Through   Innovation,   4   edition.   New   York,   NY:   Basic   Books   (division   of  
Perseus  Books),  2011.  
5
 Cooper,  Robert  G.,  “What’s  next?  After  Stage-­‐Gate,”  Research-­‐Technology  Management,  Vol  157,  No.  1,  Jan-­‐Feb  2014,  pp  20-­‐31.  
See  page  21.