How does one turn a small group of individuals into a team, one that is focused on a singular goal? The answer seems to lie with communication. Communication not in the sense of a mere exchange of information, but one that leads to dialogue. And dialogue creates the shared knowledge space for the problem, and leads to the emergence of a collaborative group of individuals, a team in essence.
In the context of outsourced offshore development (specifically, when it comes to software product development), this need for creating a dialogue takes on a much greater importance. Teams rarely have an equal level of experience, in most cases the team composition spans very little experience to a high level experience. The actual composition is very much dependent on the clients purse size.
The typical team is composed of one or two resources with the relevant experience and capability for “Deep-Work,” the rest of the team will be mid-experienced to low-experienced resources. One would think that the client, having understood the composition of the team, will also adjust his expectations accordingly, the answer is no. The knowledge be it domain or technology that is being absorbed by the team members is considered as an intangible benefit that the client is passing on. This argument ignores that the team members are individuals each with a very different ability to assimilate and learn new domains or technologies. This problem is compounded by the application of agile techniques via scrum (or something similar) in principle but not in the true spirit of it.
Agile/Scrum is not seen as techniques whose primary aim is create a dialogue amongst the development team and between the stakeholders and the development team. But, more often than not it is seen as a tool to monitor and control the work of the team. In this mind set the stake holders focus on the burn down and velocity, having replaced cooperation and communication with stories and tickets. Stories lend themselves to dialogue through a deliberate effort, left to themselves they are nothing more then a highly formalized minimalistic form of communication. If you want a dialogue with your team then make it happen, Agile/Scrum won’t magically bring it about particular if the aim is to pay only lip service to these techniques.
This is perhaps one of the most compelling reason for advocating team colocation for product development. Such a setup would ensure the cooperation of take holders and collaboration amongst the developers. And, this is should guarantee a continuous dialogue during all stages of the product development, and more importantly a dialogue during the critical early stages of the product. There will be rare cases when this may not happen, but there will be enough opportunities to stop a complete break down of dialogue.
It is very easy for distributed teams to gravitate away from dialogue into a soup of stories, tickets, burn downs, and metrics. A committed leadership is required to steer the team to dialogue not tickets, and narrative not stories to ensure a successful emergence of a team and not just a collection of individuals.
This is not an attempt to suggest that distributed teams are not the vehicle for product development, and neither is it an attempt to negate the outsourced offshore model for such distributed teams. It is to emphasize that real leadership is needed here, not one that sprinkles the words Agile, Scrum, and devOps at the appropriate time, to only walk away from it later on.