The Freeway Analogy

We often find ourselves talking to executives, managers, or product owners about capacity and flow.

Do you know what the capacity of your software development teams are? And how does work flow into these teams?

It helps to think of your teams capacity as a pipe with a certain width. Is there a dam on the one side of millions of projects waiting to be done? If so, that’s a lot of wait time before the work will be done, and potentially many clients waiting for a long period. More likely the team will be asked to tackle more work that their capacity allows and this can cause thrashing.

An analogy we use to illustrate this is a freeway.

Scenario 1 – an accident on the freeway

When you travel on the freeway trying to get from home to work and there is an accident, what happens? For most people, the workday just continues and they slot in once they arrive at work. It’s an exception. You definitely don’t adjust your work commute to now everyday cater for an accident because most days there isn’t one.

In software teams this is the equivalent of a production issue that derails the sprint. It should happen as an exception, not an everyday event. Thus your velocity should be less when this happens. (If this is happening every sprint – well, thats another story – but try our podcast for some suggestions).

Scenario 2 – the fully utilised freeway

Think of a fully utilised freeway. What does that look like? Peak hour traffic uses every little bit of space on the freeway – its a big parking lot. And the time it takes you to travel from A to B is long and frustrating.

As city planners – you would want to have the freeway in use, but also have the commute between A and B be a reasonable time. Thus, an optimised freeway has some space between cars, to allow for them to pick up some speed and travel the distance between A and B in a reasonable time.

In software terms this space is slack time. If the teams have every minute of their day booked against projects then they have no slack. No time to improve their process or figure out a new way of doing something. Instead they are probably context switching and just grinding out code without (or with very little) thought. Also – should something go wrong with a requirement, the team has no wiggle room to address that problem. This results in everything else either taking longer or in the team ignoring the problem.

Scenario 3 – making the freeway wider

As city planners we realise that the freeway between A and B is used a lot and usually at full capacity. To make this flow better we realise that we need to widen the freeway and build an additional lane. Have you experienced this ever? What happens next is a bit of chaos and a lot of traffic as usually roadworks require one of the lanes to be closed while the other is being built.

In software terms this is when you decide to grow your teams. It takes capacity to build capacity. New people need time from the experienced developers to get familiar with the domain and the code base. This takes up all of the new developers time and a lot (more than you think) of the current developers time. Thus their capacity goes down until the new developers are more comfortable. There are some ways to speed this up – pairing, hiring experienced developers – but even then, capacity will be decreased for a while.

Scenario 4 – the bus lane

Some freeways have bus lanes or lanes for commuters with 4 or more people in the vehicles. Essentially, this rewards car-pooling and public transport and punishes single person vehicles. On our freeway the buses can drive much faster than the backed up normal lanes in traffic.

In software terms we look at how to prioritise certain work so that it can be completed faster. Ideally we want to prioritise high value work. Do you know what the ROI (return on investment) is for each business feature? What about for each project? ROI is really tricky to calculate on some projects. If that describes your project – start with cost. What will it cost you to build this business feature? (To do this you need high level estimates and a stable velocity).

Given these four examples, think about your team’s freeway. Is it flowing fast, prioritising high value traffic, or blocked up with roadworks and 100% utilisation?

---

To get great results with Scrum, you don’t just need a good team you need a great Product Owner that can optimise the value the team deliver.

Our online course for Product Owners will teach you how to get the most from your team by managing and grooming your backlog effectively, learning how to prioritise, understanding your stakeholders, release planning with confidence and measuring ROI.

You can watch a free chapter here: http://growingagile.thinkific.com/courses/PO-optimising-product-delivery

---