The Tug-of-War Between Releasing Early And Completing The Project

Spoiler Alert: Your Company Could Be Losing Millions

For technology companies, the idea to “release early and release often” is not new and the ability to ship product or product increments in a predictable and accelerated manner is core to Agile. Yet, companies shy away from doing so for two reasons: they can’t or they won’t.  

Necessary Feature Or Gold Plating

Longer projects means more opportunity for scope creep, and identifying when a project is complete is actually harder than one would think. When Geneca surveyed almost 600 IT and business executives, the organization found that 77% say there is lack of agreement on when a project is done, a prime symptom of fuzzy requirements and/or lack of business objectives.

The trick for stakeholders and managers is understanding whether that extra feature will actually add value to customers or if it’s just an example of gold plating. Is this extra feature worthy of delaying the release–is it something the customer wants or will it just be one of the 64% of features that are rarely or never used per Standish report?

Even worse, forget having a bad quarter. According to white paper Delivering Large-Scale IT Projects On Time, On Budget, and On Value by McKinsey & Company, the failure of large IT projects, costing $15M+, can actually threaten the life of a company. And some of the biggest contributors to large IT project failures include shifting requirements and lack of business focus.  

Accelerated Release Is The Opposite Of Risky Business

There’s this thing we talk about called the “Risk Iceberg.” The risk iceberg is a way to visualize the unseen troublespots inherently caused when product development is worked in phases stacked one right after another: plan, build, test, release. With the traditional method (or Waterfall) a team could use 80 percent of the allotted time and resources by the time they discover a defect. Worse yet, the product could get in the hands of users only to discover they built the wrong product.

Agile breaks up a big project into smaller prioritized chunks of work, known as product increments. These bits are separately planned, built, tested, and deployed, in other words, 100% complete, before the team moves onto the next piece of work. A collection of chunks can become PSPIs, Potentially Shippable Product Increments, that can be tested by actual users. The cycle of build, deploy, and learn means a couple of things:

1. Teams and stakeholders know exactly how much work is left (no major schedule surprises)
2. Teams and stakeholders know how users are reacting to the product (no major market surprises)

Accelerated Release, Accelerated ROI

The accelerated release of products means teams can learn from users but it can also mean organizations will start to recoup some of the original investment or even make a profit ahead of schedule. Consider scenario A and scenario B:

Organization A is investing 100K a month for the next 12 months with a 3x annualized return. At the end of the project, the organization has spent $1,000,000. Since organization A is using waterfall, the product deploys at month 13. Assuming the original requirements are correct and the product is accepted, the organization breaks even at 16 months.

Organization B is also investing 100K a month for the next 12 months on a product with a 3x annualized return. However, organization B is using Agile.

At month two, organization B begins to deliver a percentage of product value. Value is delivered incrementally over the next 10 months. The product is complete at month 12.

Organization B becomes profitable at month 9, 5 months before organization A.

Releasing early means the ability to get market feedback, which accelerates learning, which creates a better product. Stakeholders and managers can trim the tail and end the project early if it has been determined that it is good enough. It can also mean being ahead of schedule from a profit perspective. It can also mean saving resources for another project if data shows the current one will or will not pan out. All are much better options than a blown scope or a failed product.