Synchronized Sprint Cadence: Thoughtful Decision or Cargo Cult?

Participate in LinkedIn Discussion

What is Cargo Cult?

It is a term used to describe certain religious movements that emerged primarily in Melanesia, particularly during and after World War II. These movements arose when indigenous populations, observing the influx of material goods (“cargo”) brought by Westerners, believed that these goods were of divine origin. In an effort to attract more cargo, they engaged in rituals and constructed symbolic replicas of Western technology, hoping to summon further deliveries.

What is Enterprise-Wide, Synchronized Sprint Cadence:

Generally speaking, an enterprise-wide, synchronized sprint cadence is an attempt to put all teams on the same schedule, so that they can start and end their respective sprints at the same time (day).

Before discussing some strong(er) and weak(er) reasons for choosing this approach, we need to look at a minimal list of assumptions that would make the whole idea of sprint cadence synchronization relevant:

• A group of people that merely reports to the same line manager is not considered to be a real team.  A real team, is a group of people that work on something together, co-own, co-create, and deliver together, at the end of the sprint.
• Teams understand Scrum, at least in theory, and have adopted the idea of a sprint – a fixed timebox.  Notably, for teams that use Kanban, the idea of sprinting may not be relevant, as there are no sprints in Kanban but rather, a continuous flow of work.
• For teams that still use waterfall planning and execution, the idea of sprinting would not be applicable, alltogether.
• For teams that have specific SLAs with third parties, such other team(s), external vendors, suppliers, users or customers, sprint synchronization would have to cascade down the chain of relationships, to all parties involved.
• Sprinting (incremental, time-boxed development) is a useful approach, given an industry type/type-of-business.  For example, in construction, this may not be of a huge benefit.

Strong(er) reasons to synchronize:

• Sprint Planning (multiple teams) – multiple teams, together, meet to discuss the ‘what’ (SP1) and the ‘how’ (SP2) for the next sprint, by picking product backlog items from the top of a shared product backlog. During Sprint Planning 1 (SP1) usually, a short session, a product owner (only one, no surrogates, duplicates or proxies) answers minor, lingering questions and defines a Sprint Goal. During Sprint Planning 2 (SP2), each team creates a detailed technical plan of work, to get each PBI to a ‘done’ state (related reading/videos on DoD) the items and plan of action or tasks that comprise a Sprint Backlog, for each respective team.
• Multi-team PBR – is a key sprint event for well-aligned, coordinated, and adaptive teams that collectively work on the same Product, for the same Product Owner, out of the same Product Backlog. During the event, attendees include all members, of all participating teams, and may also include subject-matter experts, users, customers, and a Product Owner. During a multi-team PBR, teams increase shared understanding, exploit coordination opportunities, align estimates, and increase adaptiveness across teams, as well as perform the following activities:
  • split of big items
  • clarify of PBIs until they reach a DoR state
  • estimate items in terms of size, “value”, risks, and other relevant factors
  • identify strongly-related items that suggest shared work, common work, or coordination
  • mix people from different teams into multiple groups, for better knowledge cross-pollination
• Pair & Mob Programming – collaborative software development practices that involve multiple developers working together on the same codebase, enhancing code quality, knowledge sharing, and team cohesion. This is done by two or more developers that work together on the same task, at the same time, in the same space, and on the same computer. Developers may belong to the same team or different teams that work very closely together, e.g. on the same product, in the same sprint.  Some typical benefits of this approach that lead to improved technical excellence,  are:
  • Improved code quality through continuous review
  • Accelerated knowledge transfer across the team
  • Diverse perspectives leading to innovative solutions
  • Enhanced team alignment and cohesion
  • Faster problem-solving with two perspectives
• Communication Through Code (multiple teams) – continuous integration, with each developer having his/her code checked in to a central repository mainline (head of trunk).  Something to keep in mind: branches are an unnecessary complication that should be avoided, if possible. Each team member (product developer) checks in their code as frequently as they can, multiple times a day, as well as gets updates from other developers (by check out their code). Clean code  practices is very important here, since in order for developers to effectively communicate through code, it must be clean/readable.  Communication through code is important for developers that are on the same team, as well as different teams, especially if they work on the same product.
• Sprint Review (multiple teams) – similar to PBR, it is very effective to conduct a sprint review as a diverge (bazaar)-converge (summary) event. With ALL product (a.k.a. feature) teams, product owner, customers/stakeholders/users in attendance, everyone reviews a delivered PSPI, focusing on the whole product. There is no blame-gaming for failing a PBI or missing a sprint goal (teams will discuss it during a retrospective). This event  is to discuss what has been delivered, and adapt to changes, if needed, with having the whole product focus in mind.  All teams (a.k.a. product teams, a.k.a. feature teams are in attendance).

Weak(er) reasons to synchronize:

