Bsrgvty

I joined a company where the development is outsourced in an offshore location. I have heard that the people offshore won’t deliver unless they are chased to do so.
In other words, when they are left to decide how much is too much, they will say commit to 40 points, whereas when pushed to do 60, they will deliver 60.

Therefore, management (onshore) has tried a few times and ended up that they need to control the teams (micro manage) in order to get an ideal result. “Lazy, incompetent, lack of proactivity” are some of the words used for the offshore team. Equally, I have observed that the offshore team is disengaged, from the little I’ve seen them in the video conf.

How do we provide more freedom to the offshore teams to decide, but also trust that they do the best they can, without compromising product delivery? Because the danger here is that the development slows down, and the team offshore takes advantage of the relaxed approach and starts delivering less and procrastinating more (based on previous experience).

when pushed to do 60, they will deliver 60.

This is a pretty meaningless measure in these circumstances. A team could drop quality to deliver more points or simply game the estimation of stories. Story points and velocity were designed to help teams estimate their capacity in a sprint. They are not intended to be measures of performance.

If you want to establish a good relationship with the offshore team then I would suggest some or all of the following:

• Meet with the teams in person (either onshore or offshore). Establish a relationship with them and gain an understanding of what is motivating their behaviour.


• Build mutual trust. It isn't just about you trusting your offshore team, it is also about the offshore team trusting you. If they think they are being judged or blamed then they are likely to be defensive.


• Empower the team. Help them to get engaged in design and architecture. Make them feel like their input is valued. Proactive behaviour comes when people feel they have value.


• Try and break down the distinction between the onshore and offshore teams. Make sure meetings are held jointly (including retrospectives). Use chat programs like Slack or MS Teams, etc.


• Arrange your daily Scrum at a time when everyone can be involved regardless of location (if possible).

Velocity Isn't a Productivity Metric

In other words, when they are left to decide how much is too much, they will say commit to 40 points, whereas when pushed to do 60, they will deliver 60.

If you are managing to a velocity metric, then you're Doing Scrum Wrong™. Velocity is a capacity metric, and has no utility in measuring a team's productivity. Even if it were, adopting an agile framework like Scrum wouldn't necessarily make teams more productive.

What velocity should do is achieve a stable, sustainable state. A sustainable velocity make process inefficiencies more visible, so you can address them. It can be used for secondary functions like estimating lead time only when:

1. The range of a team's velocity is relatively stable.


2. The work to be estimated is granular enough (and familiar enough) to avoid guesstimating about "unknown unknowns."

Trying to maximize velocity metrics is a an anti-pattern. Instead, you should increase communications and transparency around your Sprint Goals.

Leverage Sprint Goals

When you misuse velocity as a management metric rather than for its intended purposes as a planning tool and detective control, you're defining a target level-of-effort by management fiat. As a result, you're practically begging to be given inflated estimates by teams that try to meet these "visible effort" goals. Don't do this to the team, your project, or your company.

Instead, you should switch to an increment-based metric where a central coherence is either "done" or "not-done." The Sprint Goal was designed for that purpose, and should be what you're using to determine whether the team delivered what it planned to do or not.

The purpose of a Sprint isn't intrinsically to put in a lot of effort, do lots of things, or perform lots of tasks. The goal of a Sprint is to deliver the Sprint Goal! As such, the framework actually requires that each Sprint have a central coherence that defines it and ties all the work for the Sprint together. This is often a feature (or set of smaller features) that forms a logical increment of potentially-shippable work. This goal is set internally by the team, and is not just another way to impose a management target.

At the end of each Sprint, the Scrum Team and stakeholders use the Sprint Review to inspect the increment together. The Scrum Team then feeds the results of the Sprint into the Sprint Retrospective to improve their processes, and into Backlog Refinement and Sprint Planning for further work.

From a management perspective, a team that meets its internal Sprint Goals more often than not lends predictability to a project. A team that misses its own Sprint Goals more often than not may need additional resources (like money, staff, or a strong agile coach) to succeed.

Managing Performance

