Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

Building a Better Development Team? 60

Posted by Cliff from the teaching-old-packdogs-new-tricks dept.
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?"
This discussion has been archived. No new comments can be posted.

Building a Better Development Team? More

Building a Better Development Team?

Comments Filter:

  • team effectiveness (Score:5, Funny)

    by sribe ( 304414 ) on Tuesday April 15, 2003 @08:48PM (#5740997)
    Hire people with strong critical thinking skills ;-)
    • Actually this is tagged funny but it is largely true. Supercharged teams are the stuff of legend and the subject of intense study and invariably they are composed of individuals several cuts above the average. When you have the right team members and it gels - look out. You won't need navalgazing sessions for it to happen. For developers this could mean a massive explosion of quality code beyond what could be generated by a group 3x the size. The trick isn't necessarily in "fostering" those teams as mu
    • Here is just a thought - you want SuperHuman Performance and Award Winning Output ... so does the United States Olympic 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 (th
  • .. to do that.. team building is usually pretty easy. The problem is that you need to already have the people up to their technical speed from the start.

    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.

    • Along this line, split the team up in two halfs (at random): have each challenge the other with some technical problem, where they have to ask debugging questions which are 'simulated' by the challenging team (if I do this, what happens). Certainly, the stronger thinkers in the group will dominate, but the point is to show how strong thinkers think strongly, isn't it?

  • Teambuilding (Score:2, Insightful)

    by sunryder ( 192810 )
    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 friends

    • Re:Teambuilding (Score:4, Funny)

      by Kris_J ( 10111 ) on Tuesday April 15, 2003 @10:38PM (#5741608) Homepage Journal
      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.
      YUCK!

      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.

      • You're totally mis-interpreting what I said.

        The point I am trying to make is that IMHO, it is more important to build friendship first. Being a friend in the sense that I meant it means knowing a little about them and, as I said, being "comfortable approaching them" with issues. I think that building a basic understanding of the people you work with will enable better communication with them. And I think that communication is more important than trust in terms of teamwork.

        I said I "do not always trust the
        • No doubt it's not as bad for you as I've made out, but there are some nasty traps if you prefer friends over trusted cow-orkers. See how long someone stays friends with you when you have to tell them they're doing a bad job. The manager that can't fire an incompetent friend is not a good manager. See what happens in an organisation that is run assuming everyone is friends with everyone else when two people hate each other. Moreover, witness how inflexible and slow to react a company is when everyone thi

    • Re:Teambuilding (Score:4, Insightful)

      by Twylite ( 234238 ) <[twylite] [at] [crypt.co.za]> on Wednesday April 16, 2003 @02:34AM (#5742349) Homepage

      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.

      • A virtual +1 Insightful, since I have no mod points today. ;)

        I've been through a couple of team-building processes. Both failed miserably, imho because they concentrated on New Age-ish "bonding" exercises while failing to address the unprofessionalism and interpersonal issues rampant in both groups at the time.

        Other than this, I have nothing to add. Good post.

  • Feature Driven Development (Score:4, Informative)

    by aaronli ( 665755 ) on Tuesday April 15, 2003 @09:26PM (#5741223) Homepage
    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.
    • 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.

      The company I work for does something like this. Once a month, one of the developers gives a little mini-class on a topic of interest... we call it TechShare, and I think it's a cool way to get people on the same page regarding technical stuff.

      We also have a monthly "technical staff meeting", where all the developers get together in a
  • 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 man

  • Some suggestions (Score:5, Interesting)

    by Alpha27 ( 211269 ) on Tuesday April 15, 2003 @10:00PM (#5741399)
    The main thing is to ensure everyone knows the following:
    • all individuals know the overview of the product, timeframes, and who is doing what in a general sense.
    • project managers have a good ear (figuratively speaking) and a knowledge for the technology, since that will be your point person with everyone. I think it's imperative to have a tech person with many years of experience as the PM since they have been in the programmer role and have a very good understanding of what's going on. If this person can get to know more than just what the thing does, such as howit works, then that person can help to identify any potential problems that might arise in other development areas.
    • code review, alot of people agree with it, but very few do it. "code review takes time" well fixing bugs or seeing wacky coding takes time as well, and if you get it right the first time and not rush it, then you should be ahead of the game. this can also be done with extreme programming with paired workers
    • have a road map available at all times. I've seen places with no clear map written down, and just general stuff floating around. I'm at least seeing user storys used, but those user stories should be feed into a larger document that details the project in all
    • have a list of everyone's skill sets available, making it easier to identify someone who might be familiar with a particular library, or personal experience

    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.
      • Let developers know what they are building BEFORE they start building it.

        But only if you want to end up with a program that is already out of date.

        (If you specify a program and it takes six months to write, then you end up with a program that's doing what you wanted six months ago. But instead if you specify it while it's being written, and release it often, and allow change (and plan for change, and dare I say embrace change [c2.com]), then you'll end up with a program that does what you want today.)

        • Re:Excellent post but I have one more... (Score:4, Informative)

          by Alpha27 ( 211269 ) on Wednesday April 16, 2003 @11:07AM (#5744263)

          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.

    • I agree totally with what you said - and learnt this the semi-hard way.

      There was a coding competition held by barclays (uk bank - europe too?) - I passed the first round, and so did 2 others.

      We went down to london for the coding competition, and had a series of 5 coding problems. I assumed that everyone had the same strengths and weakness that I have. I went first, coded up my solution to the problem, and then the next guy took over the computer and coded up the solution for the next problem.
      So 2 of us
  • Are you saying that "team building" exercises are only useful for building teams of people, but don't actually help give them any useful skills for performing their jobs? Well, you could knock me over with a feather.

    How about identifying technical training needs of specific individuals and funding some decent training?

    • But how about then, when people have sufficient technical skills but are lacking social skills? I like to work on team where people talk to each other and have fun even at work. I doesn't matter if someone screwes up couple hundred lines of code but it does matter if someone is acting like jerk. Well, maybe this is a little exxagrated example but anyway. When people are comfortable with each others at work they tend to work faster which is strange because they usually chat more at the same time. I don't
      • As long as they know how to properly comment code, I'd rather have socially inept programming gurus writing software than, say, the marketing department.

        Programming is still part (black?) art. Portions of the skill set needed to properly write code are mutually exclusive with some accepted western social norms. Computers can't be bullied, bargained with, convinced or bluffed. A good programmer needs to be able to tell his or her boss that what they're asking for is impossible when it is. I don't think I

  • Book: Working With Emotional Intelligence (Score:4, Informative)

    by shunnicutt ( 561059 ) on Tuesday April 15, 2003 @11:03PM (#5741734)
    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.
    • erm, sorry, but that emotional Intelligence stuff is mostly bullshit, especially Goleman. He continuously misrepresents facts and his selection of empirical studies is highly biased. Fact is, in almost all cases people who do well at their job are satifisfied and happy, not the other way round. It's charming to believe it might be the other way round, to believe, that e.g. exam anxiety/worry is something that keeps people from getting good grades, but in fact, the anxiety is mostly caused by incompetence. A

  • You might try De Bono (Score:4, Interesting)

    by WolfWithoutAClause ( 162946 ) on Tuesday April 15, 2003 @11:36PM (#5741842) Homepage
    Edward De Bono ran a course for developing critical thinking. He also came up with a hat system; the idea is you put on a particular sort of hat and try to think in a particular way- today, I'm wearing my creative hat, or a what can go wrong hat or whatever.

    You could try running one of those courses I guess.

  • Puzzle Day (Score:4, Interesting)

    by cookd ( 72933 ) <douglascook@NOSpam.juno.com> on Wednesday April 16, 2003 @12:10AM (#5741927) Journal
    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...

  • Look at teamroles (belbin) (Score:5, Informative)

    by Reinout ( 4282 ) <{gro.seernav} {ta} {tuonier}> on Wednesday April 16, 2003 @04:47AM (#5742616) Homepage
    You should spend half a day on Belbins teamroles [google.com] with your team. Probably you can say to your personel department that you want to do a belbin course with your team, they'll hapily hire someone for a day to guide you through it.

    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.

    • Every role contributes something to the team process
    • If a role isn't filled in the team, it creates certain problems (some are bearable, some disastrous)
    • A role can go awry and will exhibit known irritating behaviour.


    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
  • 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.
    • Take this one step farther, get the team together (everybody at the team level, no managers or adult supervision) and get a few drinks in them. Lead them to a random car parked in a nearby parking lot (note : they don't have to know this, but you can go buy a junker for a couple hundred bucks specifically for this purpose) and commence with vandalizing this car in a big way : everybody participates.

      When the cops come, run like scared schoolgirls. As the owner of the car you can choose not to press charge

  • Effective Communications (Score:4, Insightful)

    by hol ( 89786 ) on Wednesday April 16, 2003 @08:23AM (#5743242) Homepage Journal
    While having a solid development team (in terms of people that know and trust each other) is important, nothing, at least in my experience, derails a team faster than poor communications. Not just internal (which one would assume is good given the team is "built"), but external communications as well.

    The foundations of this:
    • Clear expecations:
      • Expectations management
      • Captured (i.e. written) expectations
      • Checkpointing those expectations
      • Prioritizing the expectations - some are more important than others

    • Bi-directional, effective communications to and from the team
      • Status reports, both individual and summary
      • Short meetings, with agendas, and action items at the end
      • Avoiding unneccessary people at meetings

    • As far as possible a time horizon

      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).
    • Change Management
      • Whether the policy is to control, embrace, or prevent change, it's coming. Get used to it.
      • The team (and better yet, the process) needs to have clearly stated what happens when a change needs to be accomodated.
      • When badly done, it affects team morale, no matter how good the team really is, and exacerbates the communications problems in general.



    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 ;-)

  • Fred (Score:2)

    by sohp ( 22984 )
    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 [hairofthedog.com]
  • Pair programming [c2.com] is a great way to transfer knowledge (and perhaps skills) between two people.

    If you pair promiscuously [c2.com] (i.e., change pairs many times a day) you'll transfer knowledge between many people.

  • Sorry for posting w/o reading all the replies yet. I don't think this has been covered.

    I think Extreme Programming [extremeprogramming.org] 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 ro
  • 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. :^) )
  • 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
  • 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...

  • 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.

Slashdot Top Deals

To be is to program.

Close