Building that Agile Team

build-that-team1

An increasing number of offshore service organisations proffer startup incubation services. Every startup product (or project) owner wants to have the best team to deliver the outcome on time and within budget, irrespective of it availing the offshore service. Building teams is essentially a complex problem; identifying individuals that will cooperate and compete, and work to the same goal. It is therefore important to understand just what the various candidate evaluation methods attempt to achieve, and to what extent (if any) they are successful.

Every potential candidate presents four characteristics, viz.,

  1. tacit-knowledge
  2. explicit-knowledge
  3. experience
  4. mindset

Some of these characteristics are easy to validate through standard test techniques, while others are very difficult. The tests for candidate selection increase in cost as the characteristic itself becomes difficult to pin down. For example, tacit-knowledge, is very difficult to verify objectively, as it is non-transferable. Although, it can be observed in experts, such as, surgeons or highly skilled programmers.

Experience by itself is the easiest to validate and by itself the most redundant of all of them. It is difficult to ascertain if increased experience makes for increased tacit-knowledge. It is unlikely that experience by itself would be correlated to tacit-knowledge, one would also have to add ‘mindset’ to this mix.

Most organisations have a standard number of steps for candidate selection, usually increasing in technical difficulty. This is the most effective way for service companies to show speed while containing costs to build teams for new clients. But, the problem is that all these different layers give a false positive of the candidates suitability, as it only tests for explicit-knowledge. These types of question-answer sessions do not provide idea of the other three characteristics vis-a-vis the candidate. This technique may actually give a false negative, and the organisation looses a potentially good candidate.

Two of the characteristics, viz., tacit-knowledge and mindset cannot be measured through a question-answer sessions, no matter how many levels. It needs a more immersive situational techniques. It needs the creation of a environment that will mirror the actual. And, a situation that will provide an opportunity to observe the candidates responses.

  • Run a mini half-day to a full-day sprint (in the agile language).
  • Up to three potential candidates can be asked to take part at a go, these are selected from the final group selected after the preliminary selection process.
  • An existing employee must be added to the team.
  • The problem presented to them must be verified as executable within the timelines set for the sprint.
  • It must be obvious by now that this is not an easy exercise, and also explains why most offshore service organisations shy away. It is costly. It requires very high competency from the human resource department. It also requires a high degree of technical competency from the organisation.

Conclusion

Getting the composition of members for the team right is very important. If tacit-knowledge is difficult to quantify except through observation, it is equally true of mindset, which is a mix intuition, orientation, and improvisation. These characteristics do not have some mathematical or psychometric formulae that can be used to compare individuals capability to become successful members of an agile software team. They may be observed during execution or can be inferred (with difficulty) after the event.

If you have an unbalanced team (in respect to the characteristics mentioned above) then it is highly likely that something will give. It could delay the drive to market, particularly critical in the current cloud environment. It could delay the feature release, allowing a competitor to jump in first. In the worst possible scenario it could lumber the client with a dysfunctional team. Know your risks when you build a team only comprising of members validated for explicit-knowledge. It is not wrong, but there are consequences to the outcomes and your goal.

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, management, team building. Bookmark the permalink.

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