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

team effectiveness

[sribe]

Hire people with strong critical thinking skills ;-)

Some suggestions

[Alpha27]

The main thing is to ensure everyone knows the following:

• all individuals know the overview of the product, timeframes, and who is doing what in a general sense.
• project managers have a good ear (figuratively speaking) and a knowledge for the technology, since that will be your point person with everyone. I think it's imperative to have a tech person with many years of experience as the PM since they have been in the programmer role and have a very good understanding of what's going on. If this person can get to know more than just what the thing does, such as howit works, then that person can help to identify any potential problems that might arise in other development areas.
• code review, alot of people agree with it, but very few do it. "code review takes time" well fixing bugs or seeing wacky coding takes time as well, and if you get it right the first time and not rush it, then you should be ahead of the game. this can also be done with extreme programming with paired workers
• have a road map available at all times. I've seen places with no clear map written down, and just general stuff floating around. I'm at least seeing user storys used, but those user stories should be feed into a larger document that details the project in all
• have a list of everyone's skill sets available, making it easier to identify someone who might be familiar with a particular library, or personal experience

one other suggestion I would throw in: It might help to rotate the members around a bit with different job assignments. For example, One person might work on fixing bugs, the other on adding features; flip the rolls, and have the two talk with each other about their processes in the job function and see if they learn from each other.

and most importantly, do the bar thing. it sees that thursdays works out best for people. you can all swap previous work condition stories. like "I remember when we had this one programmer who would store ALL OF THE USER'S DATA INCLUDING THEIR CREDIT CARD NUMBER in an unencrypted cookie, and my supervisor wouldn't fire him because he owned (as in responsible) the code for the registration."

=)