Team Building – You Can’t Do Just One Thing

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.

  1. 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.
  2. 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.
  3. In this era of software development we should not still be differentiating between front-end and back-end development. An x-language developer (x could be any of Java, PHP, Ruby, etc.) must have a working knowledge of HTML, CSS, and JavaScript at the minimum. Building software solutions is about focusing on the business problem and not on building your very own platform (unless you are building the next generation of Facebook or Twitter) or boilerplate code, when you can choose from the many frameworks that are available.
  4. The recruiter mantra should be an emphatic “you can’t do just one thing”. No prima donna, no one Onemanbandskill 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.
  5. 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.
  6. 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.

 

About KM Mukku

Kick-start, build and manage teams in product development (particularly in the financial domain), and enjoy all in adaptive case management, business process design and business process improvement. Currently holding the position of CTO at coMakeIT.
This entry was posted in agile, product development, product outsourcing. Bookmark the permalink.

2 Responses to Team Building – You Can’t Do Just One Thing

  1. Pingback: Internet ends the nerd versus bro war | The Blog

  2. Pingback: Ohio Softball Participates in Team-Building Activities – Ohio University Athletics | The Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s