Senex Rex
  • Team
  • Blog
  • Resources
  • Contact

Breaking into Quality: Prioritization as a Pitfall

Posted on April 1, 2014 by Pablo Rodriguez-Bertorello Posted in Quality, Scrum

Our team kept solving the easy stuff, the big deliverables seemed to take forever, and would inevitably come out with major bugs.  Do the right things right… Why not just do that?  For any one product, a number of people and processes come together.  We automatically operated by priority, and this turned out to be the central problem.  The chart below shows a 66% reduction in our severe bug rate since then.

Severe Bugs: Quality (priority 1-2)

Severe Bugs: Quality (priority 1-2)

It seemed to be the right thing: when a customer reports a bug of high priority, jump on it.  When a server crashes,  jump on it.  When the senior person finds a critical bug,  jump on it.

In our meetings, the teams decided that instead of “Priority” being our call to action, we should “order” our work, always consuming our backlog from first to last.  Yet, we kept jumping on it.

I lead the team to take an innovative approach that worked:

  • The appropriate response time for a request is decided by the recipient, not by the filer
  • The default assignee of every ticket is the team’s Product Owner
  • Every item has a defined Service Level Agreement (SLA)
  • The default level of service is “P – Product Backlog,” meaning the item will be worked on when placed in a sprint
  • The development team buffers their every sprint plan, so that they can handle any aligned emergent items in a timely manner
  • The support team scrubs all customer-facing tickets, so the scrum team is clear on the acceptance criteria; and vice-versa of providing straight feedback to customers of when/if the issue would be resolved
  • Violations of SLA are reviewed in scrum-of-scrums meetings: principally so only priority P is used wherever possible

Some individuals resisted, knowing that priority was their sneaky way to get people to jump on it.  They agreed to try it, and we never looked back.  Our available work priorities became:

Name Description
1 Critical
2 Very high priority
3 High priority
4 Medium priority
5 Low priority
P Product Backlog Item

Effectively, this focused each team on the work their Product Owner ordered for execution – on the basis of value, effort and ROI.  The outcome was a decrease in bugs of all severities, as shown in the figure below.

All Bugs: Quality (green dots)

All Bugs: Quality (green dots)

Lack of interruptions gave the team the bandwidth it needed to tackle severe long-standing problems; some 6 months old or longer (purple circles).  Taking advantage of this, a number of teams came on strong with quality products that have had few or no severe bugs since then.
Challenged Teams Resolved Long-standing Defects (I)

Challenged Teams Resolved Long-standing Defects (I)

In the case of two less adept teams, the software they developed produced new bugs.  With our new backlog system, they were able to recover rapidly (see the blue line inside the yellow circle.)

Challenged Teams Resolved Long-standing Defects (II)

Challenged Teams Resolved Long-standing Defects (II)

Delivering quality products in a timely fashion, to customers that are excited to use them, requires both:

  • Maximize what will not be done
  • Minimize what will be done now: this is distinct from minimizing work in progress, which is usually understood to mean completing work within a given sprint’s time increment (up to 4 weeks.)

Case studies help agile leaders better understand the benefits and challenges of agility. Pablo Martin Rodriguez-Bertorello, Chief Innovation Officer of Exponential, wrote this case study. Exponential is one of our clients. —Dan Greening, Senex Rex Managing Director

Share this:

  • Click to print (Opens in new window)
  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to share on Reddit (Opens in new window)
  • Click to email this to a friend (Opens in new window)
  • More
  • Click to share on Tumblr (Opens in new window)
  • Click to share on Pinterest (Opens in new window)
  • Click to share on Pocket (Opens in new window)
« Senex Rex at Work: February 2014
Forecasting Defined »

Leave a comment Cancel reply

You must be logged in to post a comment.

Continue with Facebook
Continue with LinkedIn

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter




Recent Posts

  • Align to a Driving Purpose
  • Scrum
  • Agility
  • Agile Living
  • Is Agile a Subset of Lean Manufacturing?

Contact Us

Senex Rex
1037 NE 65th St # 80358
Seattle WA 98115 USA
+1 (415) 810-3693

Courses

  • Certified Scrum at Scale Practitioner
  • Certified Scrum Product Owner
  • Certified Scrum Master
  • Agile Capitalization Workshop
  • Short Course: Agile Manager

Key Posts

Scrum

  • What is an Agile Methodology? How does it beat Waterfall?
  • How can I transform my corporation to agile?
  • Strategy Scrum Teams Enterprise Scrum: Scaling Scrum to the Executive Level
  • Release Duration and Enterprise Agility

Agile Base Patterns

  • Measure Economic Progress
  • Adaptively Experiment for Improvement
  • Limit Work in Process
  • Embrace Collective Responsibility

 

Advocacy

  • Develop Agile Managers, or Agile Dies
  • Are We Agile? Answer 5 Questions to Find Out
  • Agile Cancer: Does team-only agile cause developers to quit?
  • Agile Cancer: Stop Whining and Cure It

Advanced Techniques

  • Bulk Estimation
Copyright ©2013-2015 Senex Rex LLC. All Rights Reserved.
loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok