Agile projects are more successful than waterfall projects. There, I said it. And I have the statistics from the Standish Group to back it up.
I’ve been a follower of the Standish Group Chaos Studies for a long time. The Standish Group has conducted surveys of IT project success and failure rates every 2 years since 1994. Initially the statistics were really bad with IT project success rates measured at less than 20%. Thankfully things have improved, though not much. Project success rates for technology projects are still pretty low.
What makes a project successful? Initially, the definition of project success was limited to the triple constraint, which has been the standard for the Project Management Institute for a number of years. So a successful project was one that met all three of the triple constraints: schedule, cost, and scope. A challenged project would have met two out of three constraints. And a failed project missed on two or more of the constraints.
The Standish Group took some heat over the years for their strict definition of success, challenged and failure. Recently the Standish Group tweaked the "scope" part of their definition to include not only scope but customer satisfaction, value delivered, and alignment to strategic goals. You can read more about the change here. But I digress.
Agile Projects are More Successful. What is interesting and perhaps not very surprising is the difference between success and failure rates between Agile projects and more traditional Waterfall projects. For 2011 to 2015, the overall breakout of success, challenged and failure is shown below for agile and waterfall, with Agile projects being about 3X more likely to succeed.
There are several key takeaways from this:
- Agile Projects Succeed More Frequently. While Agile approaches are not necessarily a silver bullet, the data shows they can help to reduce risk. The Standish Group data shows that Agile projects are 3X more likely to succeed or 1/3 less likely to fail than waterfall approaches. In my opinion, the primary reasons for this are the amount of user collaboration on Agile projects which helps to ensure the team is building the right solution and incorporating feedback. Agile teams also develop in short iterations and take items all the way to done within a sprint to further reduce risk.
- Smaller projects succeed more often than big projects. Duh! Even though this may be common sense, many people ignore it. Organizations that take the time to break big initiatives down into manageable chunks find that they can better manage the schedule and risk, and often deliver something of value with each small chunk. Some organizations deliver an MVP or Minimum Viable Product and use that to get feedback or validate their assumptions about the end users or customers.
- There is still room for improvement. There are still a lot of projects that are not considered "successful", both Agile and Waterfall. I think organizations need to learn from the past and leverage the findings from the Standish Group. We really need to do better.
Is "project" thinking part of the problem? In looking over the Standish Group findings, I had to wonder if part of the IT challenge is that many people still look at the world through the "project" lens. By definition a project is temporary and unique - both factors contributing to the risk of failure.
It is interesting to me the way that many organizations today manage their portfolio of project work. Frequently, all projects are high priority and they can't say no to new requests, so they keep starting new projects. There are never enough people to do all the work so they assign and over-allocate their top performers to multiple projects. They keep churning project teams and starve low priority projects. The net result is a portfolio where a little bit is done for lots of projects but few projects are actually completed.
A different approach - long-standing and stable teams. Most mature Agile organizations do things differently. They have moved away from the concept of projects and set up long-term stable teams. They create the conditions for high-performance in these teams. These long-term stable teams work at a sustainable pace and pull work from an organizational backlog. They don't overload the team, move people between teams, or assign team members to multiple teams.
Interested in Learning More about Transitioning to Agile and Scrum?
Are you considering a move to Agile and Scrum? Here are some resources that you might find helpful:
How to Successfully Transition from Waterfall to Scrum - This overview post provides a summary of the steps you need to consider when moving to Agile and scrum. It also includes links to free resources like planning checklists and a detailed whitepaper on how to successfully transition to Scrum.
If you are wondering if your organization is too big or too old for Agile, read this Case Study about how Bank of America successfully made the transition to Agile and Scrum.
Training for Agile and Scrum - Our Training page provides a list of all the training courses organizations have found helpful to better understand Agile and what it means to transition. Our most popular course is Agile and Scrum for Teams. This course is designed to be delivered to the complete Scrum team and to provide them hands on experience so they are ready to hit the ground running and succeed with Scrum. Our Agile for Leaders course is designed to provide a high-level overview of various agile frameworks like Scrum and Kanban, and an indepth understanding of the cultural change and mindset needed to support successful Agile adoption in organizations.
The Leaders Role in an Agile Transformation - Leaders play the most important part of the Agile Transformation. Read about how leaders cast vision and lead through change. You can also visit our Resources for Agile Leaders page to get even more resources.
You can read more about the Standish Group Chaos studies here and here.
By Anthony Mersino | Monday, August 1, 2016
Learn How to Transform
Your Organization from
Waterfall to Scrum
A Kickstarter Guide On