One of the challenges with traditional software development was to understand and estimate software through problem decomposition.   This process has involved taking a complex problem specification through recursive decomposition until you have a set of problems which are well understood.  Ironically it is much like how we are taught to solve problems from advanced math disciplines such as differential equations (everyone should try one of these classes).

Unlike a math problem with a concrete specification, software concepts tend to be much less understood.  These traditional software methods would depend on designers, architects and leads performing the decomposition required to provide specific designs and exact estimates.  Unfortunately this cannot occur without a complete specification.  While this problem should be obvious, often teams fall prey to pressures created by those removed from the process who do not understand. 

Agile processes embrace the reality the specification is a work in progress and instead focus on a compositive process whereby a solution is built up one step at a time.  Instead of wasting time & resource on an arbitrary big picture definition (which may not be right from the outset), the focus switches to building up a solution with regular checks and balances. 

Would you agree that Agile effectively helps reverse this backwards approach?  How might this change your approach to leveraging agile?