oftware as a Service (SaaS) companies are everywhere. With SAP and Microsoft joining this new-meets-old business model, SaaS has an element of gravitas missing from the application-hosting craze of the late 1990's. Chances are you work at a company whose management is changing—or has already retooled—its business model to embrace SaaS. You may be trying to anticipate the impact of this adjustment on the craft of building software that your customers need and want. One of my client companies went through this transition within the last 18 months and it chose to adopt principles of Agile Software Development to mitigate the effects of SaaS on its product management and software development teams.

A Not-So-Odd Couple
In a nutshell, Agile Software Development is a philosophy about the relative value of eight issues surrounding all software development. "Agile" adherents value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The congruence between Agile and SaaS makes a compelling argument for Agile's ability to support a company's SaaS adoption. In its own way, SaaS is very much like Agile:

• SaaS implies a highly accountable relationship between the software vendor and the customer just as Agile puts a premium on individuals and interactions.
• What matters most in SaaS is software that works and is always available, which sounds a lot like the "working software" goal that Agile practitioners strive to achieve.
• Virtually all SaaS deployments have some kind of try-before-you-buy option, which is difficult to undertake with perpetually licensed software (the best approximation to try-before-you-buy with perpetually licensed software is a narrowly scoped proof-of-concept system, which then forms the basis for a customer’s purchasing decision).
• While it may be stretching things to say that try-before-you-buy is akin to Agile's aims to collaborate with customers, it is nonetheless true that SaaS contract negotiations usually occur later in the sales cycle, a point of de-emphasis that an Agilist would endorse.

However, above all other considerations, SaaS is about aligning a software vendor's interests with those of the customer, so that the vendor responds quickly and efficiently to changes in the customer’s business. Need to add or remove seats based on business volume? No problem with SaaS; just adjust the amount charged in the recurring billing cycle. What about software upgrades? The vendor handles this chore and benefits accrue to both vendor and customer. The vendor reduces its burden to maintain older software, and the customer gets the upgraded capabilities as they appear without the expense of validation. Did someone yell out "scalability?" Scalability is inherently a vendor responsibility in SaaS that enables a customer to add seats or data without degrading performance. All of these examples of vendor responsibility and responsiveness resonate with the Agile creed to respond to change.

As you can see, SaaS and Agile do have goals and methodologies in common. But is Agile necessary when undergoing the transition to SaaS? The answer to that question is "yes."