Finding individuals that are technologically competent is hard enough.  Finding technologically competent individuals that play well on a team is even more difficult.  Following is a list of items to help with the dynamics of working on a team.
NOTE: Use of the word "role" to mean the person, or persons, assigned to different aspects of a project - architecture, development, Q-A/testing, requirements, documentation, etc...  I haven't touched on everything about good teamwork, but the things I mention must be done for a team to be successful.

1.  Love and enjoy what you do.  Care about your work.

2.  Don't work in a "walled" culture.  Don't think of each role as working on a separate, unique piece of a puzzle, but rather of each role as working on a different aspect of a single picture.  Everyone is responsible for working towards a common goal - the big picture.  Don't work in isolation.  You don't have to be an expert, or involved in the daily details of every aspect of the project, but you should understand how all the different aspects fit together to form the big picture.

3.  Software is nothing more than intellectual property.  Use your intellect.  Think about your work and how it fits into the big picture.  Understand the impact your work has on other aspects, and how other aspects impact your work.  Always look for small ways to improve.  Contribute your ideas to the team.

4.  In it's simplest form, a process is just using repeatable patterns that produce a desired outcome.  Once you can examine things at this level, you can start to see how patterns from different aspects relate to each other, and what they share in common.  Look for ways to meld the similar pattern pieces together to reduce duplicative effort.

5.  Maintain a single, authoritative source for each piece of knowledge.  Develop tools to push the knowledge from one aspect of the project to other aspects of the project.   Anytime 2 or more pieces of knowledge have to be manually synchronized to stay current, and up to date, something is being done wrong, and needs to addressed.

6.  Make it easy for the next guy.  Don't just throw your work over the wall and assume the next guy knows what to do with it.  If you have to write up a series of steps to explain to someone else how to install or use your work, stop and think of ways to automate those steps.  Use scripts and .bat/.sh files to help automate these steps, as well as other common tasks.  If your work spans multiple files, package them together in a zip file.  Include a readme.txt file in the package to explain how to use it.  Remember, if you stop working on something for a month, then come back to it, you are the next guy - make it easy on yourself!

7.  Every aspect of the project will change.  This is not a perfect world, and it is very rare to get anything right the first time.  Plan for change.  Every aspect should be iteratively developed.  Clean up and refactor your work regularly as you go.

8.  It takes time to develop good habits, just like it takes time to develop bad ones.  Practice taking small steps towards forming good habits.  Don't try to do to much at once.

References:
“The Mythical Man Month” - F. Brooks (1974)
“The Pragmatic Programmer” – A. Hunt & D. Thomas (2000)
"Dynamics Of Software Development" - J. McCarthy & M. McCarthy (2006)


Comments and questions can be sent to: