@Amy – Yes, the Feathers book is definitely a favorite around here. We actually had all the developers in the company go through it using a book club format about a year ago. Trying to get some characterization tests around things is where we are starting.

@Michael – thanks for the good thoughts. We are a team of 5 developers (including myself – I also server as team lead/scrum master), 1 Project Owner, 1 Project manager, who helps out with analysis also, and 0 testers.

I personally haven’t been through a refactor/rewrite of that magnitude, so I can’t cover all of the angles. I’m afraid that the only thing I can suggest, is something that you probably already know–

Since you want business value as quickly as possible, and that value is something that is determined only by your clients, I think it would be advantageous to be aware of which changes to the system they will quickly and easily recognise and adore. For end-to-end systems, I’d say this is likely to be anything visual followed by anything improving perceived performance. I think expectations management is going to be key as the whole project seems very volatile.

Provided you choose to follow such a strategy, I’d be hesitant putting everyone on the chosen front of greatest initial impact, as you may lose reconnaissance on other ends of the system which could eventually chuck a monkey-wrench in your solution. Might depend on the size of your team? Perhaps I’d prioritise subsystem work order based on their value-add factor.

In general, I can imagine that it might be advantageous for the team to focus most of their energy on one part of the system at a time and move across the system linearly if possible, so you eliminate the problems that can come with meeting in the middle.

Hopefully some of this is helpful. Good luck!