How to release with Kanban? [closed]

Question

In Scrum, it is obvious that we could produce a demo after each sprint.

I don't know how to produce demos in Kanban since it doesn't has the sprint concept (I may be wrong).

Would you please enlighten me regarding how to make releases in Kanban?

Thanks for help and time.

Answer 1

When we were implementing Kanban at my last job, the releases went one of three ways:

1. Release every two weeks on a schedule.
2. If enough sticky notes end up in the "done" bucket on the board to merit an out-of-cycle release, notify the business unit that we're releasing so we can prevent getting too out of sync.
3. The business unit requires an out-of-cycle release for a specific feature of set of features that are needed immediately.

It was pretty open-ended, really.

Answer 2

Kanban says how to manage the flow of work and limit work in progress, it doesn't say anything about the frequency of releases as such. However, it is quite demanding because it demands that a working integrated version of the product be kept at all times with new features added as soon as they are considered complete (done, last column on the board).

A concept that is frequently used is that there is a "cadence" - a regular interval when this "ready product" is taken and actually deployed to the live system/shipped.

However, I think that one concept that is very clear in Scrum may also help here. In Scrum it is clearly said that Scrum calls for a "shippable product increment" (confirming to the definition of DONE) at the end of each sprint. Whether to actually ship it / deploy it is out of scope of the development process, because it is ultimately a business decision. Same I think applies to Kanban, a ready, integrated product is available at all times, whether to actually use it as a business decision which is outside of the scope of the development process and its management.

Answer 3

There is no single definition. Usually in Kanban we add MMFs (Minimal Marketable Features) which, by definition, means that every feature should add value to the customer, thus you should be able to release every feature independently.

This doesn't mean you have to release each feature separately, so you will find whole range of approaches (David mentions a few of them). I find it a common case that Kanban team release more often than they would if they followed one of time-boxed approaches.

Demos in Kanban are optional but if the client is willing to have them you can demo features as you deploy even if you release every feature independently. In theory every feature should add value so this approach should work well.

Answer 4

We make a demo a condition of moving a feature from "Testing" to "Ready for Release". So it's feature-by-feature rather than sprint-by-sprint, and the nature of the feature will determine the nature of the demo. The greater the business involvement during development the less of an issue this becomes anyway.

Answer 5

You can try adding a sign-off step to your DOD where you may arrange a quick demo. But the difference would be, it will be an one-to-one demo whereas in scrum sprint review, the demo is for all the attendees.

Regarding the release cycle, its already mentioned in previous answers. I would like to add one more point, you may have a limit for yet to release items. For example, if you have 10 MMFs are in the board ready-to-be-released then release process can be kicked off then and there.

This method may help you to track down throughput in a way.