Release Now If You Can
Your question about when do you start releasing the code is a great one. I think that two provisos apply. First, that you have "good enough quality", and second that that you meet the requirements for an MVP (minimum viable product).
Rome (and Agile) Weren't Built in a Day
Maybe you are ready with a turnkey agile team to take over on day one. For most organizations, there is the work and expense of training, retooling, and the usual forming, storming, norming, performing cycle of building a team. Be up front about the risks and costs, be careful to set realistic expectations, and be up beat and prepared to advocate your approach.
Be a Reuse Bootstrapper
Like fusion power, code reuse is and always will be the future solution to our economic problems. My feeling is that developers often say they believe in reuse, but only the kind of reuse that starts after they build a new framework, rather than the kind where they build on what someone else has already done. How can that work until someone is willing to chose to build on someone else's foundation? At best, it means a rewrite every few years when team leadership changes.
Why Release Early And Often?
Release early and often is a mantra for many reasons. It gives life to our discussions about what the product should become, it makes real where we are, and it gives us a base for iterative/incremental changes. The pace of releases is pretty much an invariant for agile, with the difference being who receives the releases (customer surrogates or end users). Before agile, maintenance was estimated to account for 60% of the cost of software systems. This is a source of much consternation for managers and others, some who feel the product release is where software goes to die. For them, everything after the release is rework and paying to fix a product that they paid for once already.
Pre-release is Unnatural
Kent Beck writes that pre-release is an unnatural state for software products. It is certainly an inconvenient time because it is a time when you have no customers and you are paying for the product rather than the product paying for you.
Don't Criticize the Previous Team
While it might setup the developers who take over the rewrite as the heros and salvation of the project, I think there is a cost to criticizing the previous team's accomplishments.
- First, if you let people make up their own mind about the previous team, you have more time and energy for your real mission.
- It will be awkward if you need to work with members of the previous team, both developers as well as stakeholders like product managers, project managers, or customers.
- If you can get it working, you may find yourself receiving (or worse yet taking) credit for what the previous team did.
- On average, the previous team was probably average. On average, you might be average. You have more work than the previous team because you have a new methodology to put in place in addition to a project.
- If the old team was horrible, unless you are horrible too, you will eventually get credit for being better than horrible. If they were better than horrible, and you aren't noticeably better, saying they were horrible may invite unpleasant comparisons.
- If the old team was better than you thought they were, and you get into trouble because the organization is broken or the problem is ill defined or very difficult, things will go better for you if you haven't significantly raised expectations.
- If they expect what they were getting, but you do better, it is a win for you.
- To refrain from criticism is both good manners, and shows that you have class.