Customers – Out of Sight, But Still in Mind


A lot of discussion seems to happen around whether pair programming is good or how to do it pragmatically. Ditto on unit testing, and especially test driven development. Oddly enough, I don’t hear nearly as much conversation about the customer role and the common Agile strategy of having an “on-site customer.”

I recently had the opportunity to play the role of the customer recently, and it really cemented in my mind the importance of having good access to your customer. I spent a week on site with the development team and was responsible for answering questions about the requirements. It was enlightening to be on the other side of the fence for once.

The Customer Still Matters

I feel like there’s been a language shift regarding the “customer” role, changing now to terms like “product manager,” but the original principle hasn’t changed. There’s always a need for someone to represent the business — to lay out business processes, help respond to priorities changes, clarify requirements, and answer other questions.

I guess that developers probably don’t talk about this because, unlike unit testing (which a developer can just do on their own without impacting anyone outside their team), access to the customer depends on (surprise!) the customer. Because of this, it falls by the wayside all too often, and a lot teams end up seeing the customer once a week or less frequently. I think these teams have made a mistake, and are letting the perfect be the enemy of the good here.

The “Present” Client

In more than a decade of big-A Agile software development, I’ve only truly had an “on-site” customer once. For the vast majority of projects, you really can’t kidnap your customer and chain them to a desk in your office. And that’s okay as long as you remember what the principle is trying to encourage: an open communications channel and tight feedback loop with your customer. Having clients on-site will get you that too, but if you can’t host them physically, that doesn’t mean you shouldn’t have some other way to achieve that goal.

When you find yourself in the very common situation of having a customer that’s not 100% perfect, who can’t dedicate every working hour to your project, or who has (gasp!) other concerns, don’t resign yourself to only a weekly contact during your iteration meetings. They don’t have to be next to you (no matter how nice that is!) — but you can still ask for a reasonable response time and clear instructions.

You should feel empowered to email your customer, or even to make a phone call to get things resolved if you’ve run into a blocker. Perhaps encourage your customer’s participation in a daily standup — even if they can’t dedicate forty hours a week to your project, they can certainly dedicate one hour.

Your customer should be engaged, whether off-site or on. But if they’re not engaged, that’s a bad smell and represents a big project risk that you should try to mitigate sooner or later (but that’s a topic for another blog post!)