Projects in the Real World: Agile and Beyond

Priya Patra is a Program Manager in Mumbai, India.

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
    • Common governance structure that defines common milestones with different definitions for agile and waterfall teams.
    • A “hardening” iteration at the portfolio level to ensure integration between the two tracks of the projects
  2. Projects with low-dependency teams
    • Temporal integration periodically at iteration levels throughout
    • A “hardening” iteration before the final release
  3. Projects with heavy dependencies
    • Synchronization minimum at every iteration
    • Daily interaction may be required in some cases for key issues or dependencies.
    • The agile team needs to make assumptions to make progress on its iterations, while the waterfall team progresses toward an integration point.
    • These assumptions must be validated on a regular basis and, if needed, be used to drive the appropriate re-factoring within the agile team for assumptions that didn’t hold true.

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!

Want more content like this?

Sign up below to access other content on ProjectManagement.com

Sign Up

Already Signed up? Login here.

Published at Sat, 06 Oct 2018 04:00:00 +0000