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 ;-)

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.

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."

=)

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

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 ;-)

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.