views:

158

answers:

5

I work in a bank, and the boss now want's that we, the programming team, work on rotating shifts. He wants that sometimes we work from 7am to 3pm, and sometimes on 11.30am to 7.30pm.

He says that we will be more productive working this way, because he has worked with teams just like that and he just knows that. Nobody of the team wants this change, but we don't know how to effectively reject this new rule. I was trying to find some empirical (or almost) evidence about how rotating shifts affects performance of programming teams, and I couldn't. I had read something about rotating shifts, but not exactly about the effect of this on programming teams.

Do you know any research about rotating shifts on programming teams? Did you have any experience with this kind of work?

EDIT: Other teams of the company, like the database administrators team, the help desk team, the communication team or the network administrators team are already working in rotating shifts, and they don't like this but they do it anyway. I think the boss want that we work on rotating shifts too because of them, but since only we do programming I think the effects of rotating shifts could be, at least, different for us.

+4  A: 

Changing my sleeping habits never helps with productivity with me. (esp. waking up early)

John Boker
+3  A: 

Doesn't this make it MUCH harder to schedule meetings and discuss problems together?

It also hurts morale by forcing some people to work very unfavorable hours. Those people are not going to be particularly happy or helpful "team players."

BobMcGee
I suspect the alternative isn't "everyone works 9-5;" if you don't have shift rotations, then some people are going to wind up working the off hours regularly.
Jimmy
True, but this FORCES people to work off hours who very much may not want or need to.
BobMcGee
+5  A: 

Changing things for the sake of changing things doesn't sound like a good idea in any organization. Also, shift work was shown to induce metabolic syndrome (a collection of factors that increases your risk for many negative conditions, like diabetes, cancer, and heart attacks) in an important study last year.

John Feminella
A: 

It seems a bit silly to institute a rotating shift schedule for this type of work, given that the schedules are still within a 12hr period. I understand the manager's need to provide some level of support during those hours that the bank is open. But as the previous answers stated, rotating an entire team seems like changing for the sake of change (some people don't react well to changing schedules), and will be cumbersome for communication. For your scenario, you may want to institute some sort of "dev of the day" or "dev of the week" type of thing. This would be a rotating schedule for a small set of people (1 or maybe 2 depending on the work load) acting in a support capacity in the latter shift (or earlier shift if your dev team hates coming in early, as most devs do :) ).

nithins
+1  A: 

I work as a Tester Engineer (basically QA) at the company that I work for. We were started on a 2-shift system about 6 months ago. The reason that we were started onto this system, was because we needed to cover a large portion of system tests before our unrealistic deadline/release date.

Because my team was working so quickly through our testing, we started to get ahead of the software team in documenting defects. SO, the software team also started working in limited shifts.

From what I've seen, it looks like our product has gotten more and more defects than before.

Working the shifts is difficult, and rotating them even more so. Our solution was to have a 2 hour overlap in case we needed to communicate with people on opposite shifts. That 2 hour time usually starts on time, but people on first shift commonly find themselves staying 2-3 hours later than their official "off time".

If other departments are doing it, then you won't have this problem, but what we had a big issue with was the fact that sometimes we'd find an issue outside of the 9-5 time, and had no support from other teams to debug/fix the issue. This meant either documenting what we could and restarting the whole system, or if we couldn't do that, wait until the next 9-5 period came around so that we could get the system looked at.

In my opinion, it may seem like you'll save a lot of time by working more hours of the day, but ultimately I feel that you will lose a lot of time by working out the problems of not having everyone on the same page and making up for that.

Sakamoto Kazuma