11

One of the tenets of agile is ...

Customer collaboration over contract negotiation

... another one is ...

Individuals and interactions over processes and tools

But the way I see it, at least when it comes to interaction with the customer, there is a fundamental problem:

How the customer thinks is different to how a software engineer thinks

That may be a bit of a generalisation, yes. Arguably, there are business domains where this is not necessarily true---these are few and far between though. In many domains though, the typical customer is:

  1. Interested in daily operational concerns--short-range tactics ... not necessarily strategy;
  2. Understandably, only concerned with the immediate solution;
  3. Practical thinkers, not abstract thinkers;
  4. Much more interested in "getting the job done" than considering how the solution will support future concerns.

On the other hand, in the ideal, software engineers who practice agile are:

  1. People who think alot about quality;
  2. Individuals who appreciate how a little bit of upfront work can save a ton in effort down the line;
  3. Experienced, analytical thinkers.

So there seems to be a culture discrepancy that tends to inhibit "customer collaboration".

What's the best way to address this?

Improve this question
8
  • 1
    Operant conditioning shaping - en.wikipedia.org/wiki/Shaping_%28psychology%29 - Hint: it's too obvious if you use a clicker before you give them a doughnut. – jfrankcarr Mar 23 '12 at 10:43
  • 3
    I wanted to up vote this. But then I read the stereotypes you try to put on this. There are bad programmers doing agile and good customers as well. Perhaps you could rework your question to include the difficulties you are having instead of the biased stereotypes you have here.. Then I would upvote the question. – SoylentGray Mar 23 '12 at 12:49
  • 3
    your stereotypes betray your bigoted narcissistic opinion, I don't think anyone that thinks the way you do would be successful dealing with any customer, you have already made up your mind and have a firm belief system in place to reinforce your bias. It is just think kind of chauvinistic attitudes that give working with engineers a bad name. Good luck with that. – user7519 Mar 23 '12 at 13:07
  • 1
    @Chad This can be a useful point of view for a question, regardless of whether it comes from the asker's preconceptions, or not. Thinking about how a good engineer interacts with a bad client is the relevant and interesting case: it could be argued that we don't care about how bad engineers handle this, since their product will be inferior anyway, and good clients obviate the need for this question. That leaves us with the problem of how a good developer should deal with a bad client. Maybe the wording came off strong, but the question is still useful, – Chris Bye Mar 23 '12 at 15:49
  • @Slothsberry - I understand the question could be scoped for those subsets. That is not how it is phased. I read it as all developers who practice agile are good and most customers are bad. – SoylentGray Mar 23 '12 at 15:55
27

In many domains though, the typical customer is:

  • Interested in daily operational concerns--short-range tactics ... not strategy;
  • Only concerned with the immediate solution;
  • Generally one-dimensional, non-abstract thinkers;
  • Primarily interested in "getting the job done" as opposed to coming up with a lasting, quality solution.

And to be frank, they usually have good reasons to think like this. First of all, they are running a business, which should generate revenue today and tomorrow, not in some distant future. Secondly, they aren't technical experts - they don't know what's possible and what's not, and what the consequences of specific architectural / design / implementation choices are. This is what we know.

So the answer is - hardly surprising - communication.

You need to communicate a lot, to educate each other, to make each other understand the point of view of the other party at least to a basic level. You need to explain them the short and long term consequences of possible alternatives. And you need to use language they understand.

  • If you say "this would be a hack, which makes the code less readable and extensible", they say, "yeah, whatever".
  • If you say "this would be a short term fix, which would make longer term development and maintenance more costly, and increase the risk of introducing bugs", they say "a ha, let's consider".
  • And if you say "this solution would cost you $100 now, but introduces $500 of technical debt which you are bound to pay back with interest sooner or later; OTOH this other solution costs you $400 now and leaves no technical debt; pick the one you want", they say "now we are talking!".

OTOH they can teach us a thing or two about the business perspective. Business wants usable and good enough - hardly perfect - solutions. And they know probably better than anyone that "perfect is the enemy of good". So you need to keep in mind that our job is to provide solutions to problems of our clients, rather than to produce technically perfect software. Sometimes these two converge to the same, but more often not. This may be seen as sad by many, but it is business reality. For me, if I managed to solve my customer's problem, and I see that it made their life visibly easier, I am as happy as they are. OTOH if I managed to implement the perfect design I had in mind, but the company goes bankrupt the following week, it is hardly a win to anyone is it?

