Illegitimus Non Interruptus*

Cows on Gower Commons.

...the Scrum Team is serving many stakeholders, all of whom are competing for attention from the team. Requests and demands come to the team from management, from Customer A through Customer Z, and from sales and marketing. In addition, work in progress may uncover surprise shortcomings in the product itself that require attention. The frequency and importance of these requests varies over time, and occasionally their volume and urgency are overwhelming.

✥ ✥ ✥

Changing priorities or problems in the field often interrupt the work of Scrum Teams during a Sprint. Sales and marketing demands, combined with management interference, can cause chronic dysfunction in a team, repeated failure of Sprints, failure to meet release dates, and even company failure.

In many ways, the Scrum Team is a community resource that meets the needs of many stakeholders. The tragedy of the commons is a dilemma arising from the situation in which multiple individuals, acting independently and rationally consulting their own self-interest, will ultimately deplete a shared limited resource even when it is clear that it is not in anyone’s long-term interest for this to happen. American ecologist and philosopher Garret Hardin first described this dilemma in an influential article titled “The Tragedy of the Commons,” which was first published in the journal Science in 1968. [1]

The Scrum Team is a critical resource for creating new software and maintaining old software. This makes it a central resource for solving problems that arise during both development and product use, for technical communications with customers, for marketing demos, and for special projects to serve the needs of everyone in the organization. See Work Flows Inward.

Often poor product ownership allows competing priorities in a company to reach a Scrum Team. Some teams have even been bribed to work on features not in the Product Backlog.

In almost all cases, it is desirable to have the Scrum Team ‟eat their own dog food.” If they produce a defect that gets into the field, they need to fix it as soon as possible. Setting up special maintenance teams to fix defects incentivizes the Scrum Team to not be attentive to latent defects.

For these, and many other reasons, a Scrum Team is always exposed to interrupts that disrupt production.

Therefore:

Explicitly allot time for interrupts and do not allow more work than fits within the allotment. If work exceeds the allotment, abort the Sprint.

Set up three simple rules that will cause the organization to self-organize to avoid disrupting production.

This strategy will help the team replan during the Sprint to raise the chances of delivering the complete Product Increment.

• 1. The team creates a buffer for unexpected items based on historical data. For example, let’s say that a third of the team’s work on average comes from unplanned work coming into the Sprint unexpectedly. If the team velocity averages 60 points, the team reserves 20 points for the interrupt buffer.

  2. All non-trivial requests must go through the Product Owner for triage. (Web page spelling errors and compilation errors are examples of trivial errors where the fix is so obvious that there is no benefit from additional business insight. Developers may spend some small, time-boxed amount of time addressing even non-trivial defects before escalating to the Product Owner.) The Product Owner will give some items low priority if there is no perceived value relative to the business plan. The Product Owner will push many other items to subsequent Sprints even if they have immediate value. A few items are critical and the team must complete them in the current Sprint, so the Product Owner puts them into the interrupt buffer.

  3. If the buffer starts to overflow, that is, the Product Owner puts one point more than 20 points into the Sprint, the Scrum Team must automatically abort, the Sprint must be replanned, and the Product Owner notifies management that dates will slip.

It is essential to get management agreement on these rules and to enforce them. The Product Owner must always be available to the team and other stakeholders. In the Product Owner’s absence, the Scrum Team should designate one of its own to temporarily fill that role.

The Product Owner balances the buffer size to balance short-term customer satisfaction with future revenue generation. Often, a Product Owner has third-party metrics on customer satisfaction that he or she can adjust up or down with buffer size.

This strategy is independent of the focus on fixing all defects that arise in the Sprint from backlog items worked on during the Sprint (see Good Housekeeping). It is also independent of PBIs assigned to a Sprint by the Product Owner as part of Sprint Planning to reduce technical debt. Low defect tolerance increases velocity in general, but exceeding the buffer typically generates at least a 50 percent reduction in velocity. The Product Owner must use common sense to balance these forces. See Whack the Mole.

✥ ✥ ✥

These rules will invariably cause individuals to self-organize to avoid blowing up a Sprint, as no individual wants to be seen as the direct cause of Sprint failure.

Even better, the buffer will tend to never be full, allowing the team to finish early and pull forward from the backlog and/or work on removing impediments. This is important because Teams That Finish Early Accelerate Faster. Furthermore, if the team uses Yesterday’s Weather to size the buffer and the buffer almost never fills up, the buffer size continuously gets smaller, making the interrupt problem go away.

Counterintuitively, this does not cause critical problems to be hidden or unresolved. The Product Owner will put any critical items on the Product Backlog. This helps the team increase its velocity and increase the output of future Sprints. This typically allows more than enough time to address critical items and often with spare capacity.

A team exhibits a high degree of Product Pride to pause in its work for the good of the product quality and reputation. Other related patterns include: Product Owner, Product Backlog, Teams That Finish Early Accelerate Faster, Work Flows Inward, and Completion Headroom.

[1] —. “The Tragedy of the Commons.ˮ Wikipedia, https://en.wikipedia.org/wiki/Tragedy_of_the_commons, June 2018 (accessed 6 June 2018).

Picture credits: Shutterstock.com.