There is no silver bullet to managing performance with Scrum. While the transparency, visibility, and communication enhancements of the Scrum framework can certainly increase the efficiency of mature development teams, it will not allow companies to hire junior resources or mediocre people and wring anything more than predictability from the process.

Obviously, there's no way for anyone outside your company to determine if the inability to reach your project targets is due to poor target-setting by management, poor performance by teams or individuals, or poor agile release planning. It's important that your management team works closely with the Product Owner and Scrum Master to ensure that all stakeholders agree on the current release plan, and that the plan is continuously updated based on the current state of the project.

If management defines the release plan, rather than allowing it to be an emergent property of the agile inspect-and-adapt cycle, then this is unlikely to be successful. There are a lot of reasons for this, but of particular concern is the fact that an off-shore team is often not just a team but also a vendor. A vendor/client relationship within an immature Scrum process is unlikely to result in the level of honesty and transparency required for the Scrum Team to push back and say, "We can't reliably meet those goals."

On the flip side, if you have a mature agile process, but your Scrum Team can't provide you with the level of productivity you need, you will need to:

1. Revise your expectations downwards.


2. Train and improve your existing team.


3. Replace your existing team with another team or vendor.

These choices generally require increased budget and run-time for the project, so they are a cost of doing business rather than a cost-free activity. Nevertheless, they are among the primary choices you can make in such situations.

TL,DR

The throughput of an outsourcing team depends mainly on culture and expectations on them. Consider both aspects before acting.

I believe there are a few aspects that are prerequisites to be understood before entering into the actual solution.

Why Outsourcing?

First of all, there's a reason why companies outsource to offshore locations. In most of the cases, offshore is done for costing reasons. As higher the cost differences between onshore and offshore, as likely to be the quality difference.

Cultural differences?

Each culture deals with well... life, differently. There's entire (highly suggested) books about it. Some cultures may, as you said, work better when receiving explicit or implicit messages.

Now, considering the aspects above, to your question:

How do we provide more freedom to the offshore teams to decide, but
also trust that they do the best they can, without compromising
product delivery?

You'll have to understand your team, their people and their culture. As Barnaby mentioned, a constant communication (daily meetings, constant trips, etc) is required. but not only that. You have to consider that communication is required and understand that they'll deliver (and work, for the matter) according to their culture.

If, after studying such culture you believe you can push harder for more deliveries, you can experiment. But always consider the cultural factor. If you provide a candid feedback to a North American saying he's not as effective as you expect, he might deliver twice next time, as usually North Americans are very objective on their conversations. However, if you do the same with some Brazilians (I talk by experience!), you might have the opposite effect, as Brazilians could consider this offensive and that you're attacking him personally.

Lastly, do not generalise - there's room for several cultures within a single country or group of people. Just because people in Rio de Janeiro loves beaches, it doesn't mean everyone stays at the beach 365 days of the year. just because São Paulo is a very busy city, it doesn't mean you won't have people just 'faking' work from 8 to 5. These are obviously examples, don't consider them literally. That's what I meant by understand your team.

I have 13 years development experience. I worked as an outsource engineer for Weight Watchers from Jordan, and then later in my life I did manage outsource teams myself. I also managed onshore teams.

Managing teams when they are offshore can be different, but motivation i don't think its much different specially for talented engineers. Whatever motivates you and your onshore team it must also motivate the offshore team. However here are some notes that can be helpful

• 
  Get them involved in business. Getting engineers involved plays an important part of agile development, and it is a great motivation for talented people. Get them in those brainstorm sessions, ask them about their thoughts, which parts needs fixes or enhancements and take their feedback seriously.


• 
  Get them to visit. One of my favorite trips was to NY Weight Watcher offices, I stayed there for 3 months, got to know the team much better and this has given me tons of motivation. It doesn't have to be that long stay if budget doesn't allow. Two weeks visit can be great two. You can also go and visit the offshore team in their country.


• 
  Thanks emails. After a major release that recognition of team effort email does a motivation magic and get people really feeling proud of their accomplishment.


• 
  General social relations. If visits is not easy to do, still on chat and phone you need to have social relations. You need to talk and discuss and stay close. Think of other things to talk about other than the usual weather talk!

Well if I think of more points I'll share more.