A Real Onsite Customer

I’m currently working on a project that is using an agile process to manage development. We use most of the XP practices, but are mising what I would consider the most important one: an onsite customer. Though our customer is a manager, and the final decision-maker, she doesn’t participate directly in the daily development activities. Instead, she sends a proxy.

This works out great about 75% of the time, but doesn’t work so well the other 25%, when we need a tough question answered quickly. And that often introduces some long waiting. Here are a couple of examples.

Last Friday, the manager had her proxy call a meeting with the developers to discuss a featuer we had just completed. She wanted to improve the flow of the feature, and make sure that it was as easy as possible for the users. We got together with the proxy, brainstormed, offered ideas and estimated the different steps. He then went back to her, she had some other ideas, and some questions. So he came back to us and …..

All this going back and forth was costing precious time. We are still answering questions and going over ideas, though we never really meet with our customer. There are several problems with this approach. Information is lost, intent is misunderstood with each link in the chain, and delays are introduced. And this happens both ways. The proxy is an intelligent guy, but all the intelligence in the world doesn’t help here. Its the nature of communication, similar to the game we played in grade school, where we each whispered something to the next person, and what came out of the chain is not what went in. Extra energy is expended going back and forth. It would be much more convenient, and direct, to be talking directly to the decision-maker.

Contrast this to what happened yesterday. We were discussing a feature that the developers thought must be included, but the manager thought wasn’t necessary. Of course, she sent the proxy to discuss this with us. However, we didn’t feel she had a strong argument, and she didn’t think we had a strong argument. By chance, one of our teammates saw her walking by, and we asked her to explain her point. Then we explained our. We were quickly able to come up with some options that would meet her requirements and our own. I walked out of this meeting energized and excited about our application. We were going to deliver a valuable feature that met the needs of our users, and our developers, and we were able to get to that point very quickly.

All modern books preach the need for an onsite customer. This experience of two extremes solidified the idea in my mind. Your team can definitely work more effectively with an onsite customer. Not a proxy, nor a proxy to the proxy, but the real decision-maker, in the trenches with your team, day in and day out.


Yesterday, a colleague sent out an email to the group, asking for help on a certain topic. Over IM, I asked if he was doing this for a particular scenario, which he was. So I suggested he use a feature of the tool we are using. He said he wasn’t aware of that feature, so I said “RTFM” (read the frickin’ manual).

This didn’t go over very well with him. His first reaction was to lecture me, never to do something like this again. I didn’t need a lecture, but I apologized, trying to quell an escalating situation. Later, after he calmed down, he explained that this triggered memories of bad relationships with past colleagues, and that he didn’t want our rapport to get out of hand. Fine, I can accept that. But this situation got me to thinking about two things: why I said RTFM to begin with, and how I could have said the same thing in a more gentle manner.

As a consultant, I know alot is expected of me by the client. There is a reason they are paying more for my services than they pay their employees, and I have an obligation to keep up my end of the deal. I expect the same of the other consultants on the project. In this case, I expected my colleague to know the tools that we are working with, and to have at least gone through the manuals and have been familiar with the concepts. Staff employees often expect to be sent to training. As consultants, we need to go out of our way to quickly learn as much as we can about the tools and technologies we are using. We also need to be able to pass that knowledge on to our teammates, whether they are consultants or employees. It’s by this transfer of knowledge that the entire team gets better, and the entire project can go smoother.

Which brings me to my next thought: how could I have been more effective in that communication. After thinking about it, I should have said something along these lines:

You can use this feature. You should be able to find information about this in the manual. Take a look, and let me know if you have any questions.

It would have gotten the point across much better. It also would have been in line with the kind of response my colleague expected. Even though I don’t have any particular title, I am often perceived as a leader on our team. To fulfill my part of being a leader, I should have used the gentler statement to get my point across.

The work we do executing projects and developing software is difficult enough. We don’t need to make it any more difficult by creating problems among our colleagues. As a team leader, whether by title or by perception, we need to excel at increasing the knowledge of our entire team (and organization), and working towards project success.

Hello World

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Curabitur pretium tincidunt lacus. Nulla gravida orci a odio. Nullam varius, turpis et commodo pharetra, est eros bibendum elit, nec luctus magna felis sollicitudin mauris. Integer in mauris eu nibh euismod gravida. Duis ac tellus et risus vulputate vehicula. Donec lobortis risus a elit. Etiam tempor. Ut ullamcorper, ligula eu tempor congue, eros est euismod turpis, id tincidunt sapien risus a quam. Maecenas fermentum consequat mi. Donec fermentum. Pellentesque malesuada nulla a mi. Duis sapien sem, aliquet nec, commodo eget, consequat quis, neque. Aliquam faucibus, elit ut dictum aliquet, felis nisl adipiscing sapien, sed malesuada diam lacus eget erat. Cras mollis scelerisque nunc. Nullam arcu. Aliquam consequat. Curabitur augue lorem, dapibus quis, laoreet et, pretium ac, nisi. Aenean magna nisl, mollis quis, molestie eu, feugiat in, orci. In hac habitasse platea dictumst.