Splitting development of new versions from on-going fixes of in-the-field versions?

Question

At $work, we've recently (as in three or four years ago now) split our development organisation in two (but not half): one group to develop the Next Big Thing (NBT), and the other group to handle customer-reported problems, diagnose them, and check in the fixes for the regularly-scheduled patches (development support, or DS). And the second group will then merge the changes into the NBT release as well.

Allegedly, this is to help the NBT team better plan the NBT - by having their developers not being distracted by customers, planning how much of their attention can be paid to the NBT product is theoretically easier. It also is supposed to help customers by having developers specialise in supporting customers.

What are your thoughts/experiences on such a split? Would you prefer this model? Would it cause you to look for further employment elsewhere? What are the pros and cons?

In my experience so far, I'm finding that:

• some people have quit (or, rather, forced their manager to lay them off) Others seem to prefer this (I'm not sure why)
• the NBT group is further removed from customers resulting in:
  • less understanding of what pain points customers really have
  • less understanding of where customers are getting confused by the interface (whether graphical or command-line or whatever)
  • less ability to respond to stupid requirements with customer-related retorts
• The DS group is responsible for passing on what is learned from the customer to the NBT group.
  • I don't know how you learn, but me and apparently most of our DS group seems to learn by experience better than by being told. So only a portion of the information will be retained relative to not having this split.
  • It's impossible to remember everything from a two-week customer engagement to report back to the NBT group anyway, but if DS and NBT were a single group, Stupid Requirements would trigger the memory. So stuff we could have learned is never used.
• The planning of the NBT is failing as too many Stupid Requirements have come in, and the NBT team has asked our DS team for extra help. The flexibility that this split has removed is still required.

As you might be able to guess, I'm trying to make a case for re-merging the teams. However, I do recognise that my perspective may be getting the better of me, so I'm open to the reverse discussion: how this is helpful to the development process, and, ultimately, the customer. If you have positive experiences, I really would like to hear them, too.

Answer 1

I'd have to agree that a strict segregation is probably a bad thing, for many of the reasons you've cited.

I have worked in organizations that separated the roles but not the team. Each developer, in rotation, would have some period of time on "customer support", usually at least one step removed from a help desk, but in a couple of situations taking calls from end users.

In a commercial situation, software product development, you probably don't want developers answering the phone or chatting with end users. You probably want the help desk in there.

None of the developers I've worked with ever looked forward to the time on customer support, but I think overall that we agreed it was better than splitting the group.

I do think it is a good idea to have developers present (but probably only as observers, if possible) at demonstrations, trade shows, or even accompanying field service (for larger products/organizations) to see how users really use the product.

It never ceases to amaze me how differently I approach the use of an application (as a developer) than the majority of users I watch use the same application.

Answer 2

We've found our best efficiency when we organize our engineers by area of technical expertise, rather than by role, and then share their skills across projects and tasks.

So rather than an R&D team and a maintenance team, we allocate individuals according to the skills required for each endeavor. We try to cross-train so everyone becomes self-sufficient, but we know which "expert(s)" we can call on when we need help or advice.

We've also found that making the developers responsible for maintaining their own projects provides incentive to keep the amount of rework to a minimum. :-)

On the other hand, since we're a small organization, we lose momentum on new development when forest fires erupt.

Answer 3

In my current position we have exactly what you describe here.

We have Software Development team, who work on the most up to date version of the software, using fully specced out Customer requirements documents to design the newest features to be added to the system.

We also have Software Production team, who take issues from the helpdesk and resolve them, using either changes to the code, added in through service packs at customer defined intervals, or if the problem is a simple fix that does not require coding we simple write up the resolution document to pass back to the helpdesk who pass it to the customer.

Both teams work in the same cubicled office so we can interact if we need to pick someones brains on the opposite team.

During the interview process for a software position both positions are described to the candidates and they then decide which team they would like to be in. If someone finds that they aren't really suited for the team they are in, they can apply to move to the other team, and will be moved if there is a current need in the other team or someone else wants to move the same way.

For us, this seems to be a very workable solution as we have developers working always on the NBT, but the most important aspect (keeping the customers happy) is always covered.