Challenges of a small company working with an external dev team from another country

Question

I am a PO at a small company in the UK who are in the early days of SaaS development (using Agile Scrum). It was recommended that we use the external dev team which we have now instructed. This team consists of:

• Scrum master
• Lead developer (full stack)
• Developer
• Business Analyst
• Designer

We have our own in-house data engineering team who manage our data and do create most the functions needed for the product. I have never worked with an external dev team before, let alone a team from another country that I realistically will probably never meet face to face.

Question

How would I need to adapt my role as PO to lead the dev team effectively?

Answer 1

If you are following Scrum and Agile principles, you need to keep doing that. What I mean by that is that some people will have a tendency to give up on certain desired things just because now they are harder to have when working with a virtual team.

For example, you might be tempted to skip the daily standup and transform them into a larger, once per week meeting because it's easier (especially if you work on different timezone), and because it's no longer a standup, but a sit down behind a laptop screen. And this can happen with other things that were easier to do in person. You need to keep doing the Agile practices but think how you can achieve similar results with distributed people.

You will rely more on tools and technologies, and you will probably also need to be careful when selecting them to facilitate the work. Additionally, you might have to go through a few tries before finding something that works nicely. For ex, you might discover a physical whiteboard that offers maximum flexibility will need to be replaced with a more rigid tool that makes it harder to achieve the same result. Do you still try to go with as similar result, or do you give up on the result you want and just fall into the way of working that the rigid tool imposes?

That's the way you need to adapt. Think what result you want, then see how you can achieve that given the complications of having a virtual team as opposed to a colocated team.

With that being said, there are some other considerations to keep in mind, that don't relate to Agile or Scrum, but to the fact that you now have an external team. I'll mention a few big ones of the top of my head, but you will need to pay attention during reviews and retrospectives to spot others.

Us vs Them

This mindset can creep in when working with external teams. We are the brains, you are the muscles. We make the business decisions, you handle the execution. It's our project, you just work on writing the code. You need to pay attention to this kind of behavior and make sure it doesn't happen. There needs to be team ownership on the product that you are delivering, even though you have some people in the UK, and other some place else.

Cost vs Quality

You don't mention why you went with an external team in another country. Could it be in order to reduce cost? There is often a strong relationship between cost and quality. Make sure you are getting back also the desired quality, not just a reduction in cost.

Image vs Value

Following on the previous point, make sure that the team is generating value, not just present an image that things are going in the right direction. Sometimes, external providers put too much accent on a good relationship with the client and paint a positive picture, even if that means sacrificing some aspects of the product.

Culture

You didn't mention where the external team is located. If there is a large cultural difference between your in-house teams and the external teams, this can cause all sorts of misunderstanding, assumptions that then prove false, or affect the collaboration in weird ways. See for example the power distance index.

Answer 2

Some things that can help:

• If you can, have a kick-off and get-to-know session with them
• Have a session to agree on roles and responsibilities
• Your retrospectives become especially important
• Smaller stories will help, as they will allow the team to frequently demonstrate to you during the sprints
• Chat with the Scrum Master about "definition of done" and "definition of ready"
• Regular 'social time' sessions will also be useful to break down the communications barriers

Answer 3

1. You need to consciously replace the functions of an in-person office. For example, some teams use an in-person workplace as a communication tool where X will randomly overhear A and B talking about implementing some feature and jump in and point out that it will conflict with the other feature that C is currently working on (or "disaster avoidance by luck"). That won't happen remotely, people won't know about things unless you explicitly tell them about it ("disaster avoidance by planning"). Other functions of an in-person office include a sense of camaraderie, removing yourself from work at the end of the day, etc. These can all be replaced but it won't happen by magic, you have to consciously do it. This is often more work for the management layer but less work for the entire rest of the team.

2. It also sounds like maybe this team is new or at least new to your product? In which case you also have to do all the things you would do with an entirely new team. In an established team often the PO can leave out business details that the development team will fill in through past knowledge or by knowing what questions to ask. With a new team, they are at the stage of unconscious incompetence -- there are business details that they won't even realize that they don't know, they don't even know that there's a question they need to ask. Note that I'm specifically talking about business knowledge--the technical team may be very experienced technically and still completely inexperienced with your specific business. So as PO you need to take about 10 steps back and concentrate on describing the business value as clearly as possible--the "why", not the "how". Since the team includes a BA try not to let it become a game of telephone--developers should have access to primary sources for the stuff they're working on as much as possible (requests from users, regulatory documents, etc.) as well as your interpretation and the BA's interpretation.