Using Agile To Recover Failing Projects
Too many projects fail, with or without Agile. How can you truly adopt Agile to both prevent and recover failing projects?
Join the DZone community and get the full member experience.
Join For FreeDid you know that up to 84% of Waterfall and 47% of Agile projects either fail or don’t meet expected results? That may sound like an alarming number, but the point of this is not to be a doomsayer or to focus on the perceived negative. What those numbers reflect is an opportunity. An opportunity to turn a seemingly failed project into a flourishing one, to learn lessons, and to leverage the things that make Agile principles work so smoothly when they do.
The name for Agile methodologies was chosen well and done so for a reason. To be agile is to be quick on your feet, to be able to adapt quickly, and to be able to solve unpredictable problems while keeping momentum. Just like in a fast-paced race, when things start to go wrong, they tend to do so quickly. Agile problems require agile solutions — to be solved as speedily as they appear or change or ripple outwards.
So, why do some projects fail and others don’t, and what can be done about it? The reasons for failure or underperformance can be as varied as the people involved or project milestones. We’ve all heard of, or encountered versions of them before; missed deadlines, budget overruns, low morale, personnel changes, scope creep — the list can go on. But there is a common denominator here — almost all these issues are inevitable. Inevitable in the sense that project management is built around project failure — something will stray from the plan, so the goal is not to try and eliminate this aspect, but to manage it with agility. The successful recovery of a project, or having to recover in the first place, is then not a failure of the system but many times a failure of imagination. How can we then use the methodologies of Agile, to recover a failing project?
Understanding Agile Principles
First, let’s quickly recap the core tenets of Agile. Agile is a methodology, yes, but it’s not just a method — it’s a mindset that combines the best aspects of humans working together. It values flexibility, collaboration, and continuous improvement. Broadly, Agile is an umbrella term that encompasses various iterative software development methodologies but has branched out into all sectors where that workflow makes sense. It focuses on working in short cycles called sprints, and doing so welcomes responding to change, collaboration, and delivering on customer’s evolving needs.
Feature |
Agile |
Waterfall |
Approach |
Iterative, incremental, flexible |
Linear, sequential, rigid |
Change |
Embraces change throughout the project |
Resistant to change after planning is complete |
Planning |
Continuous, adaptable planning |
Detailed upfront planning |
Team Structure |
Self-organizing, cross-functional teams |
Specialized teams working in silos |
Communication |
Frequent, informal communication |
Formal communication with regular reports |
Documentation |
Prioritises working software over comprehensive documentation |
Emphasises comprehensive documentation at each phase |
Diagnosing The Failing Project
Before we can fix the problem, we need to identify the problem - sounds obvious right? It needs to be diagnosed constructively though, beyond simply labeling a cause and effect. It’s the first step in getting to the root of the problem, not just trying to eliminate the symptoms.
1. Conduct a Retrospective
A structured meeting where the team reflects on the past sprint or iteration to identify what went well, what didn't, and what can be improved. Encourage open and honest discussions and collaboration by creating a blame-free environment — emphasize learning from mistakes and then take action based on findings.
2. Analyse Sprint Burndown Chart
Burndown charts visually track the remaining work in a sprint against the time remaining, helping with scope creep, underestimation, and blockers.
3. Review Velocity Trends
A declining or inconsistent velocity can signal problems like team burnout, skill gaps, and poor estimation.
4. Gather Feedback From Stakeholders
Clients or end-users can give valuable feedback and reveal issues such as misaligned goals, communication gaps, or dissatisfaction.
5. Conduct a Root Cause Analysis (RCA)
By using tools like the "5 Whys" technique (asking "why?" five times), you can drill down from surface-level symptoms to the root causes of project issues. This helps you address the fundamental problems, not just the symptoms.
Using Agile Methodologies To Get Back on Track
Let’s now cover some of the aspects intrinsic to Agile and how they are beneficial to rescuing any project.
Individuals and Interactions Over Processes and Tools
- Why it matters for recovery: Relying solely on rigid processes won’t solve a failing project. Motivated, knowledgeable, and empowered individuals need to communicate and collaborate effectively.
- How to apply it: You need to encourage open communication, while trusting your team’s expertise and empower them by knowing that they can come up with solutions and decisions.
Working Solutions Over Comprehensive Documentation
- Why it matters for recovery: Whether you create software or offer business solutions to clients, a failing project needs tangible results, not just more paperwork.
- How to apply it: Using sprints, provide value by cutting the fat — in other words, prioritize features that mean something to clients, by getting it in front of them and then getting feedback.
Customer Collaboration Over Contract Negotiation
- Why it matters for recovery: Similar to the previous point, but more focused on involving the customer or client and veering back to what they actually want.
- How to apply it: Regularly gather feedback from the customer, involve them in sprint reviews, and be transparent about progress and challenges. They will appreciate the transparency and involvement.
Responding to Change Over Following a Plan
- Why it matters for recovery: As mentioned earlier, the hallmark of an Agile project and a quick recovery is adapting to change. The more rigid a plan, the more likely it is to crumble under pressure.
- How to apply it: Again, the practical way to approach this is by using short sprints, with tangible results. Then, based on those results, adapt the plan as needed while being open to feedback.
To put it another way, we can use 6 A’s to define project recovery;
- Aligned to strategy: Making sure everyone is on the same page, from those who are doing the work, to those with the expertise, to the clients and end-users.
- Active sponsorship: Without oversight, leadership, and adherence to budget, any project can soon derail. The sponsorship needs to be active, not passive and distant.
- Agile team of teams: Each member of the team needs to have a stake and be empowered, whether it’s managerial or delivery, all teams work together to be nimble yet focused.
- All-team planning: Informed, capable, and experienced leaders know that planning needs to happen together. A plan can be meticulous and extensive, but if different teams or silos have different plans, alignment will always be out of reach.
- Adaptive culture: The core of an Agile environment. The true reflection of a project, plan or organization in its problem-solving is not just the ideology on paper, but in practice. The culture needs to be encouraged from both the ground up and the top down. If someone notices an issue, they do what they can to help, not simply what is mandated.
- Agile expertise: Knowledge is power. With rapid feedback, you also need to be able to apply that feedback timely and effectively. This is where experience and knowledge of Agile systems and principles in practice come in. Without bespoke solutions, real-world application, and hands-on experience, Agile methodologies are in just as much danger of failing as others. You need people on your team who know not only the map but also the territory.
When it comes to re-aligning a project, saving it from failure, or future-proofing new projects, all these principles will stand you in good stead. They are tried and tested, not just by us but by countless organizations and projects around the world. This experience, iteration, and adaptation goes beyond good business practices and filters through any organization to form a solid, dependable foundation.
Opinions expressed by DZone contributors are their own.
Comments