When it comes to offshore product development, an oft-committed sin of recruiters is to continue to hire people for the product teams without due consideration of their impact and influence on the current team members and its dynamics, furthermore the impact this would have on delivery and development. This short sightedness was perhaps not an issue with fixed time waterfall projects, but in agile product development it puts in jeopardy a potential long-term engagement for the organisation. Understanding the dynamics of software development teams, and hiring the right people to be part of an effective and efficient team is more than just hiring individual “Java developer with 6 years experience”. Efficiency is mostly dependent on individual skill, but effectiveness is dependent on the team members working as a gestalt body to a single goal, that is, the team goal. There are now umpteen different ways of testing the skill of an individual, but there is paucity of measures for evaluating the participatory abilities of the same individual in a team.
To build successful teams here are a list of some of the pitfalls to avoid.
- Minimise hand-over amongst team members in the team, lets repeat that “Minimise hand-over amongst team members in the team”. This separates out work into “my-responsibility” and “your-responsibility”, rather than one of “our-responsibility”. Create small sub-teams of 2 (maximum 3) members that are entirely responsible for delivering a unit of work that can be demonstrated to the client. You not only want to create a sense of cooperation, but you also want to create a sense of competition, this is what gives rise to an innovative team environment.
- Too many hand-overs amongst team members also bury problems that will get exhumed at the worst time for product delivery. Cause and effect are separated in time and space even in software development.
- The recruiter mantra should be an emphatic “you can’t do just one thing”. No prima donna, no one skill wonders. An extreme case of a prima donna behavior was a software architect who insisted that no coding would begin until all the REST APIs and the data model had been documented. Furthermore, once documented, he insisted that no changes would be entertained. It was not funny then, and it is not funny now; all this just a couple of years ago. This was not an example of the agile “fail fast” principle, but more like fail the engagement any which way.
- Use gamification (game techniques) to identify the best team players to build successful teams with longevity. This is known technique (applying game thinking and mechanics) applied in many fields, for example, marketing.
- Just as in many other areas of computer applications, big data is seen as offering a promising way of hiring good fits for the team, but we doubt this. Unless you can quantify all the qualitative measures, you will still need a human to make the final decision.
Building software products is not a walk in the park; a successful product is a very stressful and time-consuming endeavour, with many opportunities to fail. Some mistakes, like building the wrong product, not knowing your market, or having a very high burn rate cannot be influenced development team. But, the reasons for failure that can be avoided are those to do with team building and team structure.