Customer Team Member - a way to winning together

November 13, 2008 by Przemysław Bielicki

Used by permission.
Copyright by Paweł Niewiadomski

One of the core XP practices is having a Customer Team Member. It means that development teams have access to the newest information from the customer's side and they know about all changes in the requirements very quickly. Having on-site customer (or customer proxy for commercial products with lots of potential customers) ensures that requests change informally, the process becomes flexible, and saves the cost of formal overhead.

In this post I would like to take another look at this practice. I would like to share with you my thoughts why having a Customer Team Member can help the development team win together with their customer. And I would like to take a "social" view on this practice.

Customer knows better

Some developers say "It would be better if the software wasn't made for the customers - we wouldn't have any change requests then and we wouldn't have to reimplement once delivered features". Good point, however in this case we wouldn't earn any money because no customer = no money.

XP is very clear about customers - customer should be a team member. XP says that the development team is able to consult with them all unknowns just-in-time and they don't have to assume anything or wait for their response (sometimes quite long which can result in development blockage).

Customer as a team member is very helpful - as I wrote earlier, communication is much faster and efficient as it is mostly informal. If a developer, or tester or someone else from the development team has some questions he/she goes directly to the Customer and gets the first-hand information instantly. No waiting - no wasting - no assumptions - Customer knows better.

"Social" aspect

My colleague who I worked with for last couple of years used to tell his best experience with Customer Team Member from his previous job. The project's goal was to deliver some software for the civil aircraft cockpit and the main users of this software were airline pilots. Airline pilots were the Customers.

My colleague worked for the whole project closely with Customer according to the XP practices and always says that this project was the most successful in this company. And I have to mention that the company was quite big - actually it was one of the biggest airlines in the World.

When I ask him why it was such a big success one of his main points is that when the team worked together with pilots they felt responsible for the project. They felt responsible for project's successes and failures - they were involved in the development process thus it was their product. They couldn't blame the team - they were the team!
More so, they saw how hard developers worked and that they weren't spending their time on drinking coffee and talking to each other. Pilots really appreciated the work developers were doing - they saw it, they were co-builders of the product. Customer Team Member = involvement, ownership and trust.

Customer proxy works well too

Leaving my colleague's example I have my own. I'm now working on the web GUI application for the XML-based backend and my "customer proxy" is a product definition (PD) team (my customer should be marketing directly but I don't set the rules here). They are supposed to know everything about the project - I mean requirements. To be honest it should be transparent for us as a development team who they are - they act as the Customer for us and they are on-site.

I noticed that we are the first team that works so closely with PD team but I see huge advantages. Actually I see the same advantages I was told about with airline pilots. PD sees how we work, they are involved in the development process, they know about our problems and we can adjust some requirements to the technical constraints on the fly without the overkill process of changing the documentation first.
PD team really appreciates work we do and they feel responsible for the project - it's not like "We give you the specification and now it's your business to make it work". They are helping us in adjusting the specification - but this is because we communicate them all our problems and we involve them in our development process.

It really works!

Just do it!

I hope I expressed the main points in just few words - it is very very important aspect of Customer Team Member (IMO).

And what should you do when you have problems in having an on-site customer? Robert C. Martin in his book "Agile Software Development, Principles, Patterns, and Practices" answers this question - just have one.

In practice it can be more difficult than that but it will pay off - you will win this together. Try to convince your Customer to work with you - if you succeed you will not regret it (will you?).

Do you have any experiences with Customer Team Member? Do you find it useful or useless? How do you manage to work with your customers?
Please share your opinions here.

Permalink