Here's the thing: In agile, client has very important role to fulfill - if they aren't involved, agile loses much of its value.

How do you convince clients to change the way they run projects, especially with big companies and at least medium-sized projects?

I guess they don't just believe salesperson saying "that's better." And if they don't have much experience working the agile way, clients are likely to be reluctant. So how you make them to change their minds?

  • This is a very great question. Tomorrow I'll have a meeting with my customer, trying to "sell" him agile. I'll get back my experience. Commented Mar 14, 2011 at 22:05
  • Hi Mark -- I linked my question to this and was wondering if you could chime in with your expert opinion: pm.stackexchange.com/questions/14460/…
    – amphibient
    Commented Mar 11, 2015 at 21:33

4 Answers 4



If you try to convince your customer (or boss, management, colleagues, etc) to do something totally differently to how they've been used to doing it, then they'll react in one of the typical ways in response to change: acceptance, panic, refusal, etc. So, I recommend a gradual adoption of Agile methods until you're there, for example:

  1. Start by having weekly meetings with the customer to discuss the 'prioritised requirements' (Feature Backlog). Ensure the priorities are set by the customer and are in Story Points units (with guidance from you).

  2. When you add items to the list, write them in 'User Story' language, but familiar enough not to confuse/alienate the customer. If you've already got some kind of specification or use cases, adapt them, but don't be tempted to totally re-write them - the customer likely won't be able to make the leap.

  3. Have regular deliverables so that the customer can see progress and the benefits of the new way of working. Make sure they know what they've just received, how to get to it (URL, download site, etc) and follow up to make sure they've tried it.

  4. Get feedback on these deliverables at the next weekly meeting so that the customer can refine the Feature Backlog according to what they want to see next. Take the time to outline this 'choose top user stories, implement, deliver, review' mechanism to introduce the concept of an 'iteration' or sprint.

  5. Assign cost estimates to each User Story so that the customer can understand the effort required to achieve each User Story and can learn how much could be achieved in one iteration. Be open with the customer about the Planning Game used to come up with the estimates.

  6. Make sure the customer can see how many User Stories have been achieved so far (budget used) and gets a clear understanding of how many of the remaining stories could be completed in the remaining time/budget.

I've done this successfully with multiple customers and found that after delivering on promises for a few weeks, they totally trusted us from then on and focussed more on which features they wanted most urgently rather than whether or not we were going to deliver. We didn't necessarily expose them to all the terminology, but they 'got' the regular updates and open-and-honest discussion about what features get implemented next.

There's nothing scary, wrong or weird about iterative project methodologies (such as Agile, XP or Scrum), its' just not the 'traditional' Waterfall method. Having a nice human explanation helps:

In traditional construction, you can't alter the foundations without first tearing down a house/office block/bridge. This is one reason that you have to get the foundations right first before moving on to the walls and roof.

In other industries, you can change any part of the system without having to start again. For example, in Formula One, you can jack up the car to change the wheels - you don't need to disassemble the whole car.

Therefore, some projects are very suitable for a iterative/cyclical approach where the initial solution is refined many times until it is just right.

I've deliberately been vague with the Agile terminology in order to convey the message easier and I've had a long day so may have got a bit muddled in there.

  • Great answer! I found this really helpful, tired or not :) +1
    – jmort253
    Commented Mar 15, 2011 at 3:46
  • Very interesting, so it comes down to adapt the methods, but don't use the terminology on management level. What do you do if there is a person in the management team that saw your intentions and creates panic in the management team?
    – Kennethvr
    Commented Mar 15, 2011 at 7:34
  • @Kennethvr: you catch this as early as possible and work with that single person to identify their concerns and also with the management team to allay any fears they have. See my edit above. Commented Mar 15, 2011 at 14:37

One of good answers is "you just don't."

It is perfectly possible to run agile project without showing client exact way the team works. What more, very often client won't be interested in that. The trick is they won't be interested in being the part of the team as well. They won't be actively participating in prioritization or product demo at the end of the iteration. Usually the best method here is to emulate the client within a project team. Very often the best person to do this is project manager who knows the client and the merits of the project well.

Another answer is: make it win-win

For some time I thought it is very, very hard to build some kind of agile contract which is win-win and limits risks on both sides: client's and vendor's. This presentation form Paul Klipp (slides are here) is the best approach to the subject I've seen so far. It gives incentives to both sides to finish faster and shares the pain of dealing with the slip inflicted by scope changes.

Also you can try to show them

This one is tricky as it assumes you can convince the client to give it a try. However one, pretty good, argument I heard which can change client's mind here is letting the client abandon the project after first two or three iterations at no cost. Then you have some time to show the value of your approach, possibly presenting how client's engagement helped to make the result of these first few iterations better.

  • As most of agile pethods imply a form or another of involvement of the customer (story game, short iterations with feedback form the customer and so on), I'm not sure the first point is really realistic. Replacing the customer by the project manager is, in my opinion, missing the point WHY the customer has to be involved! Commented Mar 16, 2011 at 10:16
  • Actually I saw it working in many places where the organization and people wanted to work agile-way but the client wasn't interested in being involved in the process. Of course it isn't as effective as having client working closely with your team but it works. Commented Mar 16, 2011 at 13:53

Both of the answers already given are excellent and I support them. I just wanted to add one modifiying factory. At a recent Agile panel one of the speakers made a very good observation. "If things are working and running well, then getting someone to change to a whole new system is going to be a very hard sell. Pitching an change to Agile is going to have better traction if things are already broken."

Then you need to tailor your Agile reponse to what is actually broken. You don't just swoop in and "Go Agile", you have to see what has been happening and migrate from that.


Mark, as a consultant/coach you can't want change more than your customer. They have to want to change and that may mean you have to stand by and let them fail. Maybe they're already failing but just can't see it. You can try and point this but this is a tricky slope that often leads to the fragmenting of the relationship. Better to step away and be invited back later when they are ready to change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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