2

I will be soon taking over management of a 10 member team. I will continue to code myself to another project and generally be available for the team for any issues surrounding processes or escalations. I will also be responsible for code review of some of the tasks.

For some context, the team does development work on task basis. We typically get a task from a Customer Relationship Manager for, let say, a report request. This will involve fair bit of coding in SQL and some wrapper code on top of it. The challenging part here to write the SQL, unit test, perform code review, and then send it for testing.

We have a turn around time of 15 days for every request. 15 days include, time for estimate (1 day always), coding (including peer code review and change cycle), and QA, patch to production on a daily build.

With this in mind, I would like to come up with a metric called "Efficiency" of the queue.

What typically happens is, when a task comes in from the CRM, it needs to be estimated for coding effort. Once the estimate is approved (1 day max) it moves to the coding / development step.

Now, developers in my team have the habit of picking tasks as they come and typically each one has 3-4 tasks in his/her queue. This sometimes leads to a situation where a task, though simple, sits in his / her queue in a wait state. At the same time, some of the other developers may have completed their tasks and might be waiting for another. By habit, the developer who originally picked the task doesn't let it go off his / her queue. It's not a bad thing, as we have always been able to adhere to the 15 day TAT.

However, I'm looking at ways to organizing this queue so that we avoid the unnecessary wait time and thereby increase the efficiency of the queue. This will also lead to a gradual reduction of the TAT from 15 days to say, 12 days.

How can I calculate the efficiency of the queue?

I can fetch reports around the start and end times of each stage like: Estimate, code, code review, QA, recode (if any bugs, or customer is not happy, or change or requirements).

It would be good to handle this efficiency calculation with as much less human intervention as possible, as it would have less confusion and it will also be transparent process to anyone in management to understand the metric.

Any thoughts or suggestions from anyone of you here?

Thanks in advance.

  • 4
    The problem appears to be the queue. Devs are cherry picking the ones they want and then holding onto them. Why not just have a pool of tasks and devs pull them one at a time to work on them? – Robbie Dee Feb 18 '15 at 12:10
  • 2
    It sounds like you already have your efficiency metric (average turnaround time) and idea of what might be the problem (tasks sitting idle in queues). What you really need is to work out how to encourage the devs to not pull tasks from the global ist into their own queues (start by finding out why they're doing that - to get the "best" tasks?) – jonrsharpe Feb 18 '15 at 13:18
  • What a nice way to work... cherry pick only the tasks you want. Perhaps people are ranked by the number of tasks they complete? – Frank Hileman Feb 20 '15 at 16:43
  • Thanks for your suggestions. We have decided to experiment with devs taking one task at a time, complete and go ahead with the next one. Need to experiment this and see how it goes. Other soft factors that I need to be aware of are, there are some tasks that are new requests, and some are tweaks. I need to also make sure that they get a good mix of new requests - which are relatively complex - and tweaks. – prabhu Feb 22 '15 at 3:51
  • @prabhu, How has that experimentation gone? – David Jul 13 '15 at 23:16
1

How can I calculate the efficiency of the queue?

The only queue that you mention are the individual queues of developers. Those queues are something to control, rather than something to measure. You need to restrict the number of tasks that a developer is allowed to "pick up" and add to their queue. If you want to measure something, you could measure:

  • Turn Around Time for each task. (recorded at task completion)
  • Queue size, for each developer. (recorded each time a task is completed, or added to the queue)

Tracking queue size will allow you to identify how often developers are adding more than your recommended number of task to their queue. It will also allow you to identify how often a developer's queue goes to 0, while someone else's is greater than 1. (which seems to be the main problem, from what you describe.)

If you want a simple metric from this, it might something like: "For how many person-hours, during the reporting period, did some queues equal zero while another queue was greater than one?" (having actual data and an SQL statement would be more explicit than this plain-English... but I think you get the idea.) The bigger this number... the less efficient the process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.