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 ;-)
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.
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."
=)
I'd much rather be able to trust someone to do their jobs than be friends with them. But I suppose that if none of you get anything right you all spend a lot of long days together. Me, I have actual friends outside of the company.
A company full of incompetent friends and an empty sack is worth the sack. Which is what some of your friends sound like they should get.
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.
I am far more interested in professional behaviour than friendship. Leave your emotions, personal problems, politics, ego and anything else I may not like about you and you may not like about me at home. I don't want to have the opportunity to dislike someone because of their interests, views or behaviour - it makes for trouble in the workplace. And this is a big danger in teambuilding, and why teambuilding often does not work well, especially in the tech community in which you find heros.
I consider myself Pretty Damn Good. That doesn't mean I'm above asking colleagues for help if I think they have experience with a particular problem and can help me solve it faster than I can alone. It also doesn't mean I look down on people who ask me. Being a professional means behaving in a manner which looks out for the interests of the job as well; so learning and teaching are all part of life.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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
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.