I was once part of a team at a consumer-facing technology company, who described themselves as incredibly fast-paced, operating within a rapidly changing environment. This team was smaller (4 developers in a 10-person business unit), so I expected the ability to get things done quickly to be one of our strengths. Upon joining, I was surprised to hear grumblings of low productivity and velocity. Essentially, not enough was getting done, and after managing a few two-week sprints, I quickly understood why.

Sprints started on Monday mornings, after priorities were freshly set from the previous Friday. However, at any point during the sprint, a business stakeholder could sound the fire alarm and ask for an additional urgent ticket to be added to the sprint. Wanting to please stakeholders, the dev team would absorb the extra work, reallocate resources, and adjust the release schedule to accommodate for this change.

The impact was disastrous! Nobody was accounting for the tradeoff costs: extra work was added to a sprint, but nothing was removed to balance the workload. Furthermore, but nobody measured the effort required to transition off a current ticket, ramp up on the new ticket, and transition back to finish the previous ticket. The result was stagnating velocity – sometimes only 50% of tickets in a sprint would get completed. Another manifestation was decreased engagement by the dev team – if you know ahead of time that priorities are going to suddenly shift, why bother trying to finish a ticket if you know you’re just going to get interrupted halfway through with a new fire?

Upon recognizing this problem (and several others that could be their own blog posts), I made several key changes to the development process. The first was working with business stakeholders to identify and calculate concrete KPIs of initiatives to improve prioritization. Another change was to create a triage process for disrupting the current sprint with new work, which required a meeting with the stakeholder, myself, and the dev lead. In this meeting, the goal was to understand why the new initiative demanded urgency, measure how the benefit could be quickly realized, and understand what the tradeoffs and costs of transition would be, before making a decision to modify the current sprint.

This change encouraged many new behaviors. Stakeholders began to understand the hidden costs of disrupting a sprint. Now only initiatives that took priority, and could be measured against everything else (e.g. instant ROI) modified a sprint, which occurred less frequently, and everybody with in the business unit clearly understood why. The development team’s productivity increased as well. They appreciated fewer distractions, clearer output expectations within the sprint, and how their work added value to the business unit, which further encouraged them to meet their velocity goals.

Have you ever had to incorporate a new process that helps efficiency? I’d love to hear your stories in the comments section!