Question

I work with a small team (4 developers) writing firmware and software for our custom hardware. I’m looking into better ways to organise the team and better define processes.

Our Current Setup

• Developers are generally working on 2-3 projects at a time.

• We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.

• We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.

• We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.

The Issues

We have a weekly meeting where proportions of time are allotted to each project. “Customer A wants to test feature X next week”, so the required time is allotted. “Customer B is having issues with Y, could developer P drive down and take a look?”, etc.

When we’re busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we’re getting behind on project Z and we all pull-off some long days.

I’m told that this is all quite common for a small start-up in our industry, but I’m just looking for ways to limit the number of “pizza in the office” all-nighters.

Answer 1

Developers are generally working on 2-3 projects at a time.

Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.

When we’re busy, these plans are very loosely followed.

Then why create plans at all?

Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he’s doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)

The next week there will be a realisation that we’re getting behind on project Z and we all pull-off some long days.

If there had been only one developer on project Z anyway, he wouldn’t have been distracted by customer A’s problems.

Don’t think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you’re constantly pulling all-nighters, you aren’t spending enough time away from the office anyhow.)