It’s About Time We Did Less

A look at how FIFO and Loudest-First fail to scale

It’s About Time We Did Less

For the past several months, I’ve been working with a team that until recently had the responsibility to maintain a valuable part of our corporate infrastructure. But, that infrastructure has been growing, and that means this team has had more work on its plate than what was possible. As that workload increased, the team tried scaling up some of their existing solutions for prioritizing and managing the work.

FIFO

When you have a team that has more capacity than load, a First-In, First-Out solution works pretty well. This solution also resembles the assembly line and gives the team access to using techniques developed by Ford, Frederick Taylor, and W. Edwards Deming. It makes it harder to apply the techniques of Taichi Ohno and Eliyahu Goldratt.

For a FIFO system to work, there are certain conditions that must be met:

  • The system that provides the work to the team has done the sorting on which work is most important.
  • The team will always have the capacity to complete the work
  • The work is of relatively equal size
  • The work includes repetitive components that reduce solution development windows

If all of these conditions are met, then FIFO is a good fit. FIFO systems are efficient, and I do know of teams that work hard to achieve the above assumptions with the intent of getting to a FIFO work environment. For them, they consider it part of their maturing process.

If one or more of the conditions are not in place, then the team will struggle with FIFO. One of the obvious ways to start seeing when a FIFO team is struggling to pay attention to the team’s customers. If they’re unhappy, there will likely be some communication with emotionally enhanced language. When that happens, we have a name for the prioritization system that often comes with it.

Loudest-First

Loudest-First also has conditions built into it:

  • The person with the most time to be loud is truly the priority and conversely that the quietest voices have the least important work
  • Listening to the loudest voice is efficient (time-wise)
  • Responding to inquiries from the loudest voice is efficient (time-wise)

We could document a few more conditions, but if we just use the above, we can see what it says about human behavior. Human behavior is more or less a constant that can easily prove the Loudest-First priority system violates human behavior in a way that’s destructive for the team and others. One of the smartest people I know has one of the quietest voices. He chooses to listen. He’s also in a crucial role within the company. His work should be what others prioritize but, instead, he quietly integrates with other teams. His work doesn’t always get done first, but it should.

In contrast, other teams will call their work a project and hire a project manager just so they have someone to play the role of Loudest-First. And this brings us to the other conditions I listed: that somehow responding to the loudest voices is an efficient use of people’s limited time.

Moving Forward

There are other techniques available. Thankfully, I’ve helped move the team past FIFO and Loudest-First, and we’re passionately experimenting for the solution that works best for everyone. We’re transparent about the process, and it’s amazing how that transparency helps.

The person in charge of the space is super kind, loves the team, and knows his stuff but, for years, he’s operated in roles where kindness meant saying yes instead of saying no. As we’ve adjusted how we get work done, he’s learned how saying no early is actually being kind. He’s also learned not to say no unless it's necessary. Instead of promising he’ll get things done, he’s now promising that he’ll get things added to the backlog and sorted based upon priority. He’s also promised that the backlog will be transparent and that the customers can view and comment on the work they depend on at any time.

There are some conditions needed to make this work as well, and we’re still exposing and responding to those conditions. Another part of what we’re doing here is we’re not being prescriptive and saying we’re using any particular agile method. We’re in the process of continuous discovery as to what works and that continuous discovery is working.

We’ve been able to deliver more useful solutions to more people than ever before, and we’re just getting started.