Stop Booking Developers

Introduction

If your organisation is booking developers then your quality could be better, your delivery could be faster, and your developers could be happier. 

Organisations with digital/development departments will very often have projects, maintenance, support, and emergency work. When trying to mix these types of work, common questions you will hear include: How is this work scheduled? Who is working on this task? If your company is asking these questions then you are doing it wrong. 

Class of service Issues

Projects & Large Features

Note: I tend to lump Projects and Large features into a single category as the development cycle tends to span many weeks. Projects tend to take months.

This type of work would typically be booked in for specific developers to start on a specific date. That sounds quite normal, but what happens when their current work is taking longer than expected? What if a work item is super hard and a dev doesn't know how to do it by themselves?

Support & Maintenance 

Support & Maintenance work is typically small and might include small-medium features. The timing would likely be hours to days and is normally scheduled for specific developers to work on. That sounds quite normal, but what happens when they are sick, or are taking longer on previous tasks?

Bugs & Emergencies

If bug is not critical then it is common to schedule it in the same way as Support & Maintenance (see above). If the severity of a bug is high, then you will often see devs pulled off from other projects / work so they can deal with the emergency issue. That sounds quite normal, but what if the emergency is super hard to diagnose by a single person? Also, didn't you just kill the velocity of another piece of work?

The Problem with Booking People

All of the scenarios above have been examples of optimising for utility. As you can see, the practice of booking specific people for specific work is very fragile and susceptible to variances (eg. sickness, delay). Another important issue is that very often devs need help from other devs. How does this affect the other work?

If you are booking developers then you might often see Project Managers fighting over "resource". This is really dehumanising for their colleagues, and causes a great amount of unhappiness.

A better approach is to forget about booking individual people, and start thinking about how to optimise for throughput. After all, it's the delivery (throughput) which the customer requires.

Optimising for throughput

The first thing you need is a mindset shift. Forget about booking people. Throw this practice out the window. It's full of problems. The key is to have a pool of developers who organise themselves to adapt to the situations. 

When developers self-organise this will often involve 2 or more devs swarming on a single work item. For example, it is very common for a single dev to take 2 hours to find a solution to an issue, where 2 or 3 devs working together might solve it in 10mins. This is optimising for throughput. Do the math!

When developers self-organise, the work will be done quicker, and actually be better quality as the devs will need to come to a consensus about the approach. There will be less bugs!

Kanbanizing Bugs & Emergencies

In this situation we have a team of devs who tackle tasks together like a wolf-pac. All you need to do is line up the work in priority order, and they will handle it.

If and emergency comes in then it goes to the top of list. Just notify the wolf-pac and someone / some people will deal with it. 

Kanbanizing Support and Maintenance

This class of service can be handled in the same way as Bugs & Emergencies. Depending on your requirements, you may have a team that can handle small work from several projects. This is ideal as it spreads knowledge among many people. Depending on the situation (eg. size of team), you could merge this team with the bugs and emergencies team. The key is to have enough devs to actually swarm on work.

Rotating For Projects and Large Features

But what about Projects & Large Features? Shouldn't you "book" those developers? Well kind of but not really.

For example, every project should have a technical lead. However, it doesn't mean that they need to be developing. They can take a technical oversight of the project, and attend initial meetings. In fact, I recommend at least 2 technical people attending all meetings. So you really only need to ask the devs who will be the tech lead.

The devs on a project should come from a rotation of the the other teams (Bugs & Emergencies, Support & Maintenance). Obviously you need to have enough devs for all classes of service otherwise they cannot rotate. When some work comes in that requires you to augment your capacity, then the new developers go into the pool, and the existing developers will help decide who is best suited for the new project.

But When Will It Be Started?

I have been in situations where people are pushing for work to start. This inevitably means stretching out the developer pool to only 1 developer per task. This means no more wolf-pac, and no more swarming. It is totally bonkers!!!

Asking "when will it be started" is the wrong mindset. It means nothing without knowing your Cycle Time.

The questions should be "What is our Lead Time?" and "What is our Cycle Time".

This is a very easy question to answer. Based on the current team, they will have a known average throughput. If a team delivers 5 items per week, with a standard deviation of 1, then 20 items will be delivered in 4-5 weeks. This is our Cycle Time. If we already have 5 items in the pipeline from a previous set of work, then our Lead Time is about 5-6 weeks. I hope my maths is correct :)

You don't need a gantt chart or even a burn down chart to figure this out. More on this in a later post.

To find out more about Kanban and statistics, check out Lean Kanban University.

Final Thoughts

Booking developers comes with so many problems. You will constantly be chasing people, asking when people will be available, wondering why another work item is taking too long, appologising to clients etc. Creating developer pools really elevates all of this stress. Using Kanban to manage workflow also gives you very clear statistics of how the workflow is going. 

I hope you have seen the benefits of optimising for throughput. The work output will be more predictable, faster and better quality.