How to solve the problem of people communicating issues late, but demanding an immediate reply

Question

I work in a multi-cultural team: I'm employed directly by the company and based in Europe, but apart from me and another colleague, all the remaining team members are from a contractor and are based in Asia (I'm mentioning it since I believe this can play a role). We, the direct employees, are supposed to have a managing/ organizing role towards the outsourced colleagues. We are following an unorthodox Scrum.

There's a problem that is repeating itself. The colleagues from the vendor wait most of the sprint to signal a problem to me or assign me a task and then complain a lot that they can't progress on their task because they are waiting for my (or my colleague's feedback).

We have a good, competent team on our side, but we all have a lot on our plates and we normally do need 2-4 days to solve issues, unless that's something with priority 1, which is solved immediately or something planned.

So the colleagues don't signal an issue during the first part of the sprint and then create a blocker and stress they aren't able to move on because of lack of my or my colleague's reaction. It's about issues that are identified during their work, not assigned to me for the sprint, so they can't be planned.

E.g., someone is to create an automation that goes to a website and downloads a specific file. That's their main task for the sprint. They discover after the first week of the two-week sprint that they don't have access to the website. (Before you ask: we do have a sprint planning and ask every time whether all prerequisites, accesses, etc. to complete a story have been met.)

The reply "you just assigned me that yesterday evening, and I will reply in a due course" sounds defensive and hostile. But I'm not ok with being blamed for their lack of progress and user stories not being closed with a justification they lacked my feedback either. They should identify their problems earlier.

What's the best way to tackle that?

Answer 1

I'm sure there are going to be a few answers about how to do Scrum better, and how to potentially make your contractors perform better. But instead, I'm going to offer an alternative.

Don't give you contractors a set amount of work per sprint, but instead just allow them to work of an ordered list of tasks that is not bound into 2 week blocks.

This means that if they are blocked on one task, they just move onto the next one. That leaves no excuses for them to say why they got no work done. The last thing you want is to get to the end of a sprint, and they were blocked on half their tasks. So basically you saturate them with tasks, and the blockers become less of an issue.

You should look to prioritize the work not just according to importance, but also according to how likely they are to suffer blockers. If you suspect there may be issue, you give it a high priority so hopefully issues are flagged nice and early, and the task is not significantly delayed.

Now with my answer, I am not suggesting Scrum is bad. But I am suggesting that you have to play to its strengths. I suspect tasks where it is difficult to predict blockers, and with some an asynchronous nature of communication, may suggest a less regimented approach may be beneficial.

Answer 2

I have and still work on both sides of your situation.

The only solution I know of that works is to have someone at Head Office whose primary role is just to keep bugging people for progress reports and following up on all communications. As far as I know this is pretty standard for companies with their Head Office in Asia. No reason it couldn't work anywhere else.

For example one company has teams in 6 countries and IT support in another. This one guy isn't an expert at anything anyone is doing. His whole role is to be part of all communications, keep the work flowing, record all interactions and report higher up the food chain. If you have an issue you ask the overseas team with him included, and he makes sure they give a suitable and timely reply. He's even included in video meetings.

Answer 3

In scrum you work as one team and the team is responsible for the delivery of the sprint. You will all have different strengths and weaknesses, but try and avoid thinking about "my team" and the "Asian team". It is all one scrum team.

An essential meeting for a scrum team is the daily standup which all members of the scrum team attend. Each member will typically answer three questions every day:

• What did I work on since the last standup?
• What am I working on until the next standup?
• What issues are blocking me?

Using your example, during the first week of the sprint they should be giving a brief summary of their current progress on the task. If they've been given a two week task and you haven't split that down during sprint planning, then their update on the first day is likely to be that they have further broken down the task and decided on what they will work on first. This should give you an idea of the progress your Asian team members are making.

When they get blocked by something that should be noted in the issue tracking system and maybe an email sent to the person who can unblock them. It should then be mentioned at the next standup (i.e. less than a day after the problem was spotted). It then becomes the teams responsibility to get that issue unblocked. Each day at standup the blocked issue will be mentioned, as well as any progress that has been made on it.

If it's something that requires a small amount of work by another team member, then that work should be done promptly so the ticket can be unblocked. There's no need for this to take 4 days. If it is something that is going to require a significant amount of work by another team member, then the ticket may need to be dropped out of the sprint.

Answer 4

Why does it take them until halfway through the sprint to realise they don't have access to the primary artefact needed to complete the job? Solve that problem:

1. When planning the task, identify all dependencies, especially access/permissions
2. Have a separate subtask/phase that is "done" when all dependencies are met
3. Only start the engineering work after dependencies are met

This will catch most of the blockers, however planning is imperfect, plus it sounds like their behaviour is being done to avoid work, so use your authority to force them to restructure their approach to work by having them confirm when they start the task that they have all the permissions/access they need to complete the task. Ask them to use mini spikes, which shouldn't take more than an hour.

Finally, do not let them sit there doing nothing waiting to be unblocked - they are ripping you off.
If they are blocked, immediately park the task and have them start another. You then create a subtask to unblock the task and assign it to someone (including yourself). Creating the subtask is a way to track these issues and bring them to light to management and use as feedback to the whole team to improve your task refinement effectiveness.

As per Gregory's suggestion, given the timezone difference, either assign them secondary "filler" tasks ahead of time that they can start when so blocked (authoritative), or have them park their own task (and advise you) and have them assign themselves an unallocated task from the backlog (collaborative).

Your problem could be a symptom of overly an authoritative approach. Consider giving them more responsibility/freedom to manage themselves and what work they do and how they do it.

---

FWIW I use exactly this approach with my team. Often, access etc can be done by non-software engineers, eg BAs or platform engineers, freeing up devs to get more of their specialized part done. It also highlights blockers early, leading to finding better/faster ways of unblocking.

Answer 5

I see two issues:

1. The other team isn't starting work on time or isn't reporting issues as soon as they know about them.
2. It seems like your team is "punishing" Team Asia for reporting blockers in week 2 by making them wait 2-4 days when granting them access to a website should be a fairly quick job.

I'm not legitimizing Team Asia's behavior. That needs to be addressed but you need to prioritize the sprint work (as a whole) and not just your work. You can come to a reasonable stopping point in your work, switch over to grant them access to the website, and then move back to your work in less than 2-4 days.

Now let's get to Team Asia's behavior...

It seems to me that you've identified a pattern of behavior that is causing sprint work to be delayed unnecessarily. Typically you would contact the PM, outline a few examples of this behavior, and let them take over. In this case, it sounds like your team is acting as the PM?

Either way, as the PM I would have a meeting with Team Asia, walk through the examples that you provided, and ask them some probing questions:

1. During sprint planning we asked your team if you had access to the website that you were supposed to write automation for. Why did you say, "Yes", if you didn't have access?

2. When did you realize that you didn't have access? (I'm assuming the answer to this is in the second week of the sprint given your description.) This is your main task for the sprint, why are you waiting until the second week to start working on it? Are there other team priorities/work that are distracting you from starting your work on Day 1 of the sprint?

