While agile development practices have become more and more mainstream, some agile concepts are still prone to a “sure, but that doesn’t apply to me” reaction. One of these concepts is the principle of frequent or continuous deliveries.
A core principle
Continuous delivery of value is a core concept in agile software development; so much so, that it appears twice in the list of principles behind the Agile Manifesto. First at the number one spot:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
and then again at the number 3 spot:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
With agile practices evolving over the years, defining “frequently” on a timescale of weeks or months is even looking a bit old-fashioned. Organizations that have invested significantly in DevOps practices to automate the qualification and deployment of software builds are able to deliver new software much more frequently than that – with some releasing features and bug fixes into production many times a day.
Agile principles seem to assume that customers want a near continuous stream of incremental value to come their way. The interesting thing is, many customers in the enterprise space will tell you that they don’t want frequent feature releases. Why the disconnect?
Painful upgrades
Unfortunately, many enterprise IT organizations are “once bitten twice shy” when it comes to feature releases of core software. They remember upgrades that have gone terribly – with major functionality breakages, compatibility problems, and users complaining bitterly that the new software is harder to use. They just don’t want to experience that pain any more often then they have to.
If a business has invested significantly in in-house tools and applications, the disincentive to upgrade things that these applications depend on (operating systems, browsers, databases, other applications) is even stronger. In many cases these in-house systems are hard to maintain. They rarely come with suites of automated tests, and it’s a real burden just to test them – let alone to update them if a problem is discovered. If an update is required, there’s a good chance that the people who developed the original application are no longer available, and that the code, build, and deployment procedures aren’t well documented or well automated.
Against this backdrop, the agile mantra that “frequent feature releases are better” can be a hard sell – but the world is rapidly changing.
Firstly, IT organizations are more likely to be developing in-house applications using agile principles themselves. If they are following good agile development practices, then these newer applications likely do have a suite of automated tests that can help reduce the burden of testing. Also, these teams are more likely to understand that, by taking small incremental feature updates – instead of a big batch of them once every few years – they actually reduce both the pain and the risk of upgrades.
Secondly, Software-as-a-Service (SaaS) is becoming more and more prevalent for key business systems. Companies are choosing more often to focus on their core business and use SaaS software where possible. When adopting SaaS, companies normally give up the option of deferring upgrades. They trust the service provider to provide updates and upgrades that work – and – in the event of major issues – to correct those issues quickly. Upgrades become mostly non-events, with new features simply appearing when they’re ready.
Even if enterprises don’t go so far as to adopt SaaS for key applications, modern software vendors have invested in making upgrades smoother and more automated. Where customers need to customize or extend the core application, these same vendors also work hard to provide standardized mechanisms – such as plug-in architectures – to help to ensure that customizations remain compatible as the core product evolves. This makes it easier and less risky for IT teams to deploy upgrades.
Additionally, modern software vendors employ extensive “walk before you run” approaches to software deliveries and deployments. They automate the process of deploying new software to small groups of users and businesses and then gradually rolling out these same – but perhaps improved and stabilized – features to larger and larger groups. When problems do slip through, automated update and roll-back procedures allow for quick corrections.
Still, even against this backdrop, many enterprises continue to believe that feature updates are a pill best swallowed less frequently.
Don’t let your slowest customers dictate your pace of innovation
Software development organizations that receive most of their revenues from large, slow, less-than-modern enterprises may be tempted to bow to the pressure to deliver features infrequently. After all, it seems easier, and their biggest customers will often tell them outright that they don’t want so many feature releases. Customers might say that they can only accept feature updates once a year or even less often.
If you do decide to release features less frequently, you’re adopting a strategy that is rapidly losing favour in the industry, and that puts you at a significant disadvantage in a competitive market. Even if your existing customers don’t want to upgrade, what about new customers who may want your new features? How long should they need to wait to get a feature that you’ve already developed? And what about your competition? If the competition is quickly evolving and you aren’t, where are new customers likely to go?
You may be in a situation where you have a significant lead over the competition – or where you have a high degree of “lock-in”. Unfortunately for you, leads and lock-in only last so long in competitive markets. The best defence against the competition is to have the better product, and the best way to do that is to release new features frequently and to respond quickly to feedback from the marketplace.
All of this said, if you don’t have a market worth protecting (hint: if your biggest competitor bows out be very afraid), then of course you shouldn’t be investing in rapid feature development – you should be investing in the next big thing. To paraphrase Kenny Rogers, you have know when to hold ’em and know when to fold ’em.
If you do have a market worth protecting, your core applications and services need constant attention or they will become obsolete. You need frequent feedback as you develop and deliver new features or you will waste time and cause ill will by delivering the wrong things to your customers. Major feature missteps can’t be fixed with simple maintenance updates, meaning it may take many more months to course-correct and deliver what customers really want and need.
As for lock-in, with today’s licensing models moving to subscription-based and metered models – and with customers demanding data export options as an insurance policy before they’ll sign up – your customers are likely to be less locked in. This provides them with the ability to “vote with their feet” more easily than ever before. You may think this is a bad thing. You don’t want your customers to mass-migrate to a competitor’s product. Really though, it’s good for both of you. Artificial lock-ins only delay the inevitable. If it’s relatively easy for your customers to abandon you, and if some of them start to do so (you do have good metrics, don’t you?), it’s time to take notice or become obsolete.
Hedging your bets
Microsoft is an example of an organization that has started providing more frequent feature releases while hedging its bets by also offering long term servicing for Enterprise customers willing to pay for it.
Microsoft calls their new approach “operating system as a service”. In the past, Microsoft released a new version of its Windows operating system every few years with much fanfare, only to see some releases receive a lukewarm response and low adoption rates in the market – especially in the Enterprise market. Windows Vista is the most famous example, but Windows 8 had similar problems in adoption, with users complaining that it was difficult and confusing to use. This resulted in Microsoft releasing Windows 8.1 not long after – with Windows 8 proper considered by most to be a dead release, and Windows 8.1 also not seeing broad adoption in enterprise markets.
With Windows 10, Microsoft decided that “stealth development” – keeping customers in the dark about what the next operating system release would look like – wasn’t the best strategy. They introduced the Windows 10 Insiders program, offering public preview releases of the operating system as it was developed. These preview releases continue today, even after the official Windows 10 RTM release – as a sort of beta program to get early feedback from the market on upcoming feature releases. Feature releases, instead of being 1 to 3 years apart, are now planned to to take place about 3 times a year.
When a feature release goes out (reaches RTM), Microsoft also provides several options for enterprises:
- Current Branch (CB)
This option allows customers to pick up new feature releases when they are first promoted to RTM. This is the default and recommended option, and the only option for the consumer editions of Windows. Each new CB feature release is supported for about 4 months, at which point a new CB release is issued and subscribers are moved to that release. - Current Branch for Business (CBB)
This is a deferred delivery option. It allows subscribers to wait about 4 months, with an option to delay an additional 4, from the time that a feature release is promoted to RTM and delivered to the CB subscribers. This provides time for the feature release to get additional market testing and service updates as well as more time for each business to test the new feature release before adopting it. CBB upgrades arrive just as frequently as CB upgrades – they just lag by around 4 months and come with more flexibility on when to deploy them into the enterprise. - Enterprise Long Term Service Branch (LTSB)
This option is for enterprises that want to lock down on a set of features for years instead of months. Customers who choose this option can stay on selected releases for up to 10 years, receiving only service updates and no new features. Besides missing out on new features, these releases are also very limited in the applications included as part of the operating system – with Microsoft removing most of the universal apps that are normally included. The LTSB option is designed for cases where Windows is simply a base on which to run some specialized and critical application – for example cash register software.
These options allow Microsoft to reduce product cycles, providing new features to customers faster and getting faster feedback while limiting service update costs. Service updates are only provided for about one year from the time a new feature release goes RTM, at which point customers are expected to have already moved to the next feature release. The deferred delivery and LTSB options also allow more conservative enterprise customers to maintain more conservative upgrade schedules if required. Enterprises are expected and encouraged to employ a mix of options so that new feature releases can be gradually deployed to larger and larger groups in the organization.
A “hedge your bets” approach like Microsoft has taken may be appropriate for your business if you have a mix of customer types like Microsoft does – with some wanting or needing to remain conservative and slow to adopt new features, while others want to keep up with the latest and greatest. This approach provides a lot of flexibility for service consumers.
The downside for software providers is that providing service updates for multiple parallel branches is expensive and can’t be fully automated since fixes must often be manually adjusted when the code has evolved over time. The cost of back-porting bug fixes and security updates must be justified by the additional revenue it brings in. The opportunity cost also has to be factored in.
When choosing your own approach, remember that your long term success is dependent on your ability to remain competitive. Consider policies that encourage customers to upgrade more frequently, ending standard support for older feature releases after a reasonable time period, only back-porting important security and stability fixes, and making long term support more costly for customers that need it.
What about inconvenience to end users?
One reason for not deploying frequently to end users may be that the upgrade process is intrusive and can interfere with customer productivity. If your upgrades fit this description, and you want to deploy upgrades and updates more frequently, then you owe it to your business and to your customers to improve the situation as much as possible.
Work performed to make upgrades and updates automatic, and to avoid or minimize downtime and reboots, is time well spent. Where downtime is unavoidable, allowing administrators or end users to easily schedule that downtime makes it much less painful. It should also go without saying that you want to be sure your upgrade process smoothly handles common issues like slow or unreliable networks, power loss, or disk space issues.
What about my splashy press release?
Besides “my customers don’t want frequent releases”, another reason I’ve heard for releasing less frequently is that each feature release then becomes so tiny that it isn’t special. The marketing team has no big list of exciting new features to crow about in press releases, trade shows and conferences. They can’t generate excitement around upcoming or newly released features when releases are so small and incremental.
My response to this is perhaps naive. I’m no marketing or sales expert. But what I think when I hear this is “so what”? There’s nothing to stop marketing from doing “year in review” or “this quarter” and “coming soon” press releases that highlight larger key capabilities.
Won’t my product look unfinished?
Another argument for releasing features less frequently is that if you provide only small increments of value, your features may look unfinished. The thinking seems to be that if you show your customers an unfinished feature, they’ll think less of your product as a whole.
This objection, I think, can be handled with some simple setting of expectations. Many companies have developed a practice of taking these kinds of new features and allowing them into production releases – but labelling them as “labs” or “beta” features – with the ability for customers to turn the features on or off at will. Often the features will be off by default in production releases until they reach some level of perceived maturity, but on by default in preview or beta releases. If the feature offers enough value to be useful, customers can turn the feature on. If it doesn’t, they can turn the feature off.
Your development teams will be happier
It’s well known that happy and engaged developers are more productive. Their passion and commitment to what they are doing will make them more innovative and more likely to help drive your company to further success.
Passion and commitment come from empowered contributions to things developers believe in – and part of what makes developers feel empowered is the ability to deliver their software to customers who will benefit. Frequent deliveries and deployments, combined with monitoring and metrics, also provide either quick confirmation that their work was appreciated and useful, or a way to learn and course correct without wasting too much time on the wrong path.
Frequent releases do require a DevOps mindset including a strong commitment to automation. If you don’t yet have the tools, infrastructure, automation and supporting processes in place to release frequently, you need to build these before you can realize these benefits.
Despite the advantages, when you first try to bring in more frequent releases you’re likely to get some significant backlash from your development teams. They’ll say that there’s too much overhead involved in releasing so frequently – which is almost certainly true given the tools and processes you currently have in place. Similar to your large enterprise customers, they’ll want to stick with less frequent releases to avoid the pain of releasing often.
You have a bit of a delicate balancing act here. On the one hand, you don’t want things to be so painful that they make people miserable. On the other hand, a bit of pain and discomfort is what drives people to improve. So don’t try to go straight from once year releases to daily releases, but do keep strengthening your release muscles by improving your cadence over time.
Improving your release cadence is a lot of work and may require many changes in development, testing, and deployment practices, but the end result is worth it. You owe it to your your company and your developers to give them the tools they need to realize their full potential to make a positive impact on the world. You should be satisfied with nothing less.
Yes, even for enterprise
Large enterprises can be risk-averse places. This tendency can ironically lead to their downfall. They mistakenly trade the risk of a short-term disruption to their business for the bigger long term risk of falling behind and becoming irrelevant.
Fortunately, even large enterprises – like Microsoft – are becoming more agile and adaptive. If you’re selling into the enterprise market, these more adaptive enterprises are the ones to watch. Absolutely provide support models for your slower customers, assuming that they and you can afford them, but don’t let that stop you from innovating and getting feedback quickly. The principle of faster and more frequent deliveries of value does apply – even for enterprise software.