Last minute changes by the client

Question

We have a team that works in Scrum and a PO who prioritizes the backlog. Outside of this, we have 3 project managers that hold the communication with our clients (each one with 2-3 different countries). They (instead of the PO) are the communication point with the clients. Also we have a chief PM, who holds the overall roadmap of all the projects. The team estimates and does a little bit of each project's work in each sprint, depending on then deadlines and priorities.

However more often than not, a client will put through some last minute changes, that are not small, and he wants them delivered in 2 days, therefore blowing up the rest of the sprint. This leads us to trying to juggle too many things and compromising in quality at the end.

We tried to bring the clients closer to us to let them understand how we work, but their nature of business is advertising and media, and therefore their response usually is "the ad goes live in 2 days". Therefore their product has to be ready in 2 days.

I know this setup is far from ideal, however how do you tackle the "client" part with the last minute changes, given that it's only one scrum team that has to cater for everyone? Or, even better, how do you prove that this is inefficient?

Answer 1

This is an unenviable position. I'm not sure there are any good/easy answers.

• Who is accountable in this scenario?
• Who approves the changes? Changes (last minute or not) have a financial impact on the company.
• What is the change control process? It isn't clear whether the 3 PM's who communicate with the clients have the authority to unilaterally approve changes. It isn't clear how the resulting changes are coordinated with the PO. And I'm not an initiate of scrum, but my understanding was that in scrum the self-organizing team needs to be included in discussion/coordination/decision of substantive changes.

Given that the changes cost you money, do they represent a billable cost? Does the client have to pay for last minute changes in scope? Does the client have to pay a penalty for scope changes that affect other deliverables?

Whenever the risk is disconnected from authority/accountability, problems will persist until the two are connected. There appears to be no disincentive for the client's behavior; all the risks/issues/damages/consequences rest elsewhere. I predict the client will continue to behave as your incentives communicate.

“I never allow myself to hold an opinion on anything that I don't know the other side's argument better than they do” Charlie Munger

I'm not going to pretend that I understand the situation better than you do, but based on what you've shared, if I were in your shoes, I'd

1. Internally decide on a change control process that is mandatory for any consequential change. Ensure that everyone who will be affected by the change has advisory input, but place accountability for the change on someone who can bear the consequences.
2. Do an internal practice session - use the last five changes as scenarios and run them through the process to tell when the process should be invoked, by whom, and how long it takes.
3. Communicate to your customer their role in change control & scope management. Changes during scrum planning/backlog grooming are free. Changes once the self-organizing team start work are financially costly. (or just jack up your costs to this client)
4. Prepare to lose the client. The client is not going to be pleased with the change, but you are not going to survive unless you control scope.

Best of luck.

Answer 2

There are two parts to your question:

• Do the clients really need to make changes at very short notice
• If this is a real need, what do we have to do to respond to changes very quickly

I would start by speaking with the clients and explaining the impact of last minute changes, which might include:

• Efficiency lost due to context switching (i.e. shifting to a different piece of work)
• Efficiency lost due to very short-range planning
• Efficiency lost due to having to drop some work at short notice

The clients may say that they appreciate there is lost efficiency, but that their business means they need to make short-term changes anyway. If this happens then the next thing to consider is how to quickly adapt to last minute changes.

Once you know and accept that last minute change will happen then you can build you entire process around it. It may well be that Scrum is not the best framework to use in this situation as Scrum requires a certain amount of stability within a sprint. It would perhaps be worth considering using a more responsive framework like Kanban.

Other things that may help with rapidly changing requirements include:

• Extensive use of automation, so that setup and deployment times are reduced
• Use of test automation for regression testing, compatibility testing, etc.
• Establish a process for rapidly re-prioritising your work
• Establish a process for rapidly determining the impact of changes to prioritisation (e.g. by informing other clients that their work may be delayed)

Remember that agile is all about adopting to change. Change itself is not a bad thing, but it does have implications that need to be carefully considered. If you adopt the right approach then you can welcome change.

Answer 3

We tried to bring the clients closer to us to let them understand how we work, but their nature of business is advertising and media, and therefore their response usually is "the ad goes live in 2 days". Therefore their product has to be ready in 2 days.

Lots of good answers above -- and obviously educating and involving the client is the way to go. I mean, do they really not know where something is in their sales/delivery pipeline?

That being said, one thing you might consider is having multiple teams that have different sprint cadences for this client.

• The bulk of your developers run a 2/3/4 week sprint cadence for technical stories.
• A small team of your developers run a 5 day sprint for creative stories.

It sounds like this client wants a team "at the ready" for ad hoc requests. If there's enough capacity, this might be your solution...