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

Effective Communications

[hol]

While having a solid development team (in terms of people that know and trust each other) is important, nothing, at least in my experience, derails a team faster than poor communications. Not just internal (which one would assume is good given the team is "built"), but external communications as well.

The foundations of this:

• Clear expecations:
  
  • Expectations management
    
  • Captured (i.e. written) expectations
    
  • Checkpointing those expectations
    
  • Prioritizing the expectations - some are more important than others
    
  
  
• Bi-directional, effective communications to and from the team
  
  • Status reports, both individual and summary
    
  • Short meetings, with agendas, and action items at the end
    
  • Avoiding unneccessary people at meetings
    
  
  
• As far as possible a time horizon
  
  It's so important for a development team to understand the general direction of what they are working on. That direction is outlined in the higher level project documentation, which comes from outside the team (with input from the architect, senior whatever, or someone else with a good idea of what is possible).
  
• Change Management
  
  • Whether the policy is to control, embrace, or prevent change, it's coming. Get used to it.
    
  • The team (and better yet, the process) needs to have clearly stated what happens when a change needs to be accomodated.
    
  • When badly done, it affects team morale, no matter how good the team really is, and exacerbates the communications problems in general.
    
  
  

Now I know this sounds like a tirade on development processes and stuff (and I know many readers are thinking "I am not going to work like a civil servant"), the point is that a certain amount of process can bring certainty into a team. What takes certainty away is lack of communications - management overreacts to lack of visibility, with astounding detrimental effect ;-)