Along with software updates, there is one thing you should always be delivering as part of your continuous delivery chain, and that is customer satisfaction.
To put it bluntly, if you are in the business of developing or maintaining software that people will use (or that they will interact with in some way), then you need to take into account what those people like or dislike about your software, what makes using your software difficult, and what makes it easy.
If you don't do this, you aren't doing your job, and both your software and your organization will suffer for it.
The Price of Letting Your Customers Down
The cost of not being sufficiently customer-centric can be high. Customers may not tell you when they're dissatisfied with your products or services. And if they don't like what they get, they are likely to look for alternatives, or worse yet, tell their friends and business associates all about their unhappiness with what you have to offer.
When you fail to keep your customers happy, you don't just lose their future business—you also generate negative word-of-mouth advertising, potentially costing you a greater number of potential customers, who may not even give your product a chance if they have already heard too many complaints about it.
Online Customers Can Be Invisible
For Internet-based applications and services updated by continuous delivery, the difficulty of being sufficiently customer-centric is made even greater by the lack of direct contact between the delivery team and end users. Customer feedback may consist almost entirely of metrics which capture raw statistical behavior, rather than direct communication from individual users.
You need first-rate analytics, and you need to know how to interpret those analytics before you can understand how customers are responding to the most recent changes to your software. And by the time that happens, it may be too late—The most dissatisfied customers may have already voted with their feet.
What kind of customer dissatisfaction problems are we talking about? Some are common to virtually all types of user-facing software, while others are more typical of the continuous delivery environment itself, but from user’s point of view, they are all gratuitous annoyances:
Functional and Performance Problems
One of the nice things about continuous delivery is that if you do post a not-so-wonderful update, you can quickly roll back to the previous version. But the continuous part of continuous delivery also means that updates with major functional or performance problems are likely to go live from time to time, if only for a little while.
When this does happen, users are likely to be the ones who discover the problem first (particularly in the case of performance issues), and they are the ones who will be the most directly impacted by it until it's fixed.
Any problem that makes it difficult or impossible for people to perform necessary tasks is likely to drive users away, and once they leave, they may never come back. Even if you are lucky enough to have a captive market, an accumulation of functional issues is likely to make them more receptive to an alternative, if and when one does come along.
Security Can Be "Make or Break"
Everything that is true of general functional/performance issues is also true of security bugs that go live, but in the case of security problems, the customer relations fallout is multiplied by a couple of orders of magnitude. Even a small security issue (such as an unmasked password entry field) can erode customer confidence. An all-out security breach can destroy your reputation.
When customers use your software, what they see is the GUI. It is the face of your application or service, and if that face doesn't look good, they will notice. It isn't just a matter of appearance, either. GUI problems can affect usability if, for example, labels are missing, or only partly visible, or input fields are hidden.
When you reorganize the GUI, you are forcing existing users to change the way that they have interacted with the software, which people may resent, particularly if the new arrangement is not significantly more convenient than the old one.
New and unimproved
It is all too easy to unknowingly make an application's user interface significantly less convenient. Reorganization can interrupt the existing flow of user input, or make key input or output screens harder to find. Changes in something as simple as font size or typeface may cause problems for some users, or in some browsers. Drop-down menus may not roll back up in all browsers—or on some systems, they may act more like spinners, displaying only one option at a time.
Additionally, even a minor GUI problem may have more of an impact on customer satisfaction than a fairly major backend error if it's an annoyance or an inconvenience. It can say to your users that you really don't care about how they feel. And that is something that you never want.
Some people just don't like change, and some of those people are probably your customers. There isn't much that you can do about people who are dead set against any change, but there may be ways to win over the much larger group of people who are suspicious of change at first, then gradually warm up to it.
With continuous delivery, however, visible change tends to be frequent, which may annoy users who would otherwise not mind an occasional facelift to the GUI. The aesthetic or personal comfort effects of specific GUI changes may also be a source of unhappiness for some users.
This is particularly true with social media (for example, a "Here's what your friends are saying about you behind your back" or "Look who your ex is going out with this week!" ticker might not go over as planned), but it also applies to any kind of user-facing software. If you make your customers unhappy for any reason, they will want to go away.
Customer-Centric Continuous Delivery
How do you make your continuous delivery chain customer-centric? it really isn't that difficult. For the most part, you simply need to adopt basic best practices for software development and delivery:
Test throughout your continuous delivery cycle, and make testing an intrinsic part of the process. this should include not only the obvious functional tests at the code and unit levels, but also integrated testing for both functionality and performance problems.
Don't just monitor for the metrics that make your marketing people happy. Monitor for performance, for functionality problems, for load, patterns of use, anomalous user activity, and monitor for anomalous application behavior. Monitor, and apply a sophisticated set of analytics, along with a comprehensive, customizable dashboard and a good alert system. Don't simply monitor the surface. Go deep.
Roll out upgrades to a limited/test subset or focus group first. Whatever system you use (A/B, canary, opt-in user preview, etc.), your changes should go live to a limited set of users long enough to detect functional, load, and stress issues. Only do a full deployment after changes pass the test rollout phase.
GUI Focus Groups
For major GUI changes, it can be very helpful to set up a focus group in order to get a reasonable picture of likely user reactions. For minor changes (or if a dedicated focus group isn't feasible), your test rollout group may need to serve that function (which could mean soliciting users in the test group for feedback, as well as monitoring user behavior on the pages that contain the GUI changes).
Before major user-facing changes become mandatory, give users the choice of trying them out (opt-in), or sticking with the old version (opt-out) for a while. You can do this as part of your test-rollout strategy, or as a post-rollout grace period, in order to give users a chance to get used to the changes.
Being customer-centric doesn't (and shouldn't) mean compromising the quality of your software or the integrity of your continuous delivery system. In fact, it means the opposite—applying practices which will guarantee the quality and integrity of your software and your delivery system. More than anything else, customer-centric software is good software, done the right way.
Michael Churchman is a Fixate IO Contributor. He started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues.