Sprint Cadence- To Follow or Not Follow

Problem

Cadence is defined as a pulse or rhythmical flow. Consequently, sprint cadence can be defined as the pulse or flow of key parameters within that cadence. Sprint cadence includes the following four key parameters: start day of sprints, duration of sprints, definition of 'done', and predictability of sprint outcomes. The first two of these four are fairly obvious, while the last two are important points that need to be addressed. If sprint deliverables don't meet the definition of 'done' and are not consumable, then sprint cadence does not help. Similarly, if there is no predictability to sprint outcomes, then sprint cadence won't help either. And in the absence of all four of the parameters, sprint cadence could be seen as a ticking clock with no impact on anything else. Only if all four parameters are met is sprint cadence beneficial. Here I describe the benefits and pitfalls of having scrum teams follow the same sprint cadence.

Actions taken

Benefits

• Microservices and Dependencies- Our software product is built as a set of microservices. Microservices come with the usual benefits of small, autonomous teams continuously and rapidly building new features and deploying them to production. They enable us to share common functionality and reduces feature duplication. While all this is hugely beneficial, the microservices have dependencies between them. A dependent feature, if not delivered as expected, can have a potentially cascading effect on other teams' releases.
• Sprint Planning Time- Let's observe three teams during a sprint. Priority attached to planning by Team A is high as they are planning their sprint. Given their visibility, team B and C gives their best attempt to address team A's dependencies. Subsequently, when it comes to Team B & C's sprint planning, there are some rearrangements in priorities due to new stories that come into their backlog, which leds to changes in the previously assumed priorities of Team A's dependencies. This has an impact on Team A's sprint and could cascade to teams that are dependent on Team A. We can extrapolate this to see what the effect is when the number of teams and their dependencies increase. When teams have their sprint planning sessions on the same cadence, then the focus given to planning dependencies increases.
• Scrum-of-Scrums- Scrum-of-scrum meetings are where the scrum masters of different teams interact twice a week on inter-team dependencies. Since the teams are on the same cadence, they are in various stages of feature development such as development, testing, pre-production, and production around the same time. When the teams meet for the scrum-of-scrum meetings, it is more effective as they can discuss feedback from testing and get things fixed. If some teams were instead pushing to production and others were in development stages, the priorities that they give to inter-team dependencies can be lower.
• Multiple Dependencies- Our application layers which are built on underlying capability microservices can have more than one dependency in a sprint. If the teams were not on the same cadence, the release management for the upstream project can take more time. They may need to wait for one service to deliver a functionality at some point, and then another one to test their integrations. When faced with issues in QA testing, the other teams may have moved onto a different sprint. With teams switching context it may take more time to fix bugs.
• Continuous Improvement- Another question that came up for discussion was whether teams should have the flexibility to lengthen or shorten sprint duration depending on the amount of work they had. To measure improvement, there has to be a constant reference. For example, to measure the speed of a car, the road should not move. The person inside the vehicle cannot observe or measure the movement or speed. The person standing has to observe the speed. Similarly, to measure the team's improvement in velocity, it helps if the sprint cadence is constant. We are not saying it cannot be done with variable cadence, but it becomes a more complex calculation, just as it would be to measure the velocity of the car if the road is also moving.
• Analogy From Nature- The analogy is that the day, week, month, and year are all fixed durations. Cadences can't be extended even if larger pieces of work are slated to be finished in a day as all activities are planned with a natural constraint. Not being able to do it with the calendar isn't reason enough. Our takeaway is that work can be planned based on the calendar's fixed cadence, without being affected by the constraint. This helps us overcome challenges and plan with a fixed Sprint cadence as well.

Pitfalls or Concerns

• Dependencies Tend to Not Be in the Same Sprint- An analogy drawn was based on how we integrate with external APIs. Companies do not integrate with external APIs in the same sprint. The answer was to follow the same principle and treat other teams within a company similar to external products. This question raised by this line of thinking is whether we should take advantage of efficiencies that one can derive from being in the same company. What if one's competitors are able to derive such efficiencies and are faster to market? Hence, this argument has to be viewed alongside advantages of sprint cadence discussed above so that a decision can be made.
• Scrum and Kanban Teams- In an organization there can be different types of product work. Some may follow scrum methodologies and some may follow the Kanban methodology. Due to the nature of the work stream that adopted the Kanban style, there may not be a specific release date. A possible solution is introducing a cadence buffer in dependencies between teams. And planning them one sprint ahead is a common way to solve this.
• All Teams Planning at the Same Time Leads to Chaos- It was observed that panning one's own backlog is an involved task. Adding dependencies in and out of a team into the same cycle, then different planning session can be chaotic. This can be alleviated by the product manager staying two sprints ahead of the team. The product managers and the scrum master can also discuss the upcoming sprint dependencies in the scrum-of-scrum meeting. When these are implemented well, it's observed that the backlog and dependencies are clear and precise. The planning meetings both within and across teams tend to be more organized and less chaotic.

Lessons learned

• Cadence can be compared to the synchronized activities of an NFL team in every play. The quarterback, the receiver and everyone in the team have to be in sync to make a successful pass. The passing of the ball can be an analogy to the delivery of a dependency. When the ball/dependency is delivered successfully, the dependent person can efficiently execute their next steps.
• Teams following the same sprint cadence benefits everyone in multiple ways. Even though there might be some challenges, we believe that they can be mitigated or controlled.

Source: https://www.linkedin.com/pulse/sprint-cadence-follow-ramkumar-venkatesan/