we work on a team where there are alot of distractions, production support issues, users questions, lots of simultaneous projects, etc.. any thoughts on best practices on getting the development team to avoid context switching . .
+7
A:
Depends on if the context switch is generated internally by the team, or externally.
Internal: try and schedule things like "meeting free zones", so people can focus on their individual tasks. Discourage them interrupting each other during this time.
External: It's hard to control people from outside the team. You could try things like
- Have designated 'first contact' people on the team, to try and buffer others. Rotate this role to share the 'fun'.
- Try and educate people from outside the team (politely of course). A hard sell, but unless you tell others of your problem, nothing will change.
Kevin Haines
2009-01-09 04:52:56
Most interruptions generally come from sale and support people who's job generally is to spend half the day talking to people. To convince them that a minute here and there interrupting developers can end up costing hours in lost productivity is a hard sell.
Craig
2009-01-09 04:59:02
+3
A:
Why are developers being bothered with user questions? You really should have some sort of proxy, ala Office Space ("I talk to the customers so the engineers don't have to ..."). As far as too many simultaneous projects, that's not necessarily a bad thing. If it is causing problems them postpone certain projects. It's better to actually get 2/5 projects complete than have 5/5 or 4/5 go in limbo. Of course, if there is any micromanaging going on, that should probably be stopped. From the very limited information you've given, I think at the very least you need developer support personnel.
BobbyShaftoe
2009-01-09 04:53:13
+2
A:
Are you using an issue tracking system?
If you can funnel those different demands through a single system, at least the developer (or their manager) can prioritise (focus on) work as well as workload.
Takes discipline, but it can act as a nice proxy when the need arises :)
Si
2009-01-09 05:01:43
+2
A:
Number 1 tip for avoiding context switches. Batch the email system so that it only delivers every hour. The amount of time lost by continuously checking and/or answering emails is substantial. And don't run an instant messaging client.
Or, if you can't control the email system, spend an hour processing your emails in the morning then shut down your email client for the rest of the day. People can wait (or they can bug you on the phone, but I usually screen those :-).
paxdiablo
2009-01-09 05:11:19
+1
A:
It got so bad at one place I worked we used to take the development team offsite when we kicked off a project. It was the only way to get the whole team together for a whole day. We'd find a hotel which had good meeting rooms.
We even took a small dev team offsite for a month to work out of a conference room at a hotel. The Marriot hotel was nice they had free and beer and wine every evening. Made for a fun break before getting back to the grind. These were extreme measures but they were succesful, and lead to the team becoming a little bit closer.
As for my time, when I was a project I'd literally have a line of people outside my cube. My Manager who sat near me, made the suggestion that I start posting office hours when people could come and bother me. So that's another option.
A final thing is to setup a buffer, by directing communication from outside teams via a central person. All support issues could go to person X. And you could also rotate that person around. This way the communication channels are still up but only one person is being distracted.
JoshBerke
2009-01-09 05:28:51
+1
A:
Ok, since you are using an analogy with context switching, let me answer in the same light. If your teams was a Computer, how would you avoid context switches?
A. Buy more cores = Get more team members
B. Offload tasks to other nodes = Offload non-programming tasks to other departments
C. Reduce the workload = Reduce the workload
Robert Gould
2009-01-09 05:35:41
+1
A:
I have had this problem and it can be solved in a number of ways. First depending on the number of developers on your team you could split up the developers into smaller focused teams and have developers rotate in and out of those teams on a schedule. For example you might have a production support / triage team that focuses on production support and hot fixes for production and you may have a product team that focuses on the product road map.
Some things I try personally to cut down on distractions are to:
- Block out time on my calendar for coding (So I will not get pulled into unnecessary meetings)
- Sometimes I will work from home if I need to focus and get work done
- I will physically move to a different location and remote desktop into my workstation
As far as user questions are concerned I would have users submit questions to a queue and that queue would get prioritized along with all of the other work. It sounds like you might benefit from smaller focused teams.
Michael Mann
2009-01-09 05:37:08
+1
A:
A couple of suggestions - all dependent on how your team is setup.
- blackout period - email and IM are turned off for 2-4 hours per day
- designated support person - instead of having your entire team on production support standby, have a rotating schedule of who handles production support issues
- aliases - have your group create public and private email/im names - so they can turn their public ones off as needed
- don't over load your group - keep them focused on the high priority items - don't even discuss low priority projects with them (blinders)
meade
2009-01-09 20:05:12