Trilogix Cloud

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

 

Use Agile when

Pros

Cons

Architecture informal and incrementalDiscovery with hands-on allows one to discover the current estate which is mandatory in order to build a proper TOMCross functional teams are difficult to arrange, manage, Agile PM skills do not exist
BudgetingBased on delivering valueWaterfall budgeting is done once a year, difficult to change
Code baseCode management is important and each code base moves with associated application to TOMExisting SME time to help discover can be costly, difficult
Supporting infrastructureApplications are tied to LDAP, DFS, NFS and other infraDomain, network access difficult to obtain, time-lags
Continuous integrationDependency mapping a priority and necessityNot documented usually, takes a lot of SME, existing Ops time to do
Functional Requirements are complexDomain logic must be understoodDomain logic documentation costly to make, time-lag, requires a lot of people to input
Non-Functional requirements are complexNFRs are built into the designIf no existing NFRs takes time to get the organisation to agree on what they are
Best engineering practicesPatterns and principles drive development, deploymentPatterns and principles need org input and sign-off, takes time, Agile skills lacking
StakeholdersMatrix map of stakeholders and what they wantTime-consuming, hard to get inputs from stakeholders, delays everything
Complex environmentsDesign principle should be simplicity, need to map out how to migrate to a coherent modelSilos mean little active cooperation can be expected, unless C Suite gets involved
BusinessAligns IT with the businessBusiness does not have time for technical projects

 

Leave a Comment

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