Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite
1

The software engineering team of which I am part of is approximately 7 strong located in adjacent cubicles. 3 of us work on the same project but the rest are working on their own on different projects. In some cases one guy will be on his own on a project for nearly 1-2 yrs. There is no overlap in the projects that are being done as well. Currently I am one of those 3 guys working in the same project. So I have people to talk and discuss the problems and also to do some peer programming and reviewing. But everybody in the team have also been on a project just by themselves for about 2 yrs. It gives a very aloof feeling as you get further along the project. I was wondering if any of you guys were part of such a team and what did you guys do to have a healthy team spirit. Any thoughts/ideas are welcome. Thanks for your time.

Cheers.

share|improve this question
2  
Have beers every Friday :) – Demian Brecht May 19 '11 at 20:41
1  
Play videogames together every Thursday evening on a large projection screen. – Bernard May 19 '11 at 20:43
2  
@Bernard: With beers of course ;) – Demian Brecht May 19 '11 at 20:56
@Demian Brecht: Of course! – Bernard May 20 '11 at 14:23
I would like to make this a community wiki. I don't have the powers to do it yet, so can someone please do it? Thank you. – yasouser May 23 '11 at 15:23

4 Answers

up vote 6 down vote accepted

Don't let that situation arise

I realise that seems like a glib statement, but it's not. It is very important for a team to collaborate on every project. Break those 2 year projects down into much smaller tasks - preferably less than a week - and get everyone to work on them and everyone to review each other's code.

Yes, there is a cost to this. One developer, focussed on one project will produce more quickly in the short term.

But the benefits far outweigh that cost:

  • Never ending up with a developer leaving 1 year into a 2 year project with no time for true knowledge transfer
  • Better code through collaboration
  • Being more flexible with business priorities: if Project A needs to be out of the door, at the cost of Project B, you can do that easily
  • Opening up the possibility of daily standups, to avoid the situation where one developer gets stuck on a problem for a week

And, to bring it back specifically to your question:

  • Better team cohesion
  • A team feeling of success when a project gets released
share|improve this answer
Accepting this answer mainly because of this tip: "Break those 2 year projects down into much smaller tasks - preferably less than a week - and get everyone to work on them and everyone to review each other's code". This is doable in the near future. Having team beer and team lunch are great but I personally feel that is of no use if one cannot help out a team-mate when he/she is having some time critical programming/software (aka work) problems to deal with. – yasouser May 23 '11 at 15:20
up vote 5 down vote

I would highly suggest team lunch, or team dinner, or team beer.

Another option is to cross pollinate, using people not on your project to do QA (especially code reviews) on your project. This has the benefit of getting fresh eyes on your code and making the whole team familiar with it for later maintenance.

share|improve this answer
@Ross: The idea of using fresh eyes to do code reviews is slightly harder in our case mainly because of the type of development that happens here. One guy might be developing firmware for a specialty sensor and one guy on controls algorithm and few on display software (which include application software too). So to review the code that does the controls algorithm needs to know the subject matter otherwise I think its pointless. – yasouser May 23 '11 at 15:08
up vote 1 down vote

Have a "show & tell" sort of meeting once a month or so. More frequently is even better, but once a month is a good start.

Make it casual. I'm assuming of course you and everyone else are eager to share what you've been doing.

share|improve this answer
Good if the team supports it, but generally, wouldn't there be detractors? – tylermac Jun 14 '11 at 19:44
@tylermac - I think there will be detractors. It's okay, just have the subset of people who are interested to actually attend. I imagine it's better to have a fraction of the team know what some other fraction is doing, than no one knowing anything. Also, if no one wants to share what they do, it looks like the OP would want to. In that case, the OP would share the new stuff with everyone else interested. If there's 0 interest from presenters and attendees, the team has bigger problems. – Julio Jun 14 '11 at 23:51
up vote 0 down vote

Try to organize a presentation where the separate developers can demonstrate what they have been working on to the rest of the company. This will give each of you an insight into what the others have been working on.

This can be done maybe once a quarter or once a year, depending on how often you think you'd be able to provide presentable material.

share|improve this answer
We do have a weekly team meeting with our software team manager to catch up on what each one of us is working on. – yasouser May 19 '11 at 21:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.