SaaS and Agile: BFFs
In my last post in this series “The Origins of Cloud Computing and SaaS”, I explored the origins of cloud computing and the SaaS business model in the evolution of underlying technologies (storage, compute, communication, and software development cost), which now favor a ‘thin-client’ model of computing consumption.
My main point was that IT infrastructure is determined by the cost and performance of hardware (compute and storage), communications, and software/application development (all relative to each other and the type of activities to be performed). Today, relatively low cost hardware, high performance communications, and relatively high cost software development have led to the cloud computing/SaaS paradigm.
[Side note: This paradigm is dominant today for many enterprise applications, but not ubiquitous and specific applications will find their own best architecture (E.g., a few months ago, I wrote about how local compute demands to render VR could increase demand for higher performance PCs and gaming consoles).]
In the post, I explore how the SaaS business model is mutually reinforced by Agile software development.
The causal link here is a bit sneaky — cloud computing unshackles software from the constraints of physical goods and decouples feature development from the release cycle. Thus, companies can bring software products to market faster, increasing the competitive pressure to do so. This in turn accelerates innovation such that businesses built around an Agile development process gain competitive advantage.
Physical Goods vs. Virtual Goods
Remember when you used to get America Online CD-ROMs in the mail? Since consumers didn’t have internet, they had to send you software via a physical delivery device (a CD) so you could get online.
The AOL case is a simple one where connectivity speeds were 0, so information had to be delivered physically. But even after you hooked up your 28K modem to AOL/the internet, it wasn’t like you were going to be able to transmit information quickly. I remember (circa 2002?) having a 28K modem and using Napster. I would queue up a hundred MP3s to download right before going to bed and then wake up excited to see which had actually finished by morning. Because of the relatively slow speeds and expense of communication in the on premise computing / PC era, information goods acted more like physical goods.
The beauty of information is that it can be unbound to the physical world (virtualization). When information goods are delivered via physical processes, they inherit all of the baggage of physical goods.
Relative to virtualized goods, physical goods are severely limited with respect to versioning and updates. You need to set a target for what features you want in the release, build to that release, then customers get the product and can react to it.
Once sold, it is expensive and time consuming to alter physical goods. For example, when a car manufacturer messes up the design of a product, you get a recall.
As a result, there is extremely tight linkage between product feature development and product release. And that means you really don’t want sell the product and deliver it to the customer before you are done building it.
That’s a big problem when you find a mistake or if you want to give customers the benefit of ongoing product development. You either need to do an aftermarket upgrade or sell them an entirely new product. To manage this dilemma, companies define discrete product versions, like car model years.
The Move to Incremental Release Software
When internet speeds were slow, software was delivered either by installation on a local machine (PC) or on a dedicated server. It was complicated and challenging to update software, so it needed to be stable when released.
This meant having a software development lifecycle completely oriented around release. The ‘waterfall’ methodology ‘cascaded’ in stages from architecture and design to writing the code to testing and Q&A to finally deployment (either via printing copies of software or deploying it on local servers).
This process was focused on packing in as many features into each release as possible, which meant planning out the features well ahead of time and, as much as possible, debugging them.
When there were problems, it was fixed via a patch.
It also meant that improvements or customizations took place on a local instance (e.g., one company’s ERP system) and could not be easily copied and replicated. In a sense, there was aftermarket rework and customization, making the information good a lot more like a physical good.
The Internet Allows Information Goods to Decouple from Physical Delivery Model
While it is still more cost effective on an absolute basis to ship data physically than via the internet, for the vast majority of relevant consumer and commercial applications, high speed internet works just fine.
In the 1995 ‘Introduction’ to High Output Management (originally published in 1983), the great Andy Grove discussed how “email is also the first manifestation of a revolution in how information flows and how it is managed…everything that’s digital can be shipped around the world just as fast as it can be shipped down the hall at your workplace” . The beauty of software delivered via the internet is that you can upgrade it and change it whenever you want.
Implications of Decoupling Development from Release Cycle
There are three mutually reinforcing implications of decoupling development from the release cycle.
First, it significantly reduces the cost to upgrade software by incrementalizing updates.
Second, it creates the potential for a dramatically strengthened feedback loop between vendor and customer. Given competitive markets, the companies that best establish that feedback loop in order to build products responsive to customer needs will win.
Third, software companies need to ditch ‘waterfall’ style development that aligned to long release cycles and instead embrace Agile which enables rapid, consistent release.
Cost to Upgrade
It used to be that an upgrade to a new version of a software product was both a business and technical exercise. Business folks needed to be trained on how to use the new software, then the new software needed to be installed, data migrated, testing, Etc.
While change is inevitable to provide improvements to user experience and business outcomes, big change all at once is really bad for the user experience and disruptive to business. And so the trend, broadly speaking, has been towards faster release cycles that deliver more incremental changes.
The classic illustration of this phenomenon is Amazon:
Information goods become more like physical goods the less frequently they are updated. If a user moves directly from the 1999 Amazon site to the 2016 site, the user experience would be completely disrupted. But when the changes are rolled out incrementally, a little bit all the time, there is a shared understanding between developer and consumer. When release cycles happen infrequently, information goods become harder to change, when they happen frequently, change is easier.
Customer Feedback Loop
The best pre-launch user testing doesn’t really simulate the real thing, for a service delivered online, you get constant customer input (you can literally track clicks and keystrokes).
With web-based products, a company can track constant customer input. The move from waterfall to Agile implies the ability to rapidly respond to that input. A customer need can be identified and new feature can be developed in a matter of days or weeks, not months or years.
Decoupling development from release inverts the logic of product development. Instead of building up to a finished product, companies release the minimum viable product and build out features based on what customers demonstrate a need and willingness to pay for.
This boosts the need for strong customer development and analytics to pinpoint the source of customer value and enables testing of new features in subsets of users.
Agile Development
Whereas waterfall development is completely organized around the release, agile development is oriented around the sprint designed to produce shippable code. Agile enables organizations to iteratively build software — which provided competitive advantage to its original adopters (better products faster) and is now becoming tablestakes (regular updates and improvements: not waiting months for your CRM vendor to fix bugs).
Cloud computing and the web gave rise to the need for fast product development cycles — which in turn required new ways to build software.
It is no coincidence that the Agile Manifesto was first published in February 2001 — in the waning days of the Web 1.0 bubble. The Agile Manifesto :
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
It’s further no coincidence that the Lean Startup methodology was developed by Steve Blank and Eric Ries a few years later. The Lean Startup is built around the concept of “Build-Measure-Learn” — essentially a market-product cycle modeled after an Agile sprint.
In my next and probably last post in this series, I’ll explore how Agile software development methodology actually improves the ethical norms of companies and thus the satisfaction of developers. This will complete one example of the casual chain from technological discovery to economic and business change development to political and social development.
Bonus: A Note on Hybrid Goods
Physical good companies are getting in on the action with hybrid models — for example, when Tesla released its ‘autopilot’ mode, it was available not only on new cars, but also on ones already purchased and on the road.
All it took was a software upgrade, downloaded into the vehicle overnight. And after release, Tesla kept upgrading the product — as Elon Musk noted, Tesla drivers might “notice one week it won’t steer right going across a weird freeway off ramp, but the next week it does.”
We should expect to see more of this with the Internet of Things.
Amazing.