...and so on.

Assess their answers to your questions. They may be pulled in different directions... doing work on other projects, etc. and can't start on time. (NOTE: I don't know... I'm making up excuses for them that you need to sort out if they are a reality).

Assuming they have no legit excuse to delay their work, I would also make it clear that they need to start their work as early as possible, identify any blockers, and make them know to the PM/Team ASAP. Waiting until the second week of the sprint to start their work, throwing up a blocker, and blaming another team because they started late is not a good way to build teamwork.

If you continue to see this, you probably need to report this up the chain... you'll have to decide if that's up the chain of Team Europe or of Team Asia or maybe both. After this initial investigation, continue to report issues like this (you're officially documenting a pattern of behavior). Hopefully at some point management sees the continued problem this behavior is creating and will escalate up to maybe getting different/more contractors.

Answer 6

Change the sprint duration for them

2 weeks for a sprint isn't set in stone. It's a good rule of thumb, but that's all it is. Part of your sprint planning process is (or should be) figuring out the sprint duration so that coherent blocks of work can be completed without precisely this kind of pissing about.

These guys clearly can't handle the level of autonomy that a 2-week sprint entails. So the answer is simple - reduce their sprints to a week. Their work packages need to be finer-grained, but that's OK. The most time they can ever waste then is a week.

There's a further reason for doing this too. If you can't trust them on this simple level of communications, you also can't trust the rest of their input into the process. That puts a bigger question mark over their understanding of the requirements, their estimates, and indeed their quality of work.

Basically, they have become a risk which you need to manage. The two ways of minimizing a risk are to limit its likelihood to go wrong, and to limit its impact when it does go wrong.

Answer 7

I get a similar situation sometimes in a 'traditional' development setting, with an informal weekly cycle. East-coast/West-coast US. (I am on vendor side, in a joint development of software and hardware, many dependencies going both ways).

The reply "you just assigned me that yesterday evening, I will reply in a due course" sounds defensive and hostile.

That is essentially my response. It rarely if ever has to be said once established. Polite matter-of-fact tone. If they don't get it, stop apologizing. Staying up late absorbing it would just enable more of the same. (Which, to be fair, some people do. You decide if the $$ is worth it).

---

Note: The above would require the other side to have an incentive for timely completion of the whole thing.

Answer 8

What you are describing sounds a little bit like a culturally-based miscommunication indeed - a manifestation of a clash between higher- and lower-context cultures¹. This would (at least partly) explain problems with confirmed yet unfulfilled prerequisites and similarly with "we can't work, because we are waiting for your response/input". Which for someone with a lower-context background would be just un incomprehensible and irritating.

Preferably try to pull in someone who has sizeable experience in both cultures and try to solve it with him/her. If this option is not viable, and you are reasonably convinced the cultural differences play a role, level the playing field by explicitly asking for switching to low-context communication. Explain (on examples from the project) how you interpreted their communication, what your expectations were and are, and how you would like the communication to unfold in the future (i.e. reporting the problems right away, so that they can be solved sooner rather than later).

As these requests are typically coming from a lower-context environment to a higher-context one, they should be stated tactfully and politely (especially from the point of view of the low-context culture).

---

¹The gradient runs somewhat in the east-by-south-east direction from the international date line (with the exception of Australia/New Zealand), so Asian team will come from a higher-context background than the European one. Also see Wikipedia articles on High-context and low-context cultures and the concept of Face

Answer 9

Scrum already has a tool to deal with this. It's called the daily standup.. The standup is specifically there for two things- to check that actual progress is being made, and to identify blockers. (There are others too.)

In the example you give, it sounds like "I don't have access to the website" is something they should have found out very early on in their work. In fact if they don't have access to the website, what did they actually do for the first part of the Sprint?

To fix this:

1. Make sure you actually do a standup. It may be hard to find a time when both teams are in the office, but do it. Don't rely on written reports where you can't ask questions.
2. At Standup, make sure actual concrete actions are listed as done. Not just "I worked in this story" but "I investigated the current behaviour of the website" or "I started writing the download dialog."
3. Have the Scrum master specifically ask every standup "Does anyone have any blockers?". If There are address them.

Now if someone raises a blocker late in the Sprint you can reasonably ask why they didn't raise it before? Didn't they try to use the website before? What were they doing? Ask to see the code they have written so far. Don't do this in public to humiliate them, but in private. But get real answers.

All this will establish if they are playing a game or genuinely bad thinking ahead. In either case they need some coaching. Tell them what they should have done to identify the problem earlier.

Then monitor all this next Sprint.

Answer 10

Not your problem, keep receipts.

We have this issue at my org as well.

We burnt a lot of time and shed a lot of tears over this issue, until we realized that at it's core, this was about managing expectations and clearly communicating responsibilities.

You might assume I'm talking about managing the expectation of this remote team, and communicating their responsibilities to them - that's not wrong, but it's only a small part of the recipe for success.

The people who REALLY need to be kept in the loop here is management.

If your management, and their management, is aware of this problem and in CC on these conversations, you'll discover that all the sudden reporting a blocker 4 days late is no longer perceived as your problem, because it isn't your problem when you've got a documented history of telling these people that it takes 1-4 days to process a request.

That is CLEARLY a ball-drop on the part of the other team, and the unblinking gaze of they who write the checks will swing in the proper direction very quickly if they're made aware of an obvious ball-drop that keeps happening.

Another way to look at this:

With software, sometimes you have to allow the system to fail so that you can observe the faulty behavior and find a fix. If you keep trying to bandaid the problem so that the failures are transparent, it gets harder to root cause the issue and resolve the problem.

Human systems are no different - when a process fails, you need to enable debug and get the output of that debug to the people responsible for maintaining and repairing the system. By continuing to "own" this problem and take (or accept) responsibility for bailing out these other teams on their timeline, you're interfering with management's ability to diagnose and resolve the underlying problem. You have to let them drop the ball when they drop the ball.

It can feel weird and antagonistic to push back against someone putting that responsibility on your shoulders, but in order to enable their ability to do their jobs, you have to make it clear to them where the problem lies and provide them with actionable intel.

Answer 11

Split up your tasks into two stages:

• Identify all the requirements/blockers
• Implement the task

The first stage is a ticket for sprint one, during and after which you clarify whatever they report in that sprint as a blocker/information request. You add all the info to the ticket for the second stage and then schedule that for them. Now they should not have any issues in the second half. If they do (too much) you need a contractual clause that allows you to pay them less for not having done the ticket in phase 1 correctly.

Answer 12

It sounds like part of their complaint isn't about how fast you can solve the issue, but literally about how fast you reply initially.

In many situations, a professional approach is to reply as soon as possible with an appropriate "off-the-top-of-your-head" response, like "I wasn't aware of this issue before. I will look into it and give you an update by Thursday." Notice how this reply doesn't even promise whether you'll be able to fix it by Thursday or not, just that you'll give an update. The purpose of this reply is to acknowledge their request and accept responsiblity for some next step. It also gently reinforces some boundaries of your responsibility. For example, after you sent that, it would be awkward for them to bug you about it before Thursday.

With practice, you can write such an initial reply in a couple minutes or less, making it entirely manageable to send an initial reply soon after an issue is reported.