illegitimus-non-interruptus

 

… 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. This dilemma was first described in an influential article titled “The Tragedy of the Commons,” written by Garrett Hardin and first published in the journalScience in 1968. — Wikipedia

v      v      v

Scrum teams are often interrupted during a Sprint by changing priorities or problems in the field. 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.

 

The Scrum Team is a critical resource for creating new software and maintaining old software. This makes them a central resource for debugging problems, technical communications with customers, marketing demos, and special projects to serve the needs of everyone in the company. 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 company’s 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 bugs incentivizes the Scrum Team to produce sloppy code with more bugs.

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

 

Therefore:

Allot time for interrupts and do not allow the time to be exceeded.

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

  1. The team creates a buffer for unexpected items based on historical data. For example, 30% of the team’s work on the average is caused by unplanned work coming into the Sprint unexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the interrupt buffer.
  2.  All requests must go through the Product Owner for triage. The Product Owner will give some items low priority if there is no perceived value relative to the business plan. Many other items will be pushed to subsequent Sprints even if they have immediate value. A few items are critical and must be done in the current Sprint, so they are put into the interrupt buffer by the Product Owner.
  3.  If the buffer starts to overflow, i.e. the Product Owner puts one point more than 20 points into the Sprint, the team must automatically abort, the Sprint must be re-planned, and management is notified 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, e.g. to have a Surrogate Product Owner.

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 can adjust up or down with buffer size.

This strategy is independent of the focus on fixing all bugs which arise in the Sprint from backlog items worked on during the Sprint.  It is also independent of bugs assigned to a Sprint by the Product Owner as part ofSprint planning to reduce technical debt. Low defect tolerance increases velocity in general, but exceeding the buffer typically generates at least a 50% reduction in velocity. Common sense must be used to balance these forces. See Whack the Mole.

v      v      v

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.

Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The Product Owner will put any critical items on the Product Backlog.  The team will typically double velocity and get twice as much done in future Sprints.  This typically allows more than enough time to address critical items and often have spare capacity.

 https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: