Have you ever been faced with a project, feature or requirement which initially caused you to ask how an Agile process could possibly be applied?  Maybe it seemed too complex, too many moving parts, or simply too big.  If so, let me say – this should be an immediate red flag!

After facing this scenario on multiple projects (some before Agile was well understood) and considering the outcomes and challenges experienced, I have come to appreciate ever more clearly how this response should be an immediate warning sign that Agile is exactly the process needed to deliver successfully.  Recall that “successful delivery” is not just about date but delivering the right release. 

The reality is those projects which seem the most daunting and complex, likely have a significant number of unknowns (or details).  These might be technical, feature, usability – but clearly the simple fact that you do not yet understand or it seems too big opens the door wide to leveraging Agile to ensure the best right product is delivered as soon as practical.  While most of us can appreciate it is not possible to resolve all “unknowns” upfront, when not managed properly these unknowns when compounded can be big factor in a projects failure.

Leveraging Agile will create an environment which helps give all stakeholders improved visibility as a complex project unfolds.  Considering these projects rarely go as originally expected (either by choice or by necessity) – this transparency should help ensure the right participants have ownership in the ultimate outcome.

Don’t become a victim to the false belief a project is “too big” or “too complex” – push to leverage Agile!  Even if you are getting pressure to fix a date & cost – you need Agile and your team will likely benefit, so maybe suggest a trial run of a few iterations.

If you are an Agile expert or been through a similar situation, I would love to hear from you including any lessons learned.


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?