What is the Value of Cadence?

First, let’s briefly review what it means to be “Done”:

Handovers during product development are wasteful, but some are unavoidable. If you build a customer-hosted software product you will handover a release to your customer that includes executable software, install/upgrade/migration tools, training and documentation. Scrum states that you will be “delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint”: “Releasable” might be read as complete and quality assured, while “Increment” implies readiness for future change. So, for every story/feature/bug-fix the dev team works on, a generic ‘Done’ has to be met by the end of the sprint:

From a Lean perspective, you are investing to reduce variance in the handover process. By giving your customer a uniform and predictable procedure for them to deploy high quality deliverables you are removing surprises and risk for them. You are giving them the opportunity to upgrade more frequently without incurring higher cost. You are also avoiding the internal disruption and reputational damage a half-baked release would cause when unplanned rework arrives back in your dev team via customer support.

Which brings me to cadence. Cadence is a way to remove variance from the handover time. If a handover is ready exactly on schedule there is no waste from having resources waiting around to take it. If a series of handovers occur with regular cadence there is none of the planning overhead of each being a unique event. Establishing a cadence is a way to reduce cost by synchronising the recurring activities at either side of a handover.

Cadence does not just help with repeatedly handing finished product over to the customer. Development teams turn information into product, and they need to interface with stakeholders, customers and each other to acquire that information. Interrupting developers when they are in “flow” is a notoriously expensive context switch, and Scrum’s ceremonies should be viewed as setting a cadence for those information exchanges in order to protect developers from ad hoc interruption the rest of the time.

Achieving cadence takes effort. Take Scrum for example: achieving ‘Done’ at the end of every timeboxed sprint takes creative intellectual effort by the dev team and product owner to decompose and estimate additions to your product. It takes a lot of effort (and often premium salaries) to build teams so multi-skilled and flexible that they can collectively complete a diverse mix of full-stack stories each sprint*.

I’m not suggesting we can do a detailed $ cost-benefit analysis to value cadence in our projects. But if you have selected Scrum I urge you to make full use of the benefits of cadence, and not just blindly incur the costs:

• Don’t let convenience for one stakeholder push key Scrum meetings around; educate them that these are immovable commitments that were the first entry in their diaries and you will not incur planning cost on everyone else for their benefit
• Use scheduled recurring meetings to protect your dev team from ad hoc interruptions, and ensure they get long continuous periods for development each day
• Make full use of the planning and demo meetings at either end of the sprint timebox to extract direction and feedback from customers and stakeholders

The corollary is that if you don’t value cadence Scrum might not be the right method for your team. Kanban, with its focus on flow and WIP management instead of cadence might be more appropriate if:

• You struggle to get regular customer engagement (so the cost of estimating and decomposing stories to adhere to a sprint timebox is not buying you information)  
• You deliver a service, so “Done” means deployed, and continuous delivery is preferable to output cadence because it minimises deployment lead time and batch size

--------------------

*The many creative approaches to extending Scrum when faced with this problem are not a topic for this post. Suffice to say that most trade one cost for another (for example additional handovers between teams or carrying undelivered product inventory) and for me the current coexistence of many methods implies that the jury is still out.