When to use Agile and some challenges

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 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