Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Having two teams is a mistake right from the start. </p> <p>I have seen this (two distinct teams) at other companies and it always amazed me that this was actually done in the real world. </p> <p>I suggest only one team of developers - and some are tasked with support, and some are doing new development - but there is no clear delineation.</p> <p>For one, there is no natural feedback loop (positive or negative) for the developers of new code to actually make it maintainable. They just toss it over the wall for the maintainers to deal with.</p> <p>I have also seen it create division, rather than cohesiveness. I don't see anything positive/good about the scenario, whereas I see a single product team having many benefits. </p> <p>I can't understand it.</p> <p>I agree with others - either rotate through, or make ONE team.</p> <p>EDIT:</p> <p>So, for those without the ability to rotate through teams, or make one team:</p> <ul> <li>There must be visibility on both sides into the issues that arise. That is, the feedback from production must get to the development teams. </li> <li>As you suggest, involve production team in the initial design and planning and requirements gathering phases.</li> <li>Teams must be able to have easy access to each other</li> </ul> <p>EDIT:</p> <p>I did work at one company that had a small team that was on loan from the rest of the dev team - they called it the "swat" team. They would build specific functionality for some large clients or for a fee and the code would be put on a specific branch. While similar, they really still came out of the pool of all developers. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload