Fix It the Agile Way
Change is built into the Agile process, so dealing with the above scenario using Agile is fundamentally different. In typical Agile fashion, product management defines the product requirements and works with various constituents to build a set of "user stories" on the expected behavior. User stories are of the form: as a <user>, I want <capability> so that I can <benefit>. (A simple search for "user stories Agile" will result in a number of sites discussing this technique.)

Then, the development team weighs in with some high-level estimates on the relative complexity of these stories, and the product management team uses this information to discuss and determine the capabilities of the next release among their constituents. Once this high-level planning is complete, the development team iteratively implements each of the stories in the release. Each implemented user story is checked into the current code branch as potentially releasable software; that is, within the iterative development period, the engineering and Q/A teams have completed enough of the design, coding, unit testing, and system testing on the completed software that it could be released. Checkpoints and reassessments of development priorities are built in and frequent so that late-breaking changes are embraced within the process itself. Hence, no more fire drills, just realigned priorities.

Take another look the late-breaking scalability problem when the principles of Agile Software Development are in play:

1. The sirens go off in the executive suite. This never changes.
2. If the problem has dire consequences and needs immediate action, the product owner (usually a member of the product management team) terminates the current iteration of development. This means that your work since the beginning of this iteration is set aside. Otherwise, the current iteration is allowed to finish and a batch of potentially releasable software is checked into the main branch of code.
3. The product owner, along with the operations and development teams, defines the expected behavior as a set of user stories. This exercise takes about half a day, but could be longer if more people are involved or if the performance issue touches a broad swath of the customer base.
4. The product owner convenes the development team to make some rough estimates on the effort to implement each of the user stories. These estimates are unit-less; they're used solely to gauge relative story complexity and as tallies against the team's total historical development capacity.

Author's Note: Fibonacci numbers in the range from "1" to "55" work well here. The development team might say that story A is a "3" and story B is a "13," which means that story A is probably less complex than story B based on the information available.

5. The product owner determines the minimum stories necessary to overcome the performance obstacle, and sets up a release cut-line. The stories above the line must be in the release. This takes another half day if operations, tech support, and account management are consulted as to what constitutes the minimum number of stories.
6. Tallying the rough estimates of the stories above the cut-line, the product owner then divides this sum by the development team's historical capacity to produce potentially releasable software within a fixed duration of time (usually between two and four weeks). The result is a sequence of iterative development and testing cycles that converge on the solution. Each cycle is called an "iteration."
7. At the end of the second day, senior management asks for an update. The product owner presents a series of user-focused behaviors that the new software will deliver along with an estimated time to completion—based on the development team's past performance. This conversation goes very well with the executives. They give it the "Sounds good, run with it" speech, and the product owner heads back to the war room.
8. The product owner gives the above-the-line user stories to the development team and provides additional detail to the team as they go into detailed planning for the first iteration of software development.
9. The development team commits to producing potentially releasable code at the end of each iteration, and the product owner is the final arbiter as to the acceptability of that software.
10. While the engineering team is working during an iteration, the product owner evaluates late-breaking information that may require additions to or subtractions from the list of user stories above the cut-line. At the beginning of the next iteration, the product owner presents the new information and priorities, and the development team works off this list of user stories. This adjustment exercise has almost no negative impact to the development team because all work to produce potentially releasable software occurs within a single iteration of development, not across two or more iterations.

Author's Note: There are two consequences to violating this rule. First, what would be produced at the end of one iteration would not be potentially releasable. Second, and more dangerous, it would be difficult for the product owner to change priorities between iterations in response to late-breaking information because the code is only partially complete. In general, a need to span iterations derives from a user story that is too broadly written.

11. As necessary—perhaps after a few iterations—the team demonstrates the potentially releasable software to the senior executives, who give the "Keep up the good work" speech. This is the desired outcome! Since the company is using Agile, no one has lost nights and weekends performing heroic deeds to save the company from impending doom. You spend your evenings and weekends with friends and family. When they ask you how work is going, you give the "It's going pretty well" speech.
12. When the software is released, the product owner directs the team to resume work on the usability project. You check out your software from the main branch and continue on with your work.

The Best Method To Handle Change
Though I posited earlier that Agile Software Development is preferable due to its congruency with the goals of SaaS, the reality is that Agile is a necessary methodology for SaaS adoption. Managing change is the core principle of Agile Software Development, and this is key if your company is moving to SaaS. And Agile isn't only better after you've migrated, Agile is the best method to help you migrate!

In preparing for SaaS migration, the smartest people in your organization will have to use all their experience to specify, design, implement, test, and deploy the software. Even so, it's the nature of such a change that no one can foresee the critical shortcomings that will slip through all of this planning. The preceding scenario shows one such real-world, unanticipated problem and how an Agile organization absorbs it smoothly. If your company is jumping to SaaS, take Agile along with you.