Is It Time to Shut Down Your Agile Project?

Agile planning involves allocating an amount of money (or time) to produce functions that deliver business improvement. When that time or money runs out, the project ends unless a business case to continue is made and approved. There are other situations, though, when an agile project should be stopped – even one that appears to deliver business value:

• Priorities should be changed. Although the project might still be making a positive contribution, those contributions might have decreased in importance to the organization at this point. If other initiatives are poaching skilled technical and user team members, assess THIS project’s contribution relative to other initiatives. It might be best for the business to stop this agile project to allow skilled team members to focus elsewhere.
• The primary business problem or opportunity has been addressed. Projects are launched to deliver value and specific changes. Once the value and changes are realized, user and sponsor interest might wane. Indications of this lack of interest can show up as inconsistent meeting attendance or features not being completed within prescribed sprints. Review the project to determine whether work should be stopped.
• Technical debt is increasing. When there’s pressure to deliver value, taking little shortcuts is common. Add code without comments, skip some testing scripts, or install a bit of code that doesn’t quite fit into the overall solution design. Is this the wrong thing to do? Maybe, maybe not. What these shortcuts do is create technical debt, that is, an accumulation of work that needs to be addressed downstream. If this starts to happen more often, the team might be working beyond their current experience and capabilities to deliver value and creating issues in the process. When this occurs, it’s time to address technical debt and close the project. Evaluate whether the right skills – and business case – are in place to continue.
• Benefits rationalization is increasing. When agile projects are launched, features in the backlog typically have a clear-cut purpose and business case. As the original backlog is completed and new features are added, the business value for those features can become a bit fuzzy or be based on broad assumptions. This rationalization of benefits to produce more features can be a waste of time because they don’t deliver solid value. In addition, maintaining them downstream can add unnecessary complexity and financial burden.

For more about agile projects, check out Doug Rose’s Agile Foundations course.

Coming Up

I’m starting to work on updating a couple of my projects. Stay tuned for more info!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 104,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________