Projects in the Real World: Agile and Beyond

Priya Patra

October 6, 2018

According to the 2017 PMI Pulse of the Profession® report Success Rates Rise: Transforming the High Cost of Low Performance, “A full 71 percent of organizations report using agile approaches for their projects sometimes, often or always.” Another recent survey reported that more than 80% of organizations now follow an agile approach. Does this mean agile has replaced the other development methodologies? Is it true for all projects? Let’s look at some characteristics of projects in the real world…

1. Multi-modal programs: Projects in the real world are multi-modal; there are dependencies across third-party vendors, partners or other internal teams that may be executing projects in waterfall. This means we come across scenarios where we need to maintain synchronizations across multi-modal programs:

  1. Projects that are independent of each other need to be deployed in a common release
  2. Projects with low-dependency teams
  3. Projects with heavy dependencies

2. Maintenance and enhancement projects – You build it, you run it (YBIYRI): These are projects where we already have a release done. This means it’s in production, but we also continue to evolve the product by adding features to it:

  1. Maintain one team, development and support; this team is maintained through the life of the product
  2. A fixed capacity of the team is kept aside for regular production support work, resolving incidents and answering queries
  3. Enhancement continues in iterations
  4. Any excess capacity available could be leveraged to take up stories related to technical debt or refactoring as long as the product owner agrees to it

3. ERP systems: ERP projects mainly deal with implementation of “off the shelf” products. The traditional way was using the waterfall approach, or an iterative approach:

  1. Plan for work packages of test objects based on similar functionality that can be tested in an integrated fashion (multiple of sprints determined by object volume)
  2. Focus on the more complex objects in the first two work packages
  3. Each work package is signed off and accepted by the client progressively
  4. There is a final E2E (end-to-end) testing phase where the integrated scenarios are tested
  5. Mitigates risk of discovery of issues/bugs in E2E that can extend the test phase with re-work and re-testing
  6. Progressive acceptance of objects by client business builds adoption throughout

4. Projects in regulated environment: These would be projects for banks and financial institutions, or software for medical devices.

  1. DoD (definition of “done”) to include regulatory requirements
  2. Build a quality system for validation of ISO/FDA requirements
  3. Cross-functional team to include quality and member with FDA/ISO SME
  4. Be in constant touch with the regulator
  5. Continuous alpha and beta testing by users to ensure early feedback
  6. A “hardening sprint” that is run to ensure release readiness before final release
  7. Use tools to ensure compliance-related documentation is captured

Choose the methodology that is right for your projects; the above are some cases that worked for me. Let me know if it worked for you in case you decide to try—or if you have any other inputs, I would love to know about it!

Copyright © 2024 All rights reserved.

The URL for this article is: