When we were implementing Kanban at my last job, the releases went one of three ways:
Release every two weeks on a schedule.
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.
The business unit requires an out-of-cycle release for a specific feature of set of features that are needed immediately.
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.
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.
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.
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.
发布评论
评论（5）
当我们在上一份工作中实施看板时，发布采用以下三种方式之一：
这真的是相当开放式的。
When we were implementing Kanban at my last job, the releases went one of three ways:
It was pretty open-ended, really.
看板说明了如何管理工作流程并限制正在进行的工作，但没有说明发布频率本身。然而，它的要求相当高，因为它要求始终保留产品的工作集成版本，并在认为完成后立即添加新功能（完成，板上的最后一栏）。
经常使用的一个概念是存在一个“节奏”，即采用“现成产品”并实际部署到实时系统/交付时的定期间隔。
然而，我认为 Scrum 中非常明确的一个概念在这里也可能有所帮助。 Scrum 中明确指出，Scrum 要求在每个冲刺结束时进行“可交付的产品增量”（确认完成的定义）。是否实际交付/部署它超出了开发过程的范围，因为它最终是一个业务决策。我认为这同样适用于看板，一个随时可用的现成的集成产品，无论是否实际将其用作业务决策，这超出了开发过程及其管理的范围。
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.
没有单一的定义。通常在看板中，我们添加 MMF（最小适销功能），根据定义，这意味着每个功能都应该为客户增加价值，因此您应该能够独立发布每个功能。
这并不意味着您必须单独发布每个功能，因此您会发现各种方法（David 提到了其中的一些）。我发现一个常见的情况是，看板团队比遵循某种时间限制方法时发布的频率更高。
看板中的演示是可选的，但如果客户愿意，您可以在部署时演示功能，即使您独立发布每个功能也是如此。理论上，每个功能都应该增加价值，因此这种方法应该运作良好。
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.
我们将演示作为将功能从“测试”转移到“准备发布”的条件。因此，它是逐个功能而不是逐个冲刺，功能的性质将决定演示的性质。开发过程中业务参与得越多，这个问题就越小。
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.
您可以尝试向 DOD 添加签核步骤，您可以在其中安排快速演示。但不同之处在于，这将是一对一的演示，而在 Scrum 冲刺评审中，演示是针对所有与会者的。
关于发布周期，在之前的回答中已经提到过。我想补充一点，你尚未发布的物品可能有限制。例如，如果板上有 10 个 MMF 准备发布，则可以立即启动发布过程。
此方法可以帮助您以某种方式跟踪吞吐量。
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.