What are some key concepts for effective development teams?

Question

Where I work we've recently put together what we call the Development Standards Committee which is tasked with improving our procedures, processes, methodologies, tools, standards, and whatever we think would help us become a more effective team.

We've got a spreadsheet of items that we've ranked and are going to start tackling from the top down. We've got things such as better source control (currently on SourceSafe), implement a bug tracker (such as Mantis of FogBugz), peer code review, move to .Net 3.5, possibly move to some form of Agile, do more actual team development rather than single developer per project type stuff, and some other things...

What do you think are some key things that can make or break a development team? What should we add to this list?

Some additional information: We have about 12 people on our windows team, and about fifty in development if you include all platforms. We want to improve as much as possible for everyone, but we're our biggest focus is the Windows team. All of us have been here for a couple of years at least, so most of us know each other and work together pretty well.

Answer 1

as better source control (currently on SourceSafe)

If this is Visual SourceSafe -- you need to change this immediately. Try cvs, svn or even something paid like Perforce.

There exists something called Rational Unified Process that deals with your problem (and much more).

Answer 2

Require comments when you check in code (it's great if you can tie commits back to your bug tracker)

Maybe Static Code analysis, like what's built into Visual Studio

Continuous Integration like CruiseControl

Answer 3

The number of people on your team is actually really important here. There are basic things that every team should implement (source code control, bug tracking, etc), but there are things that are different base don team size. Code reviews on a very small team, for instance, can be more informal.

Moving to Agile is a good idea, unless you're particular development environment makes it a bad idea. Also, you'll not be able to do this without support from the people who are using your software.

Consider doing things to ensure that communication between the team is easier and with less roadblocks - do all your members know each other pretty well? Can you work with each other? Do you understand each other's idiosyncracies? Learning to work as a team is much more important than any random process improvements you can make.

Answer 4

Development teams really need good people to start with, that work well together, but this isn't really an item to add to the list. It does however affect my first recommendation, be pragmatic. If you're not encouraging your developers to think about how they work and can drive them selves to improve, it's really hard to lay down a development environment that will do it for them.

Mentor and Training: If you can't do XP, then at least hook up your Juniors with Seniors whenever you can. Not only will you share knowledge but you'll share the context around your projects you own.

Answer 5

Some sort of Continous Integration and regular, tested, working "releases" make wonders for quality.