The Agile Taxi Driver

Imagine yourself as a taxi driver, waiting at the front of a taxi rank for your next fare to who knows where. You've been in the business a long time and the city's streets feel like old friends. All of a sudden your rear passenger door opens and a new customer starts to climb into the back seat.

The passenger starts with a question, "how much is it to the airport?"

Your response is almost automatic these days, "about a hundred, give or take," you say.

"Great, let's go."

The journey starts off quietly with the passenger looking out her window and around the cab. After a while she notices a sticker on the dash that states the passengers charter of rights. The charter lists a number of rights, one of which is the right to choose the route to the customer's chosen destination. Armed with this new information your passenger gets your attention and asks you to take the next left.

As a responsive and dutiful driver, you take the turn as instructed, it's her fare after all. The customer is happy with you and she sits back for a moment basking in the new power that she has been granted. A minute or two later and the passenger issues another instruction, "hey, take the next right and then the next left." You respond and follow the directions to the letter. Everyone is happy, the customer has a taxi driver that is following her instructions and you have a passenger that is pleased with the service you are providing; obviously there is a good sized tip in your future.

The trip continues in a similar fashion for some time. That is, up until the time that the passenger notices the meter has just passed $75. Looking outside, the passenger isn't quite sure where they are, but one thing for certain is that there is still a long way to go to the airport.

"How much is it to the airport from here," a slightly anxious passenger asks.

"I'd say it's another 50 or so," is your immediate reply.

All of a sudden the mood in the cab changes, the once happy customer is clearly angry for some reason. "What do you mean it's another $50? You said that it was going to cost $100 to get to the airport and now you say it's going to cost $125? Are you trying to cheat me?"

"Wait a sec, you made me go the long way round, of course it was going to cost more," is the first thing you can think to say.

"Well, if I had known that it was going to cost me more to go this route I wouldn't have taken it. You should have told me, this is clearly your fault. I'm not going to pay an extra cent."

At this point you are wondering what has gone wrong. You've done everything asked of you and now you're going to lose money because of something that you weren't in control of. There is no way that you can still get to the airport for the original estimate, but the customer is not willing to listen. How did you get here? How could you have prevented this? Is it too late to get things back on track?

This type of situation comes up time and time again on software projects, whether they are run using a waterfall process or an agile methodology. As software delivery professionals we're often asked to estimate the size of a project at the start. We have a view of the destination that the customer has in mind, but we can't always control the route in which we get there. Agile methodologies are often interpreted in a way that place all decisions about what to do and when into the hands of our customers. Our customers are best placed to make priority calls because they have the business context from which to decide. However, it is important at these times to expose factors that affect the decision that one party might assume the other party to be looking after. 

In the example above, the customer assumed that the driver was keeping an eye on the cost of the trip, while the driver assumed that the customer knew that a different route would mean a different fare. Clearly both parties cared about the cost of the trip, but neither party raised the issue. Would it have helped if the driver pointed out the increased cost of each turn as the customer issued their directions? For the most part, such feedback isn't constructive and would have come across as poor customer service. The driver could have also refused to take any turns, simply saying no. This is likely to have led to a hostile relationship with the customer with the trip cut short, a complaint made to the taxi company, or something similar. Instead, the driver is the person armed with the most experience in this situation and could have helped the customer balance their immediate needs against the real intent of the trip, i.e. getting to the customer's destination. The driver had the experience and the knowledge necessary to present better alternatives to the customer. Instead of refusing to make a left turn the driver could have suggested that a right turn would avoid traffic on the next block and keep them on time and on budget for the journey. The intent is not to take the decision out of the customer's hands, instead our intent is to help the customer make the best decision given all of the relevant information at the time. 

Few project teams realise that they are the ones in the driver's seat when it comes to delivery projects. It is our job to help get our customers to their destination. It is our responsibility to regularly communicate with our customers, to provide continuous feedback, to adjust our course if we get off track or if conditions change. And we need to do this while keeping everyone focused on the destination, not just the journey. Following an agile methodology is not about abdicating responsibility to the business for all decisions as we see too often, it is about owning the outcome in partnership with our customers so that we can achieve our business objectives.