When to use Agile – a summary

Agile is widespread within IT as a development and deployment framework. It is not generally that well understood in practice. Most IT projects should use Agile. There are many issues however including GDAD, co-location, team formation, skills training, and proper use of Agile processes and roles. The following tables provide a guidelines on when to use Agile and some of the challenges involved.

  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 are 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 Pros Cons
1 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 difficult to arrange,
manage, Agile PM skills do not exist
2 Budgeting Based on delivering value Waterfall budgeting is done once a year,
difficult to change
3 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
4 Supporting
infrastructure
Applications are tied to LDAP, DFS, NFS and other infra Domain, network access difficult to obtain, time-lags
5 Continuous
integration  
Dependency mapping a priority and necessity Not documented usually, takes a lot of SME, existing Ops time to do
6 Functional Requirements are complex Domain logic must be understood Domain logic documentation costly to make, time-lag, requires a lot of people to input
7 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
8 Best engineering
practices
Patterns and principles drive development, deployment Patterns and principles need org input and sign-off, takes time, Agile skills lacking
9 Stakeholders Matrix map of stakeholders and what they want Time-consuming, hard to get inputs from
stakeholders, delays everything
10 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
11 Business Aligns IT with the business Business does not have time for technical projects

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.