Our company is developing 2 generations of a product in parallel. Our product cycle is about 2-3 years. Today we're working on:

  • generation N "production": next product to be released, getting things into the market, new features, fixing bug
  • generation N+1 "research": concept work, studies, prototypes, research, requirements analysis

We're follow the Scrum methodology (roles, backlog, sprints, ...) in our team where possible, but the transition is still in progress. Especially: the rest of the company is (still) following a waterfall approach. The focus of our management is mostly on generation N.

Our company so far tried the following project structures, but all have severe drawbacks:


(+) = good

(‒) = bad

  • Two separate teams for production (generation N) and research (generation N+1):

    • (+) good progress in the research for generation N+1
    • (+) Production team can focus on generation N.
    • (‒) The research team has the more interesting job, the production job is not so popular.
    • (‒) Knowledge loss when transferring a project from research to production.
    • (‒) The research team never experiences the problems of the production team and vice versa. Especially the research team does not investigate all of the relevant aspects.
  • One team for both generations:

    • (+) Good knowledge sharing between generations.
    • (+) No handover required.
    • (‒) N+1 does not get the attention it deserves as the management focus in on N.
    • (‒) So there are not many innovations in generation N+1 as we did not have time for it.
  • Have only one team but dedicate 2 (or 3) "researchers" to focus on generation N+1:

    • (+) Good knowledge sharing between generations.
    • (+) No handover required.
    • (‒) In the beginning: Inefficient meetings (daily, sprint planning) as the two sub teams work on different topics.
    • (‒) In the end: The research progress is slow, as the researchers get pulled into production problems.

How should we set up our projects in this environment?

2 Answers 2


You could go with the two team approach and reduce the negative impacts by:

  • allowing developers to work in both teams when it makes sense to swap the team resources around
  • documenting and presenting research work to developers in the production team to allow them to raise any concerns or highlight things that the research team are not aware of, maybe put regular presentations in place e.g. every Friday afternoon or inviting production team members to research sprint demos at the end of every sprint

Another approach would be to have one team and ask the management to appoint a product owner to create one prioritised backlog across both streams of work. The team shouldn't be doing work that is not valuable to the business. The product owner should prioritise on the basis of business value so, how valuable is each feature to the business (whether that's research or production).

Yes this might mean that the production work is more valuable so is prioritised higher; but if the prioritisation is done on business value, and research for N+1 ensures the company stays competitive in the market, then research work may get prioritised above some of the production features.


Maintain the same team but different branches in your SCM. Your generation N product will generally be more stable so you should get (cherrypick) the stable code or any relevant improvements from branch N to N+1.

Have the same developers who worked on feature X in product N work on the same feature in product N+1. That way they will be familiar with both the codebases and any code migration or code merge will be easier. Plus it will keep them happy as they get to work on both production grade as well as cutting edge technology. Just have the management focus on N+1 in addition to N.

Depending on the situation, you can switch developers from one product to another - say product N requires a critical patch then your team working on N+1 can take a week to work on N. Similarly suppose you have implemented a stable reporting framework in N and want a cutting edge reporting framework in N+1, have the same team port the changes from N to N+1 and also improve N+1 with newer tech. This way all the developers will work as a single team which is important because after all N and N+1 are the same product, and your products will be more coherent, and help you in the long term in customer migration, devops, etc.

footnote: Apple did mac and lisa at the same time during the 80s, driving a wedge between developers of the teams. You want synergy within the company, esp if its different iterations of the same product.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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