Monday, September 15, 2008

Agility Isn't Just About Development; Hostile Business Users Are Participants Too

A friend, asked me to write about when 'agile' teams do not enjoy such a good relationship with their business users. His team is trying to be agile, and for the most part their development team is doing all the right things when it comes to developing. Their stress point is the relationship and interactions the development team has with their business users.

My friend describes their primary business user as an uncooperative blamer. That is a tough situation. I've been in a similar one myself and it can be unpleasant.

I don't know enough about my friend's situation to make specific recommendations to help the situation, but I do have some less specific recommendations for dealing with difficult customers.

One thing to keep in mind with projects, the customer, i.e., the business user, is important. Did I say important? They are essential. They are the reason that the project is funded. It is their needs that the project is trying to satisfy. The customer defines the project's success. Without them, the project automatically fails.

Sometimes it is easy for the customers to lose sight of the fact that, as developers, we're trying to help the them. One would think that the business users would want to help their developers to help them, but I don't think that business users always see developers as their helpers. 

If there is a disconnect between development and the business, there's a problem. A dysfunctional organization will ignore the problem and try to operate with a system that is missing a key element to the project. If your project has this type of disconnect, your project is failing. Ignoring it is creating a social debt with credit card interest. You can pay the bill now, or suffer its wrath down the road. 

Developers, and technical people, don't have the best reputation for being socially endearing people. As a group, we can be arrogant, harsh, and difficult to work with. In my experience working with developers, I know very few people who typify those traits, but we all have our moments. Those exceptional personalities are the ones that people tend to remember, also.

When dealing with customers who are uncooperative or have harsh personalities it is natural for many people to withdraw and exclude the conflicting party from participation. Most people avoid conflict, and they'd rather live without it. Although, they probably know that this is not going to solve the problem, many people prefer this to dealing with what they see as an inevitable conflict.

In practice, I see a lot of project teams minimize their contact with their business users. They will meet with the customer to get their requirements, go into a cave for six months to do development, and then take their punishment when the finished product disappoints their customer.

This is a bad practice. To state the obvious, shutting someone out to avoid a conflict is really deferring the conflict to another time. It also makes meeting your customers needs much more difficult and stressful than it needs to be.

It is important to understand and accept that the conflict will happen. 
Thus it is that in war the victorious strategist only seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory.
--Sun Tzu, The Art of War
If the conflict is destined to happen, it is prudent to let it happen on as many terms as you can name as possible, i.e. when, where, how, and with whom. Instead of waiting for user acceptance testing for the customer chastise your team, why not deal with the conflict earlier at a less volatile time? 

Timing is very important. Unlike comedy however, when dealing with conflict, timing isn't...
...
...
everything. Planning is important too. Most important to the planning is defining a goal. Try to objectively define what is lacking for the project to succeed. If your customer won't participate in defining success for the project, your goal might be that the team needs to be able to be more interactive with the customer to meet the customer's needs. If this is difficult, it is advisable to bring an impartial person from the outside in to help review your goals and your plan.

Try to pick a time and place that works for everyone. If that is not possible, make a sacrifice and alter your schedule to deal with the customers. Try to meet in person if possible. Location is important too, if there isn't a good location at your facility, consider taking the meeting offsite. Try to find a location that is less formal and more relaxing.

When you do meet to deal with the situation, make sure that you and your team relax. Take in a few deep breaths and walk around the building--it helps.

Choice of wording is very important when dealing with conflict. People get emotionally involved in these things and it is best to use non-confrontational language. This can especially be the case when starting sentences with the word "you".  Using you makes the statement personal. State your side and keep it impersonal.

One technique that I like is stating the situation and asking for feedback on all parties for suggestions on how to resolve the situation. For example: "I want to provide the best solution I can for your team. To do this well I need feedback on my work and clarification on the requirements. I do not believe that your team is giving me the feedback that I need to provide your tools."  

Try to understand the other side's situation. Explain your our situation in terms of providing service, e.g.,: "I want to provide a product that best meets your needs. In order to do that I need to be able to regularly get feedback on our project from you to better meet your needs." 

Give everyone an opportunity to contribute and don't lay blame on people. If cause or blame needs to be stated, lay blame on circumstances or a situation. You need not be confrontational to deal with conflict. Confronting an issue isn't about being right or wrong. A single person doesn't 'win' a confrontation, but people can lose. It isn't one 'side' that loses either, everyone loses.

Listen to the other people. Most people are reasonable, even if they don't act that way. They may not cooperate because they don't believe that they have anything to gain from it. Look for ways that you can help them and they will develop an interest in helping you help them. Demonstrate to your customer that there is value for them in helping you, and they will do what they can to help you.

If dealing with the customer directly in a non-confrontation manner doesn't work, well then it might be time to get out the old org chart and escalate. At this point, at least the people on your team have taken the initiative to perform a good faith effort to resolve the issue. Again, it is probably best to explain the conflict in non-confrontational terms and look for solutions that will accommodate each group's needs.

Assuming your customer is on board with participating, include them as much as possible. Invite them to the standups, the planning meetings and the retrospectives. Solicit feedback from them as early and as often as is valuable to them. Respect their time though and let them know that their presence is appreciated, but it is understood if they have other commitments.

If your team and your users can resolve your conflicts, your project is going to enjoy a much better chance and success. By involving the customer frequently for feedback the development team and the customer can focus on creating a product that meets the customer's needs. Isn't that really the reason why we do projects? Don't avoid the problem, take care of it tactfully and move on with the reason you go to work every day.

No comments: