Building a Better Development Team?

mlawmlaw asks: "I'm part of a development team that provides internal applications for a large pharmaceutical company. The team consists of about a dozen members, some coders, some application developers, and some vendor managers. About twice a year we do some sort of group exercise that almost always focuses on team building. After doing this for the past few years, we have found that while we have built a team that works well together, we have missed the boat when it comes to developing other team skills. We need to focus on better ways of identifying and solving technical problems and developing stronger critical thinking skills. But how do we do this? Teambuilding was easy, bring the team together and do exercises in trust, recognizing diversity, and discovering your teammate's backgrounds. So I am asking the Slashdot community, what have you found to be effective in building a better team other than exercises in teamwork?"

Comments

Feature Driven Development

[aaronli]

Try looking into some of the techniques used in Feature Driven Development.

http://www.nebulon.com/fdd/index.html

Part of the impetise for creating this methodology was to produce a project structure that naturally builds (and rebuilds) a competent team.

Excellent post but I have one more...

[ajuda]

Let developers know what they are building BEFORE they start building it.

Re:Excellent post but I have one more...

[Alpha27]

I feel you can do both. There is an importance for all involved to know what is it that the application should do before a line of code is started. It's like taking a road trip, I'm going from point A to point B along this route. But somewhere along the route I learn that one of the exits I was supposed to take was closed due to unforeseen events, so I take a short cut, it adds some time to my trip. I get back on course, and learn from someone along the way (you have to take a pitstop everyonce in awhile) that there's a short cut, I take it and save time.

Ultimately, everyone knew where we were heading, what we needed to do to get there, and how to compensate for unforeseen events. The same thing can apply to software design. You need to know your overall goal. That overall goal will never be the same as it will be when it's done, because we are creatures of trial and error. If you're building something for the first time that's never existed before, there's bound to be some changes. You probably won't drastically differ from the overall idea; ie: making a RTS game instead of the original idea of a turn-based rpg, unless the market just one accept it. Remember, we are creatures of trial and error. Somethings work the first time, and sometimes they don't. And when they don't you take a different approach to make it work.

I've worked in a situation where we built an in-house shopping cart system with user-filled products for a wholesale market place. Once we built it, we ran into something unexpected, we didn't account for item types. Sure we had the name of the item, the description, but we had no way to say in the system that a 'cap' and a 'hat' were the same. The shopping cart did everything as requested from the overview, but that one glitch, prevented a more enhanced search system.

As for building things that are already out of date, we still use software that is years old, does it mean that it's out of date? Well if you wish to equate the original planned designed to the outcome of the product, then yes it's true, but just because something might be out of date in that respect, doesn't mean it's out of use. So I'm not entirely sold on the out of date argument.

Book: Working With Emotional Intelligence

[shunnicutt]

I've just finished this book, written by Daniel Goleman, and I heartily recommend it.

Its premise is that there are different emotional competencies, and that these competencies distinguish outstanding performers from the merely average. One of the points is that the technical skills required are merely the threshold -- you have to meet these requirements to get the job. How you manage yourself and your relationships with others is what makes your breaks you.

The studies mentioned indicate that the more technical the job -- the more rarified the subject matter -- the more these emotional competencies matter to job performance.

This isn't a self-help book. However, it does break these competencies down into several areas and discusses each one with research and anecdotes.

Most important, it has a chapter dedicated to what you should be looking for in training programs that purport to increase the emotional competency of the people being trained.

Seriously -- go to your public library and check it out. Just being aware of these factors gives you a different perspective on your day-to-day life.

Look at teamroles (belbin)

[Reinout]

You should spend half a day on Belbins teamroles with your team. Probably you can say to your personel department that you want to do a belbin course with your team, they'll hapily hire someone for a day to guide you through it.

The generic idea is that there are 8 or 9 roles that surface time and again in teams. You've got someone sprouting ideas like there's no tomorrow. You've got some finishers that want to get the job done.

• Every role contributes something to the team process
  
• If a role isn't filled in the team, it creates certain problems (some are bearable, some disastrous)
  
• A role can go awry and will exhibit known irritating behaviour.
  

Once you know what roles are available in your team, you can start some serious thinking. You might miss the 'bitching' type that rightfully shoots wrong ideas before they're implemented. You might have too many captains on one ship. Etc.

From what you say, it sounds like you're perhaps missing one or two roles in your team. It's very possible that one of the existing team members is perfectly capable of fulfilling that role (but doesn't know it or doesn't dare it). After such a session you at least know what's available and what's missing.

Good luck!

reinout