Release Often Why high release frequency results in higher

customer satisfaction, better quality, and more revenue by Scott Shipp

Release Often 2

Introduction DevOps, continuous integration, continuous delivery, extreme programming, and many other sets of software tools and practices share one thing in common: the desire to release as often as possible. Why do so many companies covet this goal? What benefits can releasing often provide and how would increasing the speed of releases in a company affect the quality of their software? Is a strong case available for releasing software as often as possible? The answer is yes. Below are a number of reference points for the curious software professional who wants to answer these questions and guide their own company in the direction of more frequent releases.

How fast is fast enough? Jon Jenkins gave a talk that shocked many people in 2011. He later became the Head of Engineering at Pinterest but was the Director of Amazon Silk at the time. His talk, “Velocity Culture,” was presented at O’Reilly’s Velocity Conference 2011. In it, Jenkins revealed the slide below, saying that Amazon had turned off the last physical server at Amazon in 2010 and this had enabled them to shift to a new rapid-release culture. Their new culture was enabled by virtual servers and automated deployment software that allowed new releases of Amazon at the push of a button. Then he dropped a shocking statistic: Amazon now deploys new software an average of every 11.6 seconds.1

Designer and conference speaker Joshua Seiden reacted by calling this, “the new reality of software” even though it “consistently blows people’s minds.”2 Indeed, perhaps it was not so shocking of an announcement after all. By 2010, a large number of prominent software

Release Often 3

professionals ranging from XP inventor Kent Beck to Thoughtworks’ Jez Humble and Martin Fowler had all made it something of an activist cause to advance the idea that every software company should release as frequently as possible. Many companies besides Amazon had seen value in the idea, including Etsy, Spotify, Netflix, and even lumbering behemoth Microsoft. With Windows 8 and 10 Microsoft has announced a release cycle for Windows of 12-18 months (as opposed to about six years with previous releases) and they seem to be putting pieces in place that could allow even shorter gaps: Windows and Office licensing are now moving to cloud-based (via their “ECS” service) subscriptions and can release software rapidly to the cloud through their Azure infrastructure.3

Benefits of Frequent Releases There are three main categories of benefits discussed by advocates of frequent releases. First, the faster a business can release software the more ability they have to deliver value to users. Second, frequent releases generally result in improved product quality. Finally, shortened time between releases results in higher revenue and greater business value. Each of these three categories of benefits are discussed below.

User Value Why deliver fast? Customers like rapid delivery. That is why immediate shipping and rapid delivery is standard for online and mail-order catalogs and why while-you-wait services are popular. -- Mary Poppendieck and Tom Poppendieck, in Lean Software Development4 Improved user value is perhaps the most obvious by-product of frequent releases. Users of software appreciate new features, improved features, or even just simple bug fixes when they come quickly. By comparison loyal users become disinterested users and ultimately lost users when software grows stagnant. Proponents of frequent software releases raise another interesting point: user value can only be measured by the user. In Continuous Delivery, Jez Humble writes, “Delivering fast is also important because it allows you to verify whether your features and bugfixes really are useful. The decision maker behind the creation of an application, who we’ll call the customer, makes hypotheses about which features and bugfixes will be useful to users. However, until they are in the hands of users who vote by choosing to use the software, they remain hypotheses.”5

A related benefit is the ability to gather user feedback more often. Say that one company releases quarterly. In the first release, they introduce a new feature. In the second, they fix bugs in the feature. In the third and fourth, they successively respond to user feedback

Release Often 4

and experiment with different approaches. Say that another company releases eight times in the same timespan. They have eight user feedback opportunities as opposed to four, and have double the opportunities to hear from as well as please their users.

Improved Product Quality Frequent release advocates point to numerous positive byproducts. They argue against those who say that rushing to release something too soon is a sure way to push sloppy work and rough-edged features into a product. Instead they point to evidence that short releases have the effect of improving staff focus and freeing up efficient time for quality-related activities. For example, David Starr, a program manager at Microsoft, has the following to say: Increasing the frequency with which a team delivers working software has beneficial side effects, even when there's no genuine business case to make for releasing to a customer. Regularly exercising a delivery cycle as completely and as frequently as possible develops a team's skills for actually shipping. This drives the development and maturity of other necessary ingredients, including frequent code review, inspection and adaptation of those doing the work, collaboration with stakeholders, and minimal requirements expressions and inventories.6 Mary Poppendieck and Tom Poppendieck clarify that when they say “Deliver as fast as possible” it does not mean “rush and do sloppy work . . . we are not talking about rushing at breakneck speed to claim real estate. We are recommending a good farming practice." Perhaps Kent Beck’s criticism of the opposite practice—slow releases—makes the point even better: Software development has long delivered value in big chunks. 'Big Bang' integration reflects this tendency. Many teams make the problem worse by tending to respond to stress by making the chunks of value bigger, from deploying software less frequently to integrating less often. Less feedback makes the problem worse, leading to a tendency for even bigger chunks. The more things are deferred, the larger the chunk, the higher the risk. In contrast, the principle of flow suggests that for improvement, deploy smaller increments of value ever more frequently.7

