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:
- Architecture informal and incremental, current and end states are usually not documented or well known; requirements vague
- 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
- Code base is uncertain, ie media, code repos not known or need to be discovered, processes not documented
- Supporting infrastructure including LDAP, security, logins, environmental control and access are not documented, known, or have complex inter-dependencies
- Continuous integration and delivery is necessary ie data replication, middleware, HA, Redundancy, dependencies not mapped, nor understood
- Functional Requirements are complex, not known, documented or well-understood
- Non-Functional requirements are complex, not known, not documented, not well understood
- Best engineering practices including design patterns, test cases, must be developed
- Stakeholders need to see progress on a timely basis, including documentation; pilot projects and delivery of something tangible they can see and use
- Complex environments with SMEs from different areas, working together to identify and resolve issues, learn, use automation, a technically driven approach is necessary
- 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:
- Current and end states are well known, understood and documented, requirements clear, obvious
- 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
- Code base, media, clean, up to date, documented, easily known/accessible
- Supporting infrastructure is well documented, up to date, understood and does not need discovery, or analysis by application area or domain
- Integration and delivery are viewed as unimportant or don’t exist, dependencies clearly mapped, rather straightforward no need for iterative discovery
- Functional requirements are pretty simple, clear, well documented
- NFRs are pretty simple, documented, known, agreed
- Best engineering practices are already available including design patterns, automated test cases
- 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
- 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
- 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 | Pros | Cons |
| 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 |
| Budgeting | 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 |
| Stakeholders | 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 |
| Business | Aligns IT with the business | Business does not have time for technical projects |