When should firms use Agile?  The short answer is that within IT, it should be the de-facto methodology for development, migration and delivery of IT projects.  However, Agile is difficult, mandates a long-term investment along with widespread cultural, organisational, and automation changes and improvements.  


Use Use Agile when:

  1. Architecture informal and incremental, current and end states are usually not documented or well known; requirements vague
  2. Budgeting is hard to determine, given all the uncertainty, budgeting should be Agile based, and after a few sub-projects, a real budget can more accurately be measured based on real-world effort and time, this saves the firm time, money, frustration and prevents wasting effort on RFP based processes looking out over 5 years which have no basis in reality
  3. Code base is uncertain, ie media, code repos not known or need to be discovered, processes not documented
  4. Supporting infrastructure including LDAP, security, logins, environmental control and access are not documented, known, or have complex inter-dependencies
  5. Continuous integration and delivery is necessary ie data replication, middleware, HA, Redundancy, dependencies not mapped, nor understood
  6. Functional Requirements are complex, not known, documented or well-understood
  7. Non-Functional requirements are complex, not known, not documented, not well understood
  8. Best engineering practices including design patterns, test cases, must be developed
  9. Stakeholders need to see progress on a timely basis, including documentation; pilot projects and delivery of something tangible they can see and use
  10. Complex environments with SMEs from different areas, working together to identify and resolve issues, learn, use automation, a technically driven approach is necessary
  11.  We want business embedded inside Agile teams with the team composed of engineers, testers, business owners, QA and the sponsor, the Business Owner will provide feedback, guidance and help break down organisational barriers and obstacles


       Use Waterfall when:

  1. Current and end states are well known, understood and documented, requirements clear, obvious
  2. Budgeting is annual, top-down only, RFPs and ‘guesses’ are the cultural norm, if projects over-run budget complex CR processes exist to obtain more budget, projects are not allowed to begin unless total budgets are estimated even if they are grossly incorrect
  3. Code base, media, clean, up to date, documented, easily known/accessible
  4. Supporting infrastructure is well documented, up to date, understood and does not need discovery, or analysis by application area or domain
  5. Integration and delivery are viewed as unimportant or don’t exist, dependencies clearly mapped, rather straightforward no need for iterative discovery
  6. Functional requirements are pretty simple, clear, well documented
  7. NFRs are pretty simple, documented, known, agreed
  8. Best engineering practices are already available including design patterns, automated test cases
  9.  Stakeholders are not that concerned with delivery, they prefer heavy documentation, lots of processes with a focus on control, meetings a priority, not pilot projects, willing to wait to see a delivery
  10.  Main roles are project management related not technical, automation is not a key focus, fast failure is not deemed important, SMEs can work in silos and easily cooperate within the existing processes
  11.  Firm is fine with Silos of stakeholders, limited information exchange, formal procedures for communication, and ad hoc business reviews within the current processes


Use Agile when



Architecture informal and incremental

Discovery with hands-on allows one to discover the current estate which is mandatory in order to build a proper TOM

Cross functional teams are difficult to arrange, manage, Agile PM skills do not exist


Based on delivering value

Waterfall budgeting is done once a year, difficult to change

Code base

Code management is important and each code base moves with associated application to TOM

Existing SME time to help discover can be costly, difficult

Supporting infrastructure

Applications are tied to LDAP, DFS, NFS and other infra

Domain, network access difficult to obtain, time-lags

Continuous integration  

Dependency mapping a priority and necessity

Not documented usually, takes a lot of SME, existing Ops time to do

Functional Requirements are complex

Domain logic must be understood

Domain logic documentation costly to make, time-lag, requires a lot of people to input

Non-Functional requirements are complex

NFRs are built into the design

If no existing NFRs takes time to get the organisation to agree on what they are

Best engineering practices

Patterns and principles drive development, deployment

Patterns and principles need org input and sign-off, takes time, Agile skills lacking


Matrix map of stakeholders and what they want

Time-consuming, hard to get inputs from stakeholders, delays everything

Complex environments

Design principle should be simplicity, need to map out how to migrate to a coherent model

Silos mean little active cooperation can be expected, unless C Suite gets involved


Aligns IT with the business

Business does not have time for technical projects