5 ways to drive agile experimentation using feature flags

Cloud application architectures, microservices, CI/CD (continuous integration, continuous development) pipelines, test automation, and infrastructure as code are all technologies that enable agile development and devops teams to deliver code to production frequently. They have taken software development from the days of quarterly releases and complex integrations to a modern era of continuous development.

Developers have always been concerned about how to manage the codebase to support frequent releases, developer productivity, feature development, and code refactoring to address technical debt. Github enables different development and branching paradigms, including feature branches, release branches, trunk-based development, and Gitflow workflow. Branching strategies structure what code goes into builds and thus can be used to control which features get deployed to end-users.

Despite an ongoing discussion on branching approaches, there’s a strong consensus that development teams should avoid using long-running feature branches. Long-running feature branches often create complex code merges when the feature is ready to be integrated into the main branch.

What is feature flagging?

Branching controls code deployment and can regulate whether a feature gets deployed. But this is only a gross, binary control that can turn on and off the feature’s availability. Using only branching to control feature deployments limits a team’s ability to control when code gets deployed compared to when product leaders enable it for end-users.

There are times product owners and development teams should deploy features and control access to them at runtime. For example, it’s useful to experiment and test features with specific customer segments or with a fraction of the user base. Feature flagging is a capability and set of tools that enable developers to wrap features with control flags. Once developers deploy the feature’s code, the flags enable them to toggle, test, and gradually roll out the feature with tools to control whether and how it appears to end-users.

Feature flagging enables progressive delivery by turning on a feature slowly and in a controlled way. It also drives experimentation. Features can be tested with end-users to validate impact and experience. Jon Noronha, VP Product at Optimizely, says, “Development teams must move fast without breaking things. Progressive delivery helps isolate the breaks to small pieces and reduce the blast radius that can take entire applications down.”

Let’s review several ways development teams can drive agile experimentation using feature flags.

1. Control features in development and test environments

How many times have applications in development or test environments accidentally sent emails to internal users—or worse, to external customers—because of an incorrect configuration setting? Has a batch job run when it wasn’t supposed to, or an application processed credit cards when beta testers were testing new capabilities?

These may be configuration settings that are easy to enable or disable if there are only a few environments. But what if, in addition to development and test environments, there are also demo environments for customer testing? What if you want applications in demo environments to send emails out to a specific list of domains, or you want to test specific payment transactions?

Also, what if developers or system engineers shouldn’t have these controls, but you want to expose them to business managers who can operate environments for different business needs?

You’re not going to able to do this level of configuration in code- or systems-level testing once there are many variables, configuration settings, and owners outside of IT needed to control them. Feature flagging is one way to enable these controls and may be easier than custom coding administrative tools.

2. A/B tests of the user experience, design, and language

Designers often want to test user interfaces and feature designs with end-users to gauge their ease of use and impact. Developers and designers can test different designs in several ways to validate which ones get more traction.

• Imagine implementing a “buy now” call to action with different graphics, button styles, and text to see which approach generates the most clicks.
• Let’s say your application allows users to sort search results by several dimensions. A designer can test different controls to support multilevel sorting and see which approach test users like more.
• Enabling users to set privacy controls and configure applications can be tricky, especially deciding on levels of granularity, language, and controls. Testing several approaches is one way to let users express which approach is easier to understand and control to their needs.

3. Alpha and beta test new technology

At times developers need to test new services, libraries, or software development kits. Other times, an available upgrade includes new capabilities. How should agile product owners and development teams know which components and capabilities are ready for critical applications?

One way to take the guesswork out is to implement features, control them with feature flags, and release them as alpha features. Developers can enable alpha features for a small group of internal employees to provide feedback on the new capabilities. Once the development team addresses any issues or risks, the product owner can then enable the feature for internal and external beta testers.

4. Validate performance by slowly increasing access to new capabilities

A variant of alpha and beta testing is when development teams slowly increase access to a new capability to ensure its reliability, performance, and robustness.

Depending on the feature flagging tools used, there may be different levels of information and controls available to manage an incremental rollout. Some advance use cases include:

• If errors are detected, decrease the number of users who see the new capability until issues get resolved. Errors may come from user inputs that aren’t sufficiently validated or errors from new or updated third-party services, microservices, and databases.
• If response time increases above a defined threshold, then reduce the availability of the feature. A related approach for when teams can’t adequately load test includes slowly increasing a new feature’s availability until performance is validated.
• Another emerging use case is validating the response to machine learning and artificial intelligence algorithms, such as chatbots, natural language interfaces, image recognition algorithms, and voice controls. Applications can be programmed with advanced feature flags to control which use cases are enabled as algorithms are tested and improved.

5. Roll out features by geography, language, or other customer segments

One important consideration is turning on features for specific customer segments. For example, a feature may be ready to be exposed to users in the United States, but regulation prevents it from being used in the European Union. Another example is features that require language-specific implementations; feature flags can enable the selected languages. Product owners may want to enable new features for first-time users, low-risk customers, or other demographics.

Although feature flags offer several options to slowly roll out or configure the availability of features, it’s important to use them for these purposes. Using feature flags as a cheap substitute for implementing business logic and related parameters may create application support issues. Also, it’s important to catalog the flags and prune them when they are no longer needed.

Since today’s developers must test new capabilities faster, feature flags provide the tools to enable experimentation and deploy new capabilities with fewer risks.