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)
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)
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)
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