[Ryan Marfone]

Has anyone had experience working on a dev team that simultaneously worked on projects as well as supported customer requests? If so, how did your team manage this? Did you split your team in half (half to support, half to development)?

[PsychoCoder]

I worked for a place that did this, the way we handled it is one developer was tasked for help desk tickets for the week, we then rotated through all the developers on a continuous basis. Worked pretty good for us, but when my week came around it sucked lol.

Moving this to the Corner Cubical forum for better discussion

[Ryan Marfone]

PsychoCoder, on 23 Feb, 2009 - 09:07 AM, said:

I worked for a place that did this, the way we handled it is one developer was tasked for help desk tickets for the week, we then rotated through all the developers on a continuous basis. Worked pretty good for us, but when my week came around it sucked lol.

Moving this to the Corner Cubical forum for better discussion

We tried this approach before as well. One problem with this method is that the developer who is on support roation that week doesn't necessarily always have the skillset to support all types of issues. At that point they would need to pull another resource from developing which kinda brings you back to square one. I am curious as to what other options are out there. I am convinced that this model doesn't provide the best business value.

This post has been edited by Ryan Marfone: 23 February 2009 - 11:18 AM

[markhazlett9]

Won't that create a large amount of catch up time for developers coming back to projects after having say the "week off" to do customer support?

[NickDMax]

Well I have only dealt with small teams but we tend to work as a team to meet all goals. We have a plan for development and when support issues come up we generally decide which 1 or 2 people should really take a look at that... if there are coding issue a more senior person may do the analysis and then report back and a more junior person does the fix.

So far this has worked well for me -- but I don't really have enough people or time to really break people off 100% for a week. Generally in a week I tend to do about 80-20 split (I guess as team lead it is probably more 70-20-10 since I also spend a good bit of time administrating this process).

[PsychoCoder]

Ryan Marfone, on 23 Feb, 2009 - 09:17 AM, said:

We tried this approach before as well. One problem with this method is that the developer who is on support roation that week doesn't necessarily always have the skillset to support all types of issues.

We used this approach as a cross training technique as well. We had so many different applications so this way a way for every developer to learn the ins and outs of each application/system we had. Each application had what was called a POC (Point Of Contact) for the person on rotation that week.

I do agree that is does have it's downsides, but that was the model my employer chose to go with (have to do something when you have over 500 in house users and upwards to 250,000 outside users)

Quote

Won't that create a large amount of catch up time for developers coming back to projects after having say the "week off" to do customer support?

Not really since the developer on rotation wasn't tasked with any programming tasks for that week.

Like I said, it had it downfalls, but it was really good for cross training on all the applications we had

[Ryan Marfone]

markhazlett9, on 23 Feb, 2009 - 10:24 AM, said:

Won't that create a large amount of catch up time for developers coming back to projects after having say the "week off" to do customer support?

I guess it's a case by case scenario. It all depends on the nature of your business/projects.

[BenignDesign]

We don't have dev teams. It's every man (or woman) for themselves. Design, development and support... we do it all and we do it solo. Kinda sucks, to be honest.

[Ryan Marfone]

BenignDesign, on 23 Feb, 2009 - 01:13 PM, said:

We don't have dev teams. It's every man (or woman) for themselves. Design, development and support... we do it all and we do it solo. Kinda sucks, to be honest.

I agree. My team was structured like this for many years. Very little knowledge transfer occurs in this type of environment.

[xerxes333]

BenignDesign, on 23 Feb, 2009 - 03:13 PM, said:

We don't have dev teams. It's every man (or woman) for themselves. Design, development and support... we do it all and we do it solo. Kinda sucks, to be honest.

Same here, although we have one person who has the additional task of maintaining a running list of who is working on what or what certain individuals have developed in the past so if there is a support issue they know who to direct it to. Fortunately that person is not me.


Edit:spelling

This post has been edited by xerxes333: 23 February 2009 - 09:36 PM

[alaub]

Quote

We don't have dev teams. It's every man (or woman) for themselves. Design, development and support... we do it all and we do it solo. Kinda sucks, to be honest

I am working in a similar situation. 3 in the IT team. One is soley support, one system admin, and little me the person in the middle who has to do some of it all plus the Web Development and Crystal Report writing... oh yeah and don't forget to throw some GIS in with it all, makes for a very interesting job!! and alot of distractions from development!!

[Arenlor]

@OP Have you considered having each member support what they have worked on? In other words have one person each week as the interceptor, catching all the tickets and canning them if needed. Then they'd tag them for what part of the application it was (web front end, database backend, client side software, etc.) The person in charge of that piece would then handle all of the requests, which may alert them to bugs and feature request and also alert them if something is hard to work out. It'd make each person responsible for the support for their work.

[Ryan Marfone]

Arenlor, on 1 Mar, 2009 - 04:27 AM, said:

@OP Have you considered having each member support what they have worked on? In other words have one person each week as the interceptor, catching all the tickets and canning them if needed. Then they'd tag them for what part of the application it was (web front end, database backend, client side software, etc.) The person in charge of that piece would then handle all of the requests, which may alert them to bugs and feature request and also alert them if something is hard to work out. It'd make each person responsible for the support for their work.

From what I have seen, this is generally the most common approach with most internal dev teams. There are a few pros and cons to taking on this approach.

Pros: You generally get the best quality of customer service with this approach. There isn't usually a single person in the organization that can support your code better than YOU.

Cons: The problem I've seen with this approach is the lack of knowledge transfer between individuals on your team. If you are forced to support issues that are out of your scope then you are forced to learn how they work.

This probably doesn't apply to every scenario but it's generally what I've seen.

[Pwn]

This is similar in my dept, data processing. We have a daytime helpdesk, and they have resorted to forwarding all calls they don't know how to handle to us to handle. Unfortunately, word spreads that we take all calls, and now everybody is looking to us for answers, even PBX. That's hard for a 2 and 1/2 man team to do, especially when we have a lot of other things to do, like sysadm, setting up users, copying files, printing reports, AND fielding calls other than from the helpdesk. We even get calls from sys analysts, because they need help.

Tip of the day: don't be too helpful, it will overwhelm you.

[Ryan Marfone]

Pwn, on 15 Mar, 2009 - 09:04 AM, said:

Tip of the day: don't be too helpful, it will overwhelm you.

Agreed.