Input Queues => More Output

One of the first ‘quick wins’ that we’ve implemented is to let the development team manage their own workflow. A bug tracking tool was in place when I arrived (a good thing as there were a LOT of bugs, but more on that later) but the process in place was for Project Managers to ‘manage’ these bugs by assigning up to three bugs at a time to any given developer.

Maybe it gave the PMs some sense of security that ‘all bugs are assigned, therefore we will fix them and deliver on time’ but I’d argue that this is a false sense of security.

There are a few other things wrong with this approach:

  • How can a developer be working on three things at once?
  • How does the PM know the best person to work on a particular bug?
  • Not all bugs are equal – one might a be a tiny copy change, another could mean a fundamental problem in an important component.

We resolved this by introducingĀ the concept of a prioritised input queue. Between us, we (Dev Team Leads) and the PMs would triage new bugs into the queue, constantly re-prioritising it so that we have collective control of which bugs get looked at next.

The developers then just have to pick the next bug off the list that makes sense for them to work on. We’d usually set some rule like ‘you have to pick from the top three bugs’, so that Developers have some control and ownership of what they work on, and still ensuring they’re working on the one of the most important things for the business.

In our case the input queue was a physical one – a new column on the Kanban board that’s in place on our giant whiteboards. We’d add a new post-it to the input queue for each bug triaged into there.

This worked well as it reduced the amount of time wasted in context-switching every time a developer was ‘assigned’ a new bug, and each bug got to the relevant person more quickly and with less fuss. The hardest part was persuading the PMs to relinquish the perceived control that they had over the process.

By introducing the input queue, we were able to demonstrate that we’d be able to waste less time, and therefore fix more bugs, by managing our own workflow.

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