Business Value Business value, including higher revenue and new markets, is also amplified according to frequent release advocates. David Starr believes that “shipping often offers amazing business opportunities.” Poppendieck and Poppendieck write that, “...the best way to

Release Often 5

optimize an organization is to focus on the throughput of the organization, because this is the key to generating profitable revenue.” One fear of any software company is being unresponsive to market changes. Many recall Lotus 1-2-3 or WordPerfect. Both were once-market-leading products that failed to respond to the shift in the market brought on by Microsoft Windows. The ability to release frequently is a competitive edge, allowing fast response to market changes. Don jones, a Microsoft MVP, analyzed why even Microsoft is moving to faster releases and observed that, “Smaller, more frequent releases will let Microsoft target today's problems today, rather than always being a bit behind the curve.”8 Similar notes come from Joel Spolsky, founder of Fog Creek Software, creator of Trello, and co-founder of Stack Overflow. He muses that once a piece of software has been out for any length of time, users won’t buy it simply because it’s been out for awhile. “As soon as an application starts to feel old, people stop buying it because they are expecting that new version Any Day Now. This can cause serious cash flow problems for a software business.” He stirs the pot further with the reality that besides this, “you may have competitors nipping at your heels.”9 One additional and easy to miss business advantage of frequent releases is the flexibility and willingness it provides to experiment. In a company that has achieved short times between releases, there is fertile soil for product evolution. If something receives poor user feedback or fails to capture interest, much less is at stake. The next release window is just around the corner. That flop of a feature can be gone in the next release, or it can be evolved to something new which may be successful. Dan McKinley, principal engineer at Etsy, has even attempted to rename Etsy’s “continuous delivery” to “continuous experimentation.”10 Finally, the largest risk to a software business’ profit margin is project failure. The Standish Group publishes annual research into a cross-section of software projects. Their data has consistently shown that shorter, smaller projects have a drastically higher chance of success, as evidenced in the two charts below.

Release Often 6

Source: Standish Group. CHAOS Report 2005.

Source: CHAOS Report 2008.

Release Often 7

Takeaways and Conclusion In conclusion, the new reality of software is to release new versions as often as possible. Releasing frequently has become the activism of well-respected software professionals from Joel Spolsky to Mary Poppendieck. And the software industry has listened. Software companies want to go fast. Releasing as often as possible, even as often as every 11.6 seconds, is now a goal thanks to new tools, environments, and cultural understandings of software. Rather than degrade quality, frequent releases actually improve a company’s engineering practice by forcing them to exercise their release muscles more often. Users receive more value than ever before. And ultimately the business benefits with higher revenues and greater flexibility to adapt to changing marketplaces. 1 Velocity 2011: "Velocity Culture" Perf. Jon Jenkins. Velocity Culture. O'Reilly, n.d. Web. 01 Mar. 2015. <http://youtu.be/dxk8b9rSKOo>. 2 Seiden, Joshua. "Amazon Deploys to Production Every 11.6 Seconds." Web log post. More Than This. N.p., n.d. Web. 01 Mar. 2015. <http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-production-every-11-6-seconds/>. 3 Foley, Mary Jo. "Microsoft to Make Per-user Windows Licensing Available to Enterprise Customers | ZDNet." ZDNet. Ziff-Davis, 4 Nov. 2014. Web. 01 Mar. 2015. <http://www.zdnet.com/article/microsoft-to-make-per-user-windows-licensing-available-to-enterprise-customers/>. 4 Poppendieck, Mary, and Thomas David. Poppendieck. Lean Software Development: An Agile Toolkit. Boston, MA: Addison-Wesley, 2003. Print. 5 Humble, Jez, and David Farley. Continuous Delivery. Upper Saddle River, NJ: Addison-Wesley, 2011. Print. 6 Starr, David. "So Long and Thanks for the All the Manifestos" Visual Studio Magazine. Redmond Media Group, 16 June 2013. Web. 25 Apr. 2014. <http://visualstudiomagazine.com/Articles/2013/06/01/So-Long-and-Thanks-for-the-All-the-Manifestos.aspx>. 7 Beck, Kent. Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley, 2010. 17. Print.

Release Often 8

8 Jones, Don. "Microsoft's Faster Software Release Cycle: A Blessing or a Curse for IT? -- Redmondmag.com." Microsoft's Faster Software Release Cycle: A Blessing or a Curse for IT? -- Redmondmag.com. Microsoft, 30 July 2013. Web. 01 Mar. 2015. <http://redmondmag.com/articles/2013/08/01/faster-release-cycles.aspx>. 9 Spolsky, Joel. "Picking a Ship Date." Web log post. Joel on Software. N.p., 9 Apr. 2002. Web. 1 Mar. 2015. <http://www.joelonsoftware.com/articles/PickingShipDate.html>. 10 McKinley, Dan. "Design for Continuous Experimentation." Design for Continuous Experimentation. Etsy, 2 Dec. 2012. Web. 01 Mar. 2015. <http://www.slideshare.net/danmckinley/design-for-continuous-experimentation>. Learn more about Scott Shipp at http://code.scottshipp.com.