I'm in an environment where a new project is being discussed where a couple of members from the Core dev team will be asked to leave the core work and start this project.<p>I feel that it's not good to have the other existing core devs to not be part of this new project that will be replacing the system that they will ultimately be maintaining. Those members are eager and passionate to contribute to innovation and I feel not allowing that is harmful.<p>I recently read this article about how Facebook had their core team working in parallel on an innovative project.
https://hbr.org/2015/06/an-inside-look-at-facebooks-approach-to-automation-and-human-work<p>I'm wondering how to do something like this on a tactical level, especially in an agile scrum shop?
Rewriting is (almost) always a bad idea. (and you're planning some kind of a rewrite, since the new system will replace the old one)<p>Let's assume that Team A will work on the newer version, while Team B will continue to work on the old version.<p>Team A will start working and implementing stuff. Team B will keep working on the old project and add new features. Team A will need to keep up and add new features that Team B added, and so on.<p>> Those members are eager and passionate to contribute
ANYONE is eager to contribute to a brand-new project!<p>--------<p>How I'd do it?<p>1) Incremental changes on existing product. Unless you're using some ancient programming language and you have troubles on finding programmers (or you have some licensing options, or the product is locked on a certain platform; e.g. is written in obj.C and you want it ported on Windows and/or Linux), probably this is the best approach. If the system is too big to add features at first, start improving existing code. Clean up. Add unit tests. Clean up even more and start adding features.<p>2) If you're set on rewriting and this is the only option to consider, feature-freeze the existing project and move all developers to the new project (every once in a while, pull a developer to fix critical bugs _only_). Don't pull the same developer twice in a row though and don't ask them to fix trivial stuff.<p>-------<p>Additional lecture (in no particular order):<p>- <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000069.html</a><p>- <a href="http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer" rel="nofollow">http://programmers.stackexchange.com/questions/6268/when-is-...</a><p>- <a href="http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx" rel="nofollow">http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Alm...</a><p>- <a href="https://www.lessannoyingcrm.com/blog/code_rewrite_cautionary_tale" rel="nofollow">https://www.lessannoyingcrm.com/blog/code_rewrite_cautionary...</a><p>- <a href="http://programmers.stackexchange.com/questions/6255/have-you-ever-been-involved-in-a-big-rewrite" rel="nofollow">http://programmers.stackexchange.com/questions/6255/have-you...</a>