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 ;-)
You can try mental exercises with the group. Have them start with solving 'fake' problems. Make up scenerios and then how you would solve the problems. Not really knowing what your company does it is hard to say exactly how to do that.
Only 'flamers' flame!
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.
And how you can fix it!
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.
I've always liked the idea of, when about to start a new project, the whole team of programmers going over the structure of the program, etc, before anything is coded. Everyone gets an opportunity to input good ideas and feel a part of the project.
I also worked at a web dev company once where people who had certain skills would give little classes in-house about their expertise, to help pass on their wisdom to others.
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.
How about identifying technical training needs of specific individuals and funding some decent training?
would be to fire you.
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.
People who have great ideas hate teamwork because they hate to discuss their ideas, because they're already used to having great ideas. Teamwork is a serious innovation killer. Try to find the people which can *think* in *creative* ways and separate them from the team. They will honour you with great performances they would never have had archived in the ghetto.
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
Most importantly, drink it together. This doesn't work to get everyone together, but it will bring in a lot of them. Creating that bond outside of work will carry over to what you do at work.
Easy Online Role Playing Campaign Management
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
We've found the best way to get the team working as a well-oiled machine is to take a field trip to get know our dear friend Fred
If you pair promiscuously (i.e., change pairs many times a day) you'll transfer knowledge between many people.
That's insightfull, Moderators... you know what to do.
Sorry for posting w/o reading all the replies yet. I don't think this has been covered.
I think Extreme Programming was intended in part to address this.
Can't say as I've actually been in an environment that tried it/used it.
Short of that, I would try to get your team involved with more technical workshops, conferences, courses, etc. Staying on top of the research is important, too.
Of course, both of those things seem to be highly budget sensitive, but if you are already going on work-weekends to do ropes courses or something like that, maybe sending everyone to a big conference in your industry would be a good alternative.
A lot of replies to this post seem to be missing the question. The poster is saying that he/she already has a strong team in terms of trust, morale, etc. So, telling him/her to go drink beer with his buddies is not what he/she needs to hear.
:^) )
I think the poster is looking for help improving team technical skills, team problem-solving skills, etc.
(I must be feeling pretty PC today...all the he/she business.
You mean there are people who ASK to do teambuilding exercises???
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
the original source for that quote is Paul Ambroise Valéry.
I'm sure it was in Neil Gaiman's books (was that line spoken by the voice in the desert?), but I don't think that that was the original source.
Here is just a thought - you want SuperHuman Performance and Award Winning Output ... so does the United States Olympic Team.
... or end up on the wrong side of town and have some gangsters chase them around guns blasting ... or accidently participate in something that ends up on a Shane's World video ... now THAT would create the ultimate team that you are looking for ... those guys will be a veritable code SWAT team.
They have already determined that you can't take any random group of people and put them together under the moniker 'Team' and have a great coach or training methodology or awesome facilities turn them into winners.
They view the entire country as an applicant pool and go out, determine who is the BEST of the BEST and they 'hire them' onto the team. They make an attractive offer (the potential to represent the country in the Olympics,) have the name and reputation that attracts the best talent (USA Olympic Team,) give them excellent facilities and the training and tools they are going to need in order to succeed. Their work environment once hired is totally dedicated to working and not worrying about getting replaced by a bunch of H1-B gooks, outsourced to whatever country, or RIF'ed to make a quarterly profit number so Lumberg's stock will go up a quarter of a point.
Winning teams are not the result of team building exercises. Winning teams are the result of having a lot of winners and no lamers.
That said, forget synthetic team building exercises. You want geeks to work together, give them an hour a day (lunch perhaps) playing CounterStrike, Quake III Arena, Unreal Tournament (original and 2003) - use all the team maps (not free for all.) Take them out for a weekend to do PaintBall.
Also - give them a common adversary - nothing makes a group band together better than a common adversary.
Actually better than that : send the entire team to somewhere on 'official business' for a week, somewhere way away from the office and somewhere they can get in a LOT of trouble together. One car for every 4 or 5 people guarantees they stick together. You send your entire team to Vegas or better yet Ft Lauderdale during Spring Break and give them each $500 in discressionary spending cash you pretty much guarantee half of them are going to having sex with random strangers (or at least try, or at the very least spend a LOT of time in strip clubs) and at least one of them is going to get arrested. The more trouble they get into as a group while away from the office for a week, the better they will work together as a team for the rest of their lives. If they accidently kill a hooker in their hotel room and take the body out into the desert and bury it
Glonoinha the MebiByte Slayer
Seriously, try to foster a practice of taking the whole team out for an hour or two, a couple of nights a week to hang out together, and casually shoot the breeze. Social bonding outside of the office gets people a lot tighter than any amount of "Lucy, fall down; Dave, catch her" exercises. Hit the pub, shoot pool, and have a few beers together. Cops, soldiers, and firemen have been doing it for hundreds of years...
Farewell! It's been a fine buncha years!
These aren't neccessarily "critical thinking" development ideas. But are more technically oriented and less contrived than the fall-backwards-and-let-your-teammate-catch-you stuff that most engineers roll their eyes at.
1) Weekly technology "brown-bags" (they were during lunch). Generaly on some relevant technical topic but not neccessarily related to current development. Get it rolling by having the people who can speak and who the rest of the team respects get up and do a talk on something which they have knowledge of. Some examples: IP networking - explain address, netmask, routing - get as deep as people can absorb; RPC - what is all the plumbing that goes on between caller and callee - compare and contrast with local procedure calls; etc.
2) Book club. Pick a book on software development - not the "follow this formula" type and not a reference book, but one that is more of a discussion. Read a chapter a week and discuss with the team. This will likely need a moderator to get things going.
3) Semi-annual "how does our system work (again)" series of talks. Line up the people who know and/or have changed large things recently. This isn't a code review, but a presentation to the rest of the team. Its great for getting new people up to speed and keeping everyone abreast of changes.
We need to focus on better ways of identifying and solving technical problems and developing stronger critical thinking skills.
Maybe the people have enough critical thinking skills.
But when i think something is going wrong i dont tell. If i tell what the problem is people will say i think i know it better then the others and treat me as an impolite person. The people will eventually discover the problem themselves and then it will be solved.