New Framework - Cadence

Today, let’s talk about cadence. Iterations, Sprints, to have them or not, that is the question.

The “Agile” methods XP and Scrum have explicit iterations (Scrum calls them Sprints), short time boxes within which the team develops an Increment of running, tested software. However, there are “Agile” approaches like [Kk]anban¹ that focus more on continuous flow, with no expicit time boxes. And Arlo Belshee presented a kanban-like process that was iterationless, quite some years back.

Remember our adopted notion of “Whole Team”, the cross-functional, self-organizing team that builds the software. The Whole Team includes someone who is in charge of what to build, variously called “Customer” and “Product Owner”. (At this writing, I’ve not adopted a particular term for this role.) In addition, most teams have stakeholders who aren’t part of the team, but whose opinions (and money) really matter.

The Customer/PO needs to guide the product to be the best it can be within the available time and money. They do the best job of guiding the effort when they can see what’s being built. Now, as the Agile Manifesto puts it:

Business people and developers must work together daily throughout the project.

But working together could mean a lot of things. For them to work together well, the business-side people need to see the Product Increment. Similarly, for the stakeholders to be well-informed, they, too, need to see the Increment. Now in a true “continuous integration” shop, there would be an Increment daily or even more often, and the local business Customer / PO would inspect that any time they wanted. In a less-advanced “Agile” team, an Increment might only be available every few days or every couple of weeks.

Inspecting the Increment is a key part of deciding what to do next (and what to defer doing).

Recall that Scrum has a meeting called the Sprint Review. This is a meeting in which all interested stakeholders review the present Increment and discuss what should be done in the future. This is a key moment for the Inspect and Adapt cycle of Scrum, and a moment of value in any would-be “Agile” approach.

As such, my inclination is to suggest that an “Agile” framework should include a Product Review Cadence, a regular interval, where the team and stakeholders consciously review the running tested software Increment, with an eye to how to improve it in the future.

Quite likely, I’ll also suggest a Retrospective Cadence, where the team reviews how they’ve been doing the work and how to improve.

If I were truly clever, I might call these the WHAT Review Cadence and the HOW Review Cadence. Let’s hope I’m not truly clever.

Whatever we call them, I expect we’ll have Cadences in my view of “Agile”, to review the product, and to review the process.