This post is the second part of a series on setting up and scaling a distributed development team and addresses various phases involved in setting up a distributed team from its inception to success.
Distributed Development Team: Setting up and Scaling [Part 1]
Distributed Development Team: Setting up and Scaling [Part 3]
Every initiative to scale-up comes with its own specific set of opportunities and constraints. Multiple elements are involved in getting a distributed team to work:
- people & objective
- knowledge & process
- cultures & mindset
Some of the above elements need elaborate preparation and planning. Certain aspects such as the objective should be shared upfront in the existing organization and accepted so as to enable participation and support at all the different layers in the organization that will have a role in the formation and operationalizing of the distributed team.
The other aspects of Organizational Preparedness are:
* Executive level support for the distributed team endeavor – to ensure that the people responsible for this initiative on both the Parent Organization and the distributed team side are sufficiently empowered to make timely decisions and are not left to defend and justify all their actions and decisions. This is best enabled by having an executive level member entrusted as the Single Point of Contact on the parent organization side.
* Organizational focus from all involved departments in setting up the distributed team- to ensure that the needed support from the different functions across the organization happens in a coordinated manner without having to chase all the stakeholders to pitch in for their part.
* Acceptance at the employee level to adopt, mentor and work with new setup without the typical fears associated with outsourcing – by keeping the employees informed on the background and objectives, the chances of being motivated to participate and support this endeavor are high.
* Organization culture enabling participation (openness, transparency, trust) – to ensure that people from both sides–the parent organization as well as the distributed team feel comfortable to discuss real issues and realistic options without the fear of being shot down for identifying/reporting improvements. There can be no perfect plan to enable a distributed team development team. A lot of improvisation has to happen as the team starts rolling out. Hence a culture that enables participation, delegating responsibility and building trust between the existing and new units is a big enabler.
Some of the elements can be tamed and amended to suit specific needs. However, some of them can’t be resolved (for e.g. culture, it existed much before this endeavor; your best bet would be to get the different cultures to work together). The overall approach should be to in-source solution(s) and not out-source your problem(s).
In the next part, I will share my experiences on the aspects of working with smart knowledge workers and setting the right expectations from the distributed team.
Rajaram Parimi has over 15 years of experience in Software R&D, Consulting. All these years he has been part of distributed development setups of major European software companies. He is been participating in Agile development since 2006 and successfully embedding Agile concepts and strategies in the various growth phases across multiple software development companies. In his last assignment he has successfully set up an offshore software development centre in Hyderabad, India for a major Dutch ISV and scaling it to a size of 50+ people and grooming the next level of agile leaders.