A sensible business owner will understand - if you explain them using their own language - why is it important to keep software clean, to write unit tests, to refactor etc. Even though these do not seem to directly contribute anything in the short term, they are essential for long term maintenance. And sensible customers do care about the long term maintainability of their business, so they surely are willing to invest into it when they see the value their investment generates. However, both their resources and your time are limited, so you need to prioritize and focus on the most important things. But it is important only if it is important to both of you.

You may want to refactor module A because the code in there is just awful, and you have a stupendous idea how to refactor the code to be concise, elegant and clean, using a design pattern you just read about. However, if that module hasn't been touched for years, and it works reliably, you are most likely better off focusing on module B, which is going to be extended next week with a very important new feature, and it contains tons of bugs already.

Improve this answer
5
  • 3
    Wow, you have clients that would actually avoid technical debt? Most of the ones I've had would go '$100, yeah I'll take that one'. – sevenseacat Mar 23 '12 at 9:12
  • Well, that's the tricky bit, isn't it? What is "good enough", and where do your returns start to diminish when you consider spending time on the medium-to-long-term health of your businesses product/system? I would argue that that is something for a professional to make a call on. – Eric Smith Mar 23 '12 at 9:14
  • 2
    @Karpie, yes, there are clients who have learnt what technical debt actually means (usually the hard way). – Péter Török Mar 23 '12 at 9:29
  • 2
    @EricSmith, yes, it is a fuzzy decision, with no single right answer. We developers understand the technical consequences of things; the customer knows the budget and business limitations. Ideally, we tell how much each feature / task costs; the customer prioritizes based on the value and cost of each. There are always compromises when you need to keep the system up and running while fixing the most pressing problems one by one. – Péter Török Mar 23 '12 at 9:35
  • 3
    I agree with what you're saying here although I've ran into company cultures where users refused to communicate. It has to be a two way street or it won't be successful. I was only half-joking about using doughnuts for conditioning in my comment above. Sometimes you have to use positive or even negative reinforcement to get participation. – jfrankcarr Mar 23 '12 at 10:48
4

How your customer views themselves:

  • I have a project that I need to get done ASAP
  • I know my business needs
  • I need to solve the problem in a way that is not going to be disruptive to current business practices
  • I do have a limtied budget to get this done.

On the other hand, they see your group as:

  • Guys who dont get that they are sucking money out of my budget.
  • Do not understand the needs of our business
  • Want to redesign everything even though it is going to make implementing it harder on the business.
  • Want to have clever slick solution when all i have the budget for is functional and effective.

Your primary problem seems to be neither of you is understanding what they need from the other party.

Improve this answer
3

Well, first and foremost, Agile is not the solution for all the problems you have in your project.

How the customer thinks is fundamentally different to how a software engineer thinks

Yes. Sometimes it is true. There are even case where customers do not know what and how they want (ie; requirements are not clear). What ever, If you are agile you get the result after each sprint (say 2 weeks) and you get an opportunity to get customer feedback and make sure all are on the same page. This helps in identifying and fixing the issues early which will internally help build trust.

Also there is a saying, users are like crazy children, so when they are asking for a gun and you know it is not safe, you might consider giving a toy gun to calm them down.

What's the best way to address this?

As I have told already there are no magic stick that can solve all theses problems. You need to engage more with your customers so that there is a good understanding about what each others do. Promote the site visit, open feedback etc.

Make sure your product owner and the stake holders attend the sprint demos and gives valuable suggestion to improve the product.

Improve this answer
1

If you do not have buy in from the customer, Agile can be nearly impossible.

By buy in, I mean getting some guarenteed percentage of a customer representatives time per week or month. This percentage will vary depending on the project.

Obviously they have their day job, so it's not just down to the customer representative themselve, it's down to their management to make time for them.

So getting agreement from management on the customer side is key to this problem

Improve this answer
2
  • without customer buy in any method will be nearly impossible – Ryathal Mar 23 '12 at 12:51
  • @Ryathal - well indeed, but it's particularly important in the way I describe for Agile. – ozz Mar 23 '12 at 12:59
0

Remember that agile doesn't mean that the customer is involved in daily standups or some of the other day-to-day aspects of agile. Agile, from the customer perspective, is about communication. That doesn't mean they are communicating with engineers about implementation details.

Customers collaborate with the product owner to get and give constant feedback. The topic is features, but not how they are implemented. Are you delivering the proper features? Are you on schedule? Do they have changing requirements you need to adapt to?

Agile helps you and your customer answer those questions.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.