I’m the middle of a Scrummerfall (http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.aspx)

Euphamisticlly defined by Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Perhaps this:
Scrummerfall. n. The practice of combining the meetings of Scrum with a Waterfall process. This ensures that the team doesn’t have to change the way they work while adopting Scrum.

Right now I’m at the tail-end of a project with a first-time Scrum team. Here is where we’re at.

100% Code Complete!

I still have no idea what the phrase “code complete” means (other than the title of a great book by Steve McConnell). Making this declaration with 35 bugs open is meaningless. The team front-loaded all feature development, postponed testing and deferred bug fixing. We’re still finding bugs.

Here are some symptoms to this approach

• Broken window syndrome: Developers come across bugs (while doing other bug fixing) which they dismiss. “yea, it’s not supposed to work in FireFox yet.”
• Increased project risk: The team explicitly scheduled 6 weeks of bug fixing time. No portion of the system is in a working state when “Code Complete” was declared. It’s unclear how much work is remaining to gauge if the system will be in a shippable state by the deadline.
• Time wasted on integration. To hit the “Code Complete” deadline, merging with other branches was deferred for two months. Several days have been spent just doing the merge. Bugs related to the merge continue to fall out.
• Other teams have to use our buggy system for full end-to-end testing.
  People actually like the bug triage process. For some strange reason, folks are finding comfort in seeing a big number get chipped away at over the course of several weeks. It’s not seen as wasted time.

• Low Quality, Little Automation

I believe a core Agile principle is to deliver a high-quality system at frequent intervals. When a team is doing the Scrummerfall there is no pressure on keeping a system healthy. Why invest in automated tests and automated deployments when there are two (or three) Sprints at the end dedicated to testing and bug fixing?
If a team is delivering a high-quality product at frequent intervals, it’s because some investment has been made to ensure that the quality always remains high. Usually, that means testing the system all the time. Testing is painful. When all the features in the system are verified by hand each iteration (”yup it still works”) someone eventually says “enough is enough” and begins automating tests. In the Scrummerfall there is no pressure to have a high-quality system at frequent intervals. Deployment, testing and bug fixing are deferred to the end. The pain doesn’t happen frequently enough for someone to try to fix it.
Mike Cohn likes to say, “The deadline [of the Sprint] is sacred.” I like to say, potentially shippable is sacred.