queue n.
1. A line of waiting people or vehicles.
2. Computer Science
a. A sequence of stored data or programs awaiting processing.
b. A data structure from which the first item that can be retrieved is the one stored earliest.
intr.v. queued, queu•ing, queues
I was reading a Harvard Business Review article the other day on innovation and product development. The focus was on internal product development teams, but much of it directly applies to software development as well. It would be rational to have a Project Manager maximize the amount of daily development time to a project. Less bench time equals more forward progress on the project. The article I read suggests that by over allocating daily developer time you're more likely to cause delays, undermine quality and raise costs.
Let's first clarify what types of projects were talking about. The projects that are subject to these findings are ones where tasks are unique, project requirements change, and the output (software code/solution files) reside in multiple places at the same time. In short, custom development or highly customized enterprise server implementations.
Queuing Theory
Queuing theory is the mathematical study of waiting lines. The graph below illustrates the effect on waiting time as resource utilization increases.
The logic for maximizing utilization seems pretty obvious and elementary. A busy software development firm who utilizes its people effectively will be much faster and more efficient than those that don’t. Here is where that logic has potential to break down and not work.
Variability in development work
Many aspects of application development are unpredictable. We run into variances on how long it takes different developers to do the same work, when external dependencies will actually arrive and how tasks should ultimately be sequenced. If we were doing assembly line work, we'd have a 5% project length extension for a 5% increase in work (scope creep) or a 5% project delay. Since we're not doing predictable assembly line types of work we're subject to the impact of work queues/logjams on the project.
Impact of queues on productivity
When utilization is high, partially completed work can sit idle, waiting for resource availability. The queues can delay feedback, which can cause developers to follow unproductive paths longer. Queues can reduce the nimbleness of the organization. Consider a client UAT example: the client identifies a show topper issue that impacts further testing. The Project Manager then has to fire drill to get the correct resources available to resolve the issue. This seems so obvious, but it’s amazing how often this happens.
So, what can we do?
Make sure we have good visibility of the project backlog. It's difficult to fight a problem you can't see or measure. A granular and quantifiable inventory of the remaining work empowers the resource planner.
Process work in smaller batches. Smaller, more frequent deployments are quicker to test. They are less impacted by utilization (queuing) constraints. They also enable the project stakeholders to validate work or raise issues quicker. Quicker testing feedback means we can adjust quicker to issues.
Build in some capacity buffer. 3M schedules at 85% of capacity. Google is famous for allowing their developers to work 1 day per week on internal projects. By adding in this internal project flex time, we can optimize the amount of 'downtime' that developers have, particularly right after a deployment has been released for review.
Ensure that ALL stakeholders understand and agree to the project schedule, before the project starts. It's important to understand the loaded cost/consequences of missed deliverables during a project. Missed deliverables without the corresponding project extension equate to the same effect of over-allocating the project team.
Resist the urge to add scope into a project once it has started. It's much better to iterate more frequently and release more frequent deliverables of smaller functional enhancements.
Software development firms have long battled the unintended consequences of scope creep & project delays, but staying agile and making sure the project queue are visible at all times, keeps the project and its resources in check. Ongoing communication with clients and iterating smaller, more frequent deployments will ultimately minimize the risk of going over budget or past deadlines and will keep internal processes running more smoothly.