Like many developers, I’ve been protected from apparently difficult customers by my managers and left to get on with the important job of “writing code”. But this week I left our office and headed out to a technology park to work directly with one of our customers, and after a couple of days of understanding each others needs I’ve rarely felt so excited about “writing code”, because I know it will be valued.
XP & Scrum talk about a customer on the team but I’ve never seen it happen, well not a “real” customer. Proxies aren’t the same, particularly when they are neither dev or customer. With little understanding of either side, they’re stuck on the fence, helplessly documenting and relaying demands with seemingly unquestionable priorities to an increasingly demoralised team. It’s a world away from the customer and developers really understanding each other, so why can’t we do better than this?
Fear gets in the way
The developer fears the customer. I’ve spent years assuming developers would love to talk to customers given the chance, but when it came down to it, I’m seeing fear come between us. I feared being asked to do dumb things and not knowing how to say no. I feared having to explain failure and the difficult conversations that follow. Without letting myself be vulnerable I grew conservative, inward looking and start making assumptions based on what works best for me rather than what’s really needed.
The customer fears the developer. She fears being taken for a ride by these alien geeks and looking stupid when they try to dazzle her with their technical prowess. Who can blame them, I see defensive developers making an art out of making people looking stupid rather than be open and share what they don’t know.
The manager fears relationships. It sounds like a terrible thing to say, but it looks to me like many managers want people ‘under’ them to have exclusive relationships with them rather than each other. Holding tightly to our relationships lets us stay in control, but interesting things only happen when loosen our grip and let people collaborate freely.
Enlightenment
This is hard, but there is some enlightenment available to those willing to step into the unknown. When we open ourselves up to sharing and learning from each other, we can start to collaborate. Once we begin to understand and attend to each others needs we can start to create something that’s a bit special.
Time to build relationships
Can I propose that when it’s not possible to have a real customer on the team, that developers spends at least a couple of days a month with a customer and users? To help build the desperately needed relationships and mutual understanding, Scrummasters and Managers can help facilitate this relationship building. I think this collaboration is perhaps the most important thing we can do if we want to build something that has real value.
Diary of a ScrumMaster 
Deming talked about driving out fear. Relationships are a means of reducing fear but there is always a first step. In my opinion that step needs to facilitated by management more than by scrum masters or others (albeit they have a roll).
You make quite a few good points in this article. I have occasionally seen another reason for management’s desire for separation between the customer and the development team. Simply put, they are representing the state of the project “incorrectly”. There becomes a divergence between what the customer understands the state of the project and the real state. This is often referred to as “managing the customer”.
Always a pleasure to read you. And right you are. I find it extremely important and ridiculously hard. As much as I wanted this most workplaces I’ve been to make it darn impossible. But the times they are a changing. 🙂
An extremely valuable practice, even on waterfall projects (Fred Brooks wrote in “The Design of Design” about immersing technical folks in the customer’s world e.g. Air Traffic Control or mainframe operations).
Agree entirely with John’s comment about ‘managing the customer’.
On waterfall projects, a similar reason people fear relationships is that they lead to customer feedback (the horror!) and possible change. But there is no budget or time for change, and the (contractual) requirements have long since congealed. The customer must be held to them! 😉
A related worry is that a mere technical person might, whilst on hostile territory, unsupervised by ‘grown-ups’, commit to a customer request that is not in the requirements or budget.
I’ve also had difficulty getting access to the “right” customers – sometimes a particular customer department is kept out of the loop until it is too late for them to contribute – even on the customer’s site one can end up talking to a proxy! This may not be apparent if your customer contacts speak with apparent authority (and how is the developer supposed to spot this? – after all, they are often not a domain expert).