• Metrics – chasing numbers (a.k.a. vanity metrics) is dangerous.  Relying on complex formulas that leverage vanity metrics for calculations, is even more dangerous.  Frequently, organizations collect measurements that may appear impressive but lack meaningful insights and weakly reflect reality. Vanity metrics may lead to:
  • Misleading Success Indicators – impressive numbers, but without context about business improvements
  • Encouraging Counterproductive Behavior – prompting teams/people to take actions to boost numbers rather than actions that add real value. For example, if developers are rewarded, based on a number of tasks completed, they would intentionally create too many small tasks, to create an illusion of voluminous completion.
  • Obscuring True Performance: Relying on vanity metrics can mask underlying issues and make executives focus on wrong things, and by doing so, develop a false sense of achievement.  As Albert Einstein once said: “not everything that can be counted counts, and not everything that counts can be counted“. It is important to focus on actionable metrics that align with core business objectives and provide genuine insights into performance and growth.
• Reporting– typical reports provide data fixed at a specific point in time. Heavy reports take a lot of time to review and take away form executives’ ability to actually come to ‘GEMBA‘ (trenches) and observe work in action. Some additional problems, when relying heavily on reports:
  • Lack of Real-Time Insights – since reports do not reflect current conditions but rather historical data. In fast-paced environments, relying on outdated information can lead to decisions that are misaligned with the present situation.
  • Time-Consumption: manual (re)generation of reports, to collect the most recent data, is time consuming, labor-intensive and error-prone.
  • Scalability Challenges: As organizations grow and data volumes increase, reporting systems may not be able to keep up with growing sets of data and/or mix data that is not relevant
• “Enterprise Velocity”– velocity measures the amount of work a team completes during a sprint, assuming that work delivered (PSPI) is user/customer-centric and, therefore, produces business an OUTCOME (potentially ‘monetizable units‘). If there is only high OUTPUT but no outcome, then most likely, a team measures its ‘speed’ (of delivery).  When trying to apply the concept of velocity measurement to the whole company (enterprise-level), the following challenges may arise:
  • Velocity (Speed?) Variability Across Teams -since different teams may use varying scales of measurement, this leads to inconsistencies. Aggregating these disparate measurements in one all-inclusive number, leads to creating even more meaningless data.
  • Misinterpretation of Metrics: “worshipping” velocity, as a key performance indicator will encourage teams to prioritize quantity over quality. This may lead to unfinished work, technical debt, and a deterioration of quality.
  • System Gaming and Misuse – using velocity as means of measuring teams’ performance can lead to unhealthy competition, leading to practices, like inflating story points to make teams appear more productive.  To effectively scale agile metrics, proper organizational conditions must be created. Above all, stands out a set up, where multiple teams can refine and estimate work together.
• Dependency Management – one of the biggest pitfalls of dependency management in software development is an assumption that an “effective management” is the main goal. It should not be. The goal should be dependency reduction/eradication, especially, with respect to asynchronous dependencies (as opposed to synchronous). Some additional disadvantages of excessive dependency management:
  • Maintenance Overhead – managing too many dependencies can complicate a development process and lead to creating activities/tasks that are timely, tedious and costly.
  • Psychological Stress – for developers that constantly face the need of managing complex interdependencies, leading to frustration, shifting a blame and leading to “us vs. them” mentality.
  • Local Optimization – by those people that are responsible for e.g. intra- and cross-team dependency management (e.g. dependency managers, coordinators). These people are not motivated to reduce dependencies, as it would mean reducing the need for their own role.
• Management of Shared Resources – is probably one of the most harmful, self-inflicted wounds from which organizations suffer today. First, it is important to note that humans are not resources but rather intellectual assets and companies should adjust their language accordingly. Here are some of the most common challenges, seen in situations, where developers are not dedicated to teams and are expected to be responsible for multiple tasks, working on multiple activities:
  • Loyalty Conflicts – developers that are expected to commit and deliver to multiple teams, while reporting to multiple managers, could be stuck in a tough situation of choosing, whose priorities are higher.
  • Uneven Workload Distribution – developers face the challenge of workload balancing, resulting in overcommitments and overburdening, further leading to psychological overload, stress and drop in productivity.
  • Increased Communication Overhead – developers that are shared by multiple teams/initiatives also create bottle necks and hard dependencies for other developers, further leading to issues with planning, commitments and deliverables
  • Lack of Knowledge Depth – developers, being responsible for multiple activities, reporting into multiple managers and focusing on different (conflicting) priorities have a much lower chance of learning any current or additional domain. Due to attention and focus dilution, developers’ ability to learn (as well as teach others) is lowered.

Conclusion:

When deciding that your entire organization, and all of its technology teams, need to synchronize their sprinting cadence, please think carefully about deep, systemic root causes for why you are making this decision.  Understand the true impact of your decision and its real benefits, prior to “flipping a switch”.

Do not submit to a peer pressure (“others are doing it, so we should do the same”) and do not become a part of a corporate cargo cult.