Headway is a measurement of the distance and time between vehicles. For the railway industry, it’s a way of measuring the time it takes a train to come to a complete stop. Too little headway? That means a train could hit another train because it can’t stop in time. Too much headway? Then your train service is slow and choked with angry customers.

For software development, we try to measure the time it takes to finish something. Depending on your metrics, this could be the time to deploy some new code, or the time it takes to launch a new feature, or the time it takes to finish a project.

If we continue using our train analogy, then it’s interesting to note that most of the railways around the world are trying to move from a timetable based schedule to headway based structures. Similarly, modern software teams have moved away from waterfall delivery methods with rigid schedules to more flexible delivery methods, incorporating lean thinking and other software development patterns to allow them to do things faster.

This is all great, right?

Actually, the move from scheduled to headway structuring in the railway community often uncovers higher levels of complexity. Rather than being able to dictate where trains are, based on a rigid schedule planned ahed of time, headway based travel means constant adjustments based on availability of trains, availability of staff, customer flows, maintenance needs, emergencies and a whole other raft of factors. If an organization isn’t ready to handle this level of complexity, or they’ve always assumed that another part of the organization was dealing with it, then the complexity hit can be quite high.

And as railways deal with this ever growing level of complexity, customer satisfaction can take a hit. Why? Often, as railways get caught up in internal factors rather than monitoring customer flows thand journeys, they lose sight of what actually makes customers happy with their commute.

Decreasing headway and being able to run more trains to a station doesn’t mean you’ve solved customer satisfaction, or increased the chance that a member of the public is able to use public transport for their journey. You need to spend time understanding how people use public transport and seeing what they value. They might be willing to trade off a newer train for a faster service. Or maybe an express train can get people there faster. Or maybe a whole number of people have switched train lines, and we need to read to a change in traffic. We need to be able to react to emergent patterns guided by a clearer understanding of what value our service delivers.

In software delivery, it’s easy to lose sight of why a team exists, as a company grows or a project drags on. The team exists not to do more things in a week (increasing headway, or our velocity), blindly chugging through a backlog of work, but to ensure they are building a product that their users truly value.

Great teams do things fast, but they don’t start as fast teams. They work out what a great service looks like, then they get good at making things faster. First you have to lay the tracks, then work out what trains people catch, and only then start getting fast. Don’t just watch the velocity number that Scrum tells you to. It’s a useless value if people don’t want your service.