Product release process in Agile?

Question

Can anyone please explain the product release process in agile methodology? I have a bit idea about the release plan. Are both same? If any difference are there then kindly speak.

Answer 1

Release process means the steps you have to go through to get a product or product change into the marketplace or being used in its intended context. It is usually independent of the methods used to develop the product but is very dependent on the type of product, the technologies used and the organisation you work in.

Release planning is something different. Typically that means putting product features on a timeline or into a sequence to indicate when they will be available.

There is really no such thing as "agile methodology". Agile refers to an approach - a set of ideas, techniques and principles that can be used to solve complex, adaptive problems.

Answer 2

_{This is a large topic to answer so I'll just add some general information. If you have other questions or things are still unclear, you should open more specific questions.}

---

In more traditional software projects that employ sequential phases for building software (like the Waterfall model for ex.) releasing software (i.e. making it available to users) usually happens in the final phases of the project. A release means to package and deploy the application, usually in a production environment, although it can be also in other environments for testing, validation, etc. The release could be done manually or automatically. It was usually a manual process since it was happening only once. Sometimes, intermediary releases could also be created (like for important milestones) which could be deployed to various environments. These tended to include many functionalities or sometimes the complete application but not 100% functional or with bugs, often denominated as Alpha versions, Beta, Gamma, etc, and then the Live release.

With the advert of Agile methods, the more traditional release model changed because one of the ideas behind Agile is to deliver software often. Each sprint creates a potentially releasable product increment. You no longer have big releases full of features, you have smaller ones that incrementally add more and more functionality to the application. Having this idea in mind now involves some sort of automation of builds/releases because it will be a pain to do them manually so often.

There are Agile teams that release software even sooner than after each sprint using techniques like continuous delivery and continuous deployment.

Since you deploy small functionalities very often, you might not think about those increments as releases, because they are small. Traditionally, a release was something feature packed, something of considerable size. So Agile also has this notion of releases.

A release in Agile means to wait before making features available to the user and packing them into one big package. Instead of delivering each sprint, you might decide to deliver once every quarter, for example, or for important events. You still develop working software each sprint, but you just wait until you have more features and then release them. This is a business decision and depends on the organization, the domain, the application, etc.

So, in Agile, a release is a combination of features from multiple sprints. You can of course decide to release every, say, 6 sprints, or you can do a release planning before hand. This is probably the thing you mention in your question. Release planning is a longer term, higher level planning to decide what each release should contain, get a feel of when the whole product might be finished (with what's currently in the backlog), what features it will contain, how much they will cost, and how to set the priorities for working in each sprint to make those things happen.

As with many other things in Agile, the release planning is something that happens more or less continuously (or at least in an iterative manner), it's not just something you do at the beginning of the project. A product backlog in Agile is not a full set of requirements and specifications, it's a living artifact that will evolve as you learn more about the product. So a release planning is a large level forecast that will change in time, it's not a bunch of deadlines that must be hit spot on or else...

Answer 3

This is a big topic, but I can talk about the release process in the organisation I work in.

The development teams continually deliver working code to the production environment, but they hide the new functionality behind feature toggles. The idea being that while releases are frequent, it is a business decision as to when the new features are made visible to the customers.

The benefit of this is that it combines the agile approach of delivering working software frequency with the flexibility that marketing, sales and other business teams need.

Answer 4

Agile isn't a methodology and it doesn't prescribe how you build your process and how you release. Though it does suggest a short delivery cycle.

There are 3 common approaches to releases*:

1. Scheduled-based releases. E.g. in Scrum you deliver your increment at the end of the sprint. Usually Waterfall is also based on the delivery schedule, but it may as well fall under the next category.
2. Scope-based releases. You finish a scope of work - then you release. Just-in-time (Kanban) and Theory of Constraints are modern approaches that follow this ideology. Ideally each time you complete a task - you release.
3. Continuous Delivery (CD). Suggests that we release even the work that's not yet finish (we hide it with Feature Toggles or Branching by Abstraction). Unless something's broken - you can deliver.

#3 is the fastest approach, #2 achieves the highest level of quality. Note that at the beginning of the project there's probably nothing to release, so don't follow these (or any other) rules blindly.

*This is my personal terminology, I don't know if some well-known classification exists.