You are starting an agile project. As a scrum master you are facilitator and you assist the product owner with the backlog in creation as also in its maintance. You also coordinate with external customer communications to report progress on the project.

Your self-organized team is ready to start the sprints for the project.

Everything is set up, but imagine that those clients that are not used to this agile approach and are not aware of the iterations in testing sprints and they are only waiting for the final deliverable to test everything like in the classical approach.

How do you train or deal with your clients who are not aware yet of an agile approach?


Let's say that you once you already started your project and got your initial scope/objectives, you build your 2-week sprints for all the features to be built with dates and what is to be tested and how each feature fulfills the objective (Expecting to be used later as an input to a new iteration).

But as I said, customer does not have "resources" to test and give many feedback about the deliverables, because they are used to the classical approach where you expect to gather all the information from conception and refine data slightly through execution then later they want to perform testing effort later (This could fail and could drive to rework) As a scrum master, explain the benefits of the approach, you explain them about the whole process, but still they are not convinced. 2 risks here:

  1. They would believe they can ask anything infinitely, which you need to make clear that if it's not.
  2. Customer reacts negatively because as I said they don't have resources. You can escalate or negotiate with stakeholders or whatever is the authority to report progress nicely. But in this 2nd point you react, to me, as typical PM.

As your team is already agile, they are self-organized and empowered to manage their sprints with the product owner. You don't have the "control" as a regular PM. Don't misunderstand me, I think the agile approach is great to create motivated teams and spread creativity.

What are your strategies from experience to deal with customers with no experience in agile approaches?

  • 1
    Have you planned out what the final deliverable is going to look like already? Because then you're already starting from the wrong angle. If you're doing it agile, you should be building it in small steps, and the client should be aware that you'll need further input from them every few weeks at most, maybe more often.
    – Erik
    Commented Jun 15, 2018 at 5:18
  • My first question is; do you know the final deliverable? Forcing a traditional project into an iterative framework is not that helpful either. If the final product is fully understood and mapped (IE construction, transport) then agility will not help you. If you have uncertaintity in your product then it is easier to sell iterations to stakeholders. Just like Erik has said above. Commented Jun 15, 2018 at 7:55
  • Thank you so much for your comments. Please I updated my question above. Commented Jun 15, 2018 at 10:49

2 Answers 2


This is a complex question because it assumes two things:

1) you've acknowledged that part of the problem with most software development efforts is that you can get to the end and realize that though you've built exactly what was asked for, it wasn't what was needed, hence moving to Scrum; and

2) your customer has decided that, despite this, he's going to wait until the end to tell you if it's right anyway.

For your first risk, I don't know that this has anything to do with agile. The problem with fixed-cost software projects has always been that they can create runaway expense. Even if there is a fixed scope, most companies won't ever say "you got the scope, take it or leave it" - it does too much damage to their reputation, meaning that you'll just eat the cost. I can't count the number of companies I've watched go under because of this over the years, regardless of the project management approach. What Scrum brings to this conversation is actually making it safe for the customer to agree to a time-and-materials contract because they get to see stead progress, they can cut it off at any time, and they get to keep whatever progress has been made up until that point.

For the second risk, I suspect that they may not understand the ask. They don't have to do hours of UAT testing. They need show up for an 2-hour review every two weeks. If someone is willing to pay the cost of your company to develop software, but won't either give 2 hours of their own time or appoint someone to represent them, that would raise some major red flags for me. Again though, this isn't really an agile problem. Projects have crashed and burned for this reason for decades. Many of the Agile and Scrum practices came about to mitigate this existing problem.

  • Maybe 1 of the first things that we did wrong moving from classic to agile PM is that we didn't educate our clients since conception. I think that it worths to expose our methodology since RFP and how we are gonna perform the sprint reviews with them. The more I plunge into agile the more I realize the classic methodology (PMI) is outdated. You can use some tools and strategies, but WBS and CPM are not longer valid. That's why they are moving into agile in the 6th version. I finished another book yesterday and not doubt agile is another way of thinking. Change and KANBAN is good. Commented Jun 15, 2018 at 12:22

The very first thing, in my view, to consider here is this :

Is your project requirements are fixed/frozen?

If the answer to above is yes, then perhaps the risk of final deliverables not matching the customer expectations is low. I am assuming that the project team has understood the scope, exact product requirements and has the right skills, tools and sufficient schedule/time to deliver as per customer's expectations of quality.

Here the classical approach of making a final deliverable to customer for their UAT is less risky.

Agile approach is of course recommended when project is experiencing a high degree of changes. If this is true with your project, then active engagement and participation with project stakeholders/customers is must.

Now if customer is having less resource/bandwidth, often, development team and customer can exchange information and project status updates in a dynamic & co-creative process such as quick demo of 20-min. with customer showcasing important modules/components of project.

These kind of regular interactions with customer gives them the sense of "where we stand" in project, build trust, and also gives a project team a chance to do any adjustments(if needed) in project deliverables.

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.