Can Fixed Scope/Variable Timescale be Agile?

Question

I have an ongoing argument - our delivery manager tried to introduce a "release after 3 sprints" pattern into our teams. Unfortunately, like many businesses, the actual work can be x number of sprints, often more than 3.

I argue, just because the scope is fixed up-front, that is just our DoD. We release to Live when we complete the scope and we are Done. Nothing in there breaks agile principles - we just acknowledge that although in theory we could release to live at the end of a given sprint, in reality we never would until we are Done and then we have a true release candidate.

He argues, agile can only be agile if you work a sprint at a time and have a release candidate every sprint.

Which version is correct, or are we both right/wrong?

Answer 1

TL;DR

In any agile framework, if you want to estimate based on fixed scope, your estimated release dates will vary. If you opt instead for a fixed release date or routine release cadence, then it's scope that varies. Both are legitimate options, but in this case your delivery manager is more right than you are.

All Sprints are Potentially Releasable

Your delivery manager is mostly right. Whether you're following Scrum or some other framework that just happens to use the term "Sprint," an agile iteration should always result in a potentially-releasable product. Scrum in particular makes it very clear that each increment must be releasable:

At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done"...The increment must be in useable condition regardless of whether the Product Owner decides to release it.

While most agile frameworks don't define a fixed release cadence, neither do they prohibit it. Since each Sprint results in a potentially-shippable increment, there's no reason not to target a three-month release cadence for the project if that adds business value.

A Release Cadence is an Agile Timebox

It's more traditional to see agile release planning estimating a release date based on how many iterations it will likely take to complete a given set of features. However, Lean flow, DevOps culture, and an industry shift towards continuous delivery and continuous deployment have resulted in some projects moving towards a routine release cadence such as the one your delivery manager wants.

As one example, Ubuntu has a biennial release cadence for long-term support releases, and a six month cadence for interim releases. In contrast, the Debian release cycle follows a more traditional model that isn't inherently timeboxed.

Should Releases Follow a Cadence?

A reliable cadence is generally a good thing in a project management framework. However, an iterative delivery cadence and a product release cadence are really two different things. Whether releases should follow a cadence or not is a product-specific business decision, and there's no "one size fits all" answer to that question.

Answer 2

Releases are a hugely significant aspect of Agile. There are many reasons for their importance, including:

• We value feedback and a released product gives us an opportunity to receive feedback from the end users.
• Doing a release collapses a lot of unknowns, such as "Will it work on the production server?" and "What will be the impact on production performance?"
• Releases also focus the minds of the development team. It makes them think about dotting the i's and crossing the t's. "Is the documentation up to date?" "Have we cleared out the tech debt we discussed last week?"

This is the reason why Agile frameworks like Scrum emphasise the need to have a potentially shippable increment at the end of each sprint.

It may be tempting to say that you don't want to release the product until the finished development work is feature rich and 'complete' from the product marketing point of view. However, this misses out on two of the three points mentioned above. If you wait until the product is feature rich before releasing then you delay collapsing the uncertainty of the release and you let your developers get in to the mindset of delaying work that is only important for a release.

It is worth noting that a lot of Agile organisations will release frequently, but will not immediately make their changes available to the users. For example, some teams use feature toggles. This gives the best of both worlds, you get the value of frequent releases but can also let your business and marketing people control how and when features become available to the users.