Back again with another software delivery article! Today we’re going to talk about what a feature and feature flag is in agile software delivery. They’re two distinct things but are related especially if you want to experiment often. We’ll talk about some pros and cons + a few other topics. Regardless of process, time to market, customer feedback and being “nimble” rather than following strict process that slows everything down is an important mantra in my mind.So let’s get to it!
What is a feature in agile software delivery?
A “feature” refers to a distinct element of functionality that can provide a benefit to the user. Features can range from user interface designs to APIs and can be anything that adds some kind of value to the software from the user’s perspective. I typically like to talk about what would be the minimum incremental feature that a customer would love. Not really an MVP but moreso what can they use and give you feedback on.
Here are some examples of what might be considered a feature in software:
How do you create small incremental features?
As previously mentioned above, I typically like to talk about what would be the minimum incremental feature that a customer would love. Not really an MVP but moreso what can they use and give you feedback on. Here’s a few examples in the traditional sense:
- Defining the “feature” / Epic: An epic is a large body of work that can be broken down into a number of smaller tasks (or stories). It’s often a high-level requirement or feature that needs to be implemented. The first step is to clearly define what the epic is and what it aims to achieve. Ie, we are going to add the visa support feature for our payments business.
- Create User Stories: User stories are small, self-contained units of work that can be completed by the team within a sprint (typically a 1-2 week period). A user story should be small enough to be completed within a sprint and should deliver some kind of value to the user. User stories are often written from the perspective of the user, e.g., “As a [user], I want [some feature], so that [some benefit]”. If you’re using kanban or something else, think of it from the lense of cycle time. How long will this ticket take to get through to done? 3 days? 5 days? How can I best serve my customer.
- Break Down User Stories If Necessary: If a user story is too large to be completed within a sprint, it may need to be broken down further into sub-tasks. Each sub-task should be a piece of work that contributes towards completing the user story
- Prioritize the Work: The team, often with input from the product owner or stakeholders, should prioritize the user stories based on their value to the user, the effort required, and any dependencies between stories. This helps to ensure that the most important work is done first. Another way to do this when you’re a bit more mature in the process is looking at financial, technical and customer impact. The easiest way I found was to prioritize by buckets with percentages. Ie, top 15%, bottom 10% and the rest (in the middle). Think of a few buckets where you can save money, increase revenue, avoid costs or protect the business.
- Plan the Sprint or replenishment meeting: The team then decides which user stories they will commit to completing in the next sprint or prioritize. This depends what framework you’re following. Generally, a quick but impactful discussion should happen where they know what the next week or two increment is.
- Review and Adapt: Run those experiments, those A/B tests, did customers give you any feedback or do you still need to ship way more stuff in order to get usability. If so, your tickets might be too big.
- Push quality code to prod often: Awaiting the quarterly release won’t cut it if you’re going to be releasing features often. If you’re a startup you need to push often in order to gather feedback from customers. If you’re a mid size / large company. Same rules should apply with a few more checks and balances. Check out what world class software delivery can potentially look like with DORA metrics.
By breaking down work in this way, teams can deliver value incrementally, make progress even if there are changes or uncertainties, and continuously learn and improve their process and be responsive to customers.
What is a feature flag?
What about feature flags? Are they features? A feature flag, also known as a feature toggle, is a technique in software development that allows developers (sometimes product owners) to enable or disable features in their software, even after the code has been deployed to production. Feature flags provide a way for developers to manage and control the visibility and availability of certain features in their application without having to change the codebase. Ie, I am going to turn on this feature flag for specific customers so they can see our new visa payment feature. Let’s see how it performs!
What are the pros of a feature flag?
Here are some reasons why a company might use feature flags:
- Canary Releases and A/B Testing: Feature flags allow developers to gradually roll out a feature to a small subset of users before making it available to everyone. This can be useful for testing how a new feature performs in the live environment. Ie, here’s a rollout strategy we’re going to do. I am going to use this feature flag to rollout to 20% of the customer base first.
- Trunk-Based Development: Feature flags can be used in trunk-based development where all developers work on a single branch (the “trunk”). Developers can merge their incomplete features into the trunk without affecting the functionality of the application, as the feature can be hidden behind a flag until it’s ready.
- Kill Switch: If a feature is causing problems in production, a feature flag can be used as a “kill switch” to turn off that feature without having to redeploy the application.
- Experimentation: Feature flags allow for experimentation in the production environment. Developers can test different variations of a feature to see which one performs better. I want to test this feature flag in an A/B test. Here’s my two layouts I’m going to serve customers.
- Operational Flags: These flags can be used to control operational aspects of a system’s behavior, such as circuit breakers or maintenance modes.
- Permissioning: Feature flags can be used to restrict access to certain features based on user roles or subscription levels. Ie, I only want subscribers to see this new feature so I can see if customer churn reduces.
What about the cons?
- Increased Complexity: Feature flags can add complexity to your codebase. Each flag represents a branch in your code, which can lead to more paths through your code and more potential states for your software to be in. This can make the code harder to understand and maintain.
- Technical Debt: If not managed properly, feature flags can accumulate over time and become a form of technical debt. Old flags that are no longer needed should be removed from the codebase to prevent this.
- Testing Challenges: Because feature flags create multiple paths through your code, they can also increase the amount of testing required. You may need to test each combination of flags to ensure there are no unexpected interactions.
- Inconsistent User Experience: If features are being toggled on and off, it can lead to an inconsistent user experience. Some users may get used to using a feature that is then turned off, or different users might have different experiences depending on which flags are enabled for them.
- Performance Impact: Depending on how they’re implemented, feature flags can potentially have a performance impact. If checking a feature flag requires a call to a database or an external service, it could slow down your application.
- Risk of Misuse: Feature flags can be powerful, but they can also be misused. For example, they might be used to push out features that haven’t been fully tested, on the assumption that the feature can just be turned off if a problem arises.
- Dependency Issues: If not managed carefully, feature flags can lead to dependencies where certain flags need to be enabled or disabled in a specific order. This can make managing your flags more complex.
- Must have an opt out strategy: Some individuals don’t want to be tested on so it should be clear that you are. You should also include an optout for your customers in case of any issues that arise.
To mitigate these potential downsides, it’s important to have a good strategy for managing your feature flags. This might include things like having a plan for removing old flags, using automated testing to catch problems, and monitoring the performance impact of your flags.
Closing
Creating features that customers love is a hard thing to do. It’s important to reduce feedback loops, decrease time to market and ship high quality code early and often. If you have the best features in the world but you can’t release due to various blockers, that becomes a problem and you cannot respond quickly enough to feedback. If you need assistance with incremental release and features, be sure to reach out to me.