TLDR - Programmers are bad at giving time estimates so we shouldn’t ask them to. To be more efficient an organization should experiment with a process that simply places 3 items in each developers ‘PQueue’ and let them finish it.
PQueue
My tech teammate was up from Austin this week and suggested that our dev team try out a process similar to what his old team used at Demand Media. The basic idea is that instead of doing agile or waterfall, Demand Media simply assigned each developer a queue of the highest priority tasks they could be working on at that moment (with a cap of 3). I would like to dub this method the “Priority Queue” Development Process or ‘PQueue’ for short.
The Business - Programmer Divide
The business world generally runs on an organized schedule. You set meetings, sales calls, ad buys, deliveries, etc at predefined times and generally meet those obligations.
Since schedules existed long before software, most organizations try to ram their dev teams into something that nicely fits with the traditional business world. Times, dates, estimates of completion, etc. Programmers then run around behind the scenes trying desperately to meet the semi-educated estimate they gave the project manager two weeks ago. People get stressed, dates are missed, and the end result is usually a programmer ‘debriefing’ in a room full of non technical people for a couple hours trying to explain why they missed the deadline despite burning themselves out over the weekend. The very next day another ‘planning’ meeting is usually created so that the developer can try his best to give better estimates this time around before starting this hair-brained process all over again.
It’s an undeniable truth that most programmers are bad at estimating and that every programmer has missed a deadline at some point in their life. So why do we continue to measure success or failure based on whether a programmer successfully hits a time estimate? And worse yet why do we waste 5 to 10 hours a week of programming time in meetings for a process that is so clearly broken?
Enter The PQueue Development Process
As described earlier the process is very simple: Throw out all those planning/debrief meetings and give each developer on your team a list of 3 tasks they should be currently working on.
This makes life for a programmer simple. The three tasks in their queue are the highest priority item for them. They don’t have project managers pestering them about status updates or worry about missing an estimated deadline. They simply have three tasks and uninterrupted time to do them in the shortest time possible. Once a task gets completed you move it off the dev queue, into the QA queue, and then move on to the next highest priority item in your team wide ‘Priority Queue’.
What’s a Project Manager to do?
PQueue development makes a project managers job more focused and streamlined as well. The project managers main focus is to ensure that there is a ‘Priority queue’ sorted in priority order for their developers to pick tasks off of.
Additionally a project manager should ensure that their team has uninterrupted time to code. This means running interference on requests from other departments, working with QA to parse bugs, etc.
You pay programmers to program. Let them do their job in the most effective way possible.
Won’t this hurt a business development person?
There are certainly arguments to be made that this would hamper a bizdev employee; however there are positives. You may not have dates, but you do have an organized list of the companies priorities. This gives you a way to intelligently speak about the direction of the company without tying yourself down to time estimates that are bound to disappoint.
Do you already do ‘PQueue’ style development? Are you interested in learning more?
If you are interested in learning more about PQueue development style techniques or are already doing something similar I would love to hear from you in this survey: