We we are dealing with distributed teams, there’s a few things to consider when you’re constructing your team. Amongst those of highest importance is the distribution of roles. In particular I would like to address the ScrumMaster and the Product Owner roles.
The ScrumMaster
ScrumMasters are usually placed in the location closest to the nearshore business. Most arguments I hear is that “the ScrumMaster is the owner and enforcer of the process – we need to have this process under control, so we would like the ScrumMaster to be close to our business”. While I do not dispute this argument, I would also state, that it’s very possible (and a good idea) to place the ScrumMaster in your offshore team – especially if you have a better suited process-personality there. As we know, the ScrumMaster is the enforcer and owner of the Scrum process – and if done correctly, the process is going to live and thrive on both offshore and nearshore location. Having your ScrumMaster located on the offshore side helps bridge the connection with your nearshore team. Why? Because the ScrumMaster have to be aware of all the things that goes on in a team – on both sides – and hence, you will have a facilitator who are communicating a lot across the teams.
The Product Owner
The Product Owner role is most often placed nearshore. It’s vital that the bandwidth between the business and the Product Owner is as high and wide as possible. But at the same time, it requires a special breed of Product Owner to become succesful with a distributed team. Being available and being ready to answer questions that the team might have (offshore/nearshore) is vital for the teams success. If the Product Owner and the ScrumMaster are good communicators (also with each other) then the bridge between the offshore and nearshore part of the team should be well established. In complex businesses or in larger teams, it’s often advised to assign the role as “Proxy Product Owner” to a business oriented person in the offshore team. This way, the developers on both sides have direct (and quick) access to business logics and information at all times. It can be compared to the “Scrum of Scrum” pattern.
Placing your roles in a distributed team can eventually mean success or failure. It’s important to understand that placing all the roles on one side of the team will skew the balance and the understanding that each team member has of the team and the delivery. Another aspect is also, that when placing roles distributed, you will also add a different level of “trust” to the team. This is vital for the team to evolve, develop and progress ahead.