Do Your Homework

This is just a reminder to myself and the readers of my blog that it is critical to understand the originating domain and context under which new advice/principles/practices being applied to software development came from.  Taking ideas that sound great on the surface and running with them can be catastrophic if those ideas are not well understood as they can easily be misapplied e.g. no testing as a reaction to “ceasing mass inspection” or the blind use of manufacturing principles in software development.  For those of us leveraging Scrum, have you read the original seminal paper on Scrum as a Product Development Game?

I’m not discouraging looking outside the field of software development for radical ideas as I don’t believe the field will evolve if we don’t do so.  Rather, I’m suggesting that we become more accountable in the application of these borrowed ideas.  Let’s understand that our domain is unique in its own way and grow it in a responsible manner.

Advertisements

Team makeup – what should we look for?

People make things happen.  I’ve always believed the success of a team lies heavily on who makes up the team and it’s the managers number one responsibility to acquire the right individuals for their team.  So what  should a manager look for in potential team members?  I have three key things to look for:

  1. Technical competency
  2. T-shaped skill set
  3. Personality types

Technical competency should go without saying.  We need people who can do the job and do it well.  Even if they can’t do exactly what is needed, they should be capable of learning and subsequently doing what is needed.  However, beyond just being technically competent, they also need to be driven to improve technically and must have pride in their work.

T-shaped people can also be referred too as being “poly-skilled”.  In everyday life, most of us are poly-skilled.  We can cook, clean, read, drive and the list goes on and on.  In knowledge work, these are individuals who can do more than one thing.  For example, program in C# and write user stories or perform some DBA-type functions and also write automated tests.  In essence, these are people that are not one trick ponies. Teams that scale effectively are usually comprised of T-shaped team members.

The last, but most important thing, in my current opinion is looking for different personality types to complement each other on the team.  I know of teams that have prospective new hires take personality tests and while I don’t know if I’m in favor of that yet, I can definitely see how doing so could be valuable.  Having a range of personalities on a team naturally provides for variety of opinions which is always a good thing.  For all the bullish people on the team, having a couple of bears balances things out. For all the outspoken individuals, a couple of reserved team members may help the group actually think things through

This was intended to be short and discussion provoking.  If you have others things you look out for, please share.