Iteration Centric Cadence

Cadence means rhythm and lean practitioners use cadence to talk about the rhythm of their work, like the heartbeat of their process.

Kanban does not talk about cadences. The main focus in Kanban is visualization, limiting WIP, and helping work flow, but that does not mean that we cannot use cadences to work our best.

Other than the cadence of daily Standup meetings and weekly backlog refinement meetings, the team can decide to work within a time-boxed iteration (which is a cadence too) or use a flow based approach.

1. Time-boxed iteration

Time-boxed iterations lay the foundation for predictability. With a regular cadence, a team can start measuring and predicting how they are doing against their goal. If a team delivers seven work items every two weeks, it can set the goal for the next two weeks accordingly and have a review process every two weeks to see how it did against the goal.

The Iteration starts with planning what you are getting ready to do and, by the end of the iteration, what you will be done with. At the end of the iteration, look back at how the last iteration went and see the opportunities for improvement. The practices of Kanban, which make work visible, limit WIP, and help the work flow, still apply in iterations.

2- Flow-based approach

The main focus of the flow based approach is on work items and how they individually flow over the board. There is no start or end.

The planning and review are done at regular intervals in a flow-based approach and either cadence is decided for that or it is done just in time. For example, a team can decide to plan every week and have a review and retrospective every 4 weeks. A flow-based approach does not mean that we can get rid of planning, review, and retrospective sessions at regular intervals. We can have the cadence we see fit for activities such as reviewing, planning, demonstrating, and retrospecting. In a flow-based approach, cadence is not tied to the flow of work.

Many scrum teams start with an iteration-centric cadence in the beginning and then slowly move away from that to a flow-based process without iterations.

There is no way to tell which method is better. One way is to decide based on your backlog.

• If you have a backlog of items that you need to work on, then an iteration-based approach would be suitable, as it will give you a focus on what is within the scope of the iteration and what is not. It also helps you predict when you will be done with certain backlog items.
• If you are in support or maintenance phase of an application and there is no fixed backlog but work is flowing in the system and the work items are managed as they come to you at any time, flow based system might be better, without any start and stop of the iteration.

It is important to understand that if Kanban method does not say about anything, it does not mean it can not be done. Team can decide the process that help them do the great work. E.g. Kanban did not talk about planning it does not mean that planning should be done, just like testing your code is not mentioned in Kanban.

Flexibility is main component of being agile and teams can adapt a process to what work best for them and their organization. Goal is delivering high quality products.

Go back to the Essentials page.

Reference: Kanban In Action by Marcus Hammarberg and Joakim Sunden