Slashdot Mirror
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?"
Hire people with strong critical thinking skills ;-)
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?"
;)
Hmmm...sounds like someone has been taking all those Dilbert cartoons seriously...
OK, jokes aside, sure you trust each other, but are you friends with one another? There is a very important distinction and I've found that friendship is far most important than trust. I don't always trust that my co-workers (and subordinates) will do things "correctly" or even their best. But for the most part they are also my friends and I feel comfortable approaching them if there is a problem or just some task to work on.
How about doing something friends might be more inclined to do rather than team building exercises? Go mountain biking, paint-balling, rock climbing or hiking together.
There are also things you can do at work. We play Frisbee, Starcraft, or just hang out at lunch. It's not only fun and relaxing, but it builds up the relationships between everyone.
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.
Roleplaying will do this well. Contrary to Hollywood's portrayal, it's not a game for those unable to cope with this reality. It's a game for people who like analytical challenges. Among it's many team building advantages, is the revealing, to a group of people, how each of them solves problems. It exposes weaknesses in people's analytical thinking, and allows people who don't have the "right" answers to sit back and watch how those who do came to them.
It doesn't have to be AD&D either. Among many other varieties, the Science Fiction role playing games are very appealing to geeks and don't have nearly the "I'm a disconsolate teenager" stereotype attached. Nothing says "That was a bad analysis," better than a decision that everybody "buys into," that consequently gets all their characters killed.
If your group of people can't be persuaded to go this route, then an alternate that I experienced was to get the team involved in a team member's hobby. In trying to trick out a friend's car with a Linux-based, head-up-displayed engine monitoring system, I learned to observed the things that stalled that project in my work projects all the faster. Now my planning phase for a new project involves more thorough research into hardware suitability, than it did previously. I learned this "the hard way," but on a project that didn't affect my income.
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."
=)
Let developers know what they are building BEFORE they start building it.
I've just finished this book, written by Daniel Goleman, and I heartily recommend it.
Its premise is that there are different emotional competencies, and that these competencies distinguish outstanding performers from the merely average. One of the points is that the technical skills required are merely the threshold -- you have to meet these requirements to get the job. How you manage yourself and your relationships with others is what makes your breaks you.
The studies mentioned indicate that the more technical the job -- the more rarified the subject matter -- the more these emotional competencies matter to job performance.
This isn't a self-help book. However, it does break these competencies down into several areas and discusses each one with research and anecdotes.
Most important, it has a chapter dedicated to what you should be looking for in training programs that purport to increase the emotional competency of the people being trained.
Seriously -- go to your public library and check it out. Just being aware of these factors gives you a different perspective on your day-to-day life.
You could try running one of those courses I guess.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I'm not sure what you're asking, but if you are trying to come up with a team activity that would help them think hard, my favorite is "Puzzle Day". I've done it a few times, and I come off of it with the biggest high and a new confidence in my abilities to solve tough problems, as well as a respect for the abilities of my friends & co-workers.
My teams were 10 to 15 people, but two teams of 5 or 6 would probably work. Come up with some fun but HARD problems. Hard means that 5 people working for 12 hours might solve 5 out of 10 problems. Try to have a theme.
Puzzles come in all shapes and sizes. Cryptogram word-search puzzles are one example: take a word search puzzle, then replace all A's with G's, B's with T's, etc.
The best puzzles are layered: After solving the word search, the uncircled letters make up the phrase "fear of the great mole rat", and the final answer to the puzzle is "Zemmiphobia". Then all of the answers to all of the puzzles come together to solve one final puzzle...
Maybe this isn't your cup o' tea, but I sure found it fun...
Time flies like an arrow. Fruit flies like a banana.
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.
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
Reinout van Rees
The foundations of this:
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).
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
- - - Non Caffeine Drink or Drink Error
Firstly you are better off hiring people who bring in problem solving and critical thinking skills.
Few tips on interviewing for these skills: Have typical questions in your interview where you ask for previous experiences where they demonstrated their problem solving ability. Give them hard questions and see how they approach them and/or solve them. Pose hyporthetical situations and see their response.
Even now you can selectively hire & fire to first get a proper team with the proper mix of skills and problem solving ability. Never be afraid to right-size.
Once the team is built to your satisfaction.
Have a strong problem solver in a leadership/decision making rols, so he can take on more challenges.
On developing problem solving skills:
1. Have brainstorming sessions to solve cri6tical problems where people are encouraged to speak out and mistakes are forgiven. People get encouraged to speak out in an open forum and good ideas emerge. follow the 7 hats way.
2. Have sessions where real and imaginary problems are posed and time limit given to solve them. Evaluate the results and encourage the top performers while not discouraging others.
3. Recognize and reward good problem solvers and make your ploicy known