If you do enough research on feature flags, you’ll see flags framed a lot of ways:
All of this is true! But there’s one thing that you won’t see talked about a lot, and we find it’s often the difference between teams that are able to use feature flags to truly unlock next-level velocity from those that find them useful, but not transformative.
That missing thing is seeing feature flags as a part of your software delivery team’s culture. Not just a tool, or an implementation detail. Feature flags are also a process and also a way your team works if you want to get the most out of them.
They can be useful as just another tool in your stack, but they will be gamechanging when you let them change the way your teams work.
First, let’s take a look at ways we’ve seen teams adopt and use feature flags:
If this looks like the state of feature flagging in your organization, you are not alone. And, there are parallels: if you’ve been in this industry a long time, you might remember that test automation, and later deployment automation, often lingered in this sort of patchwork place too before their eventual industry-wide ramp-up as a standard engineering practice.
To remedy the above situation, we have a few suggestions. To start, make sure everyone in your organization has access and knows what feature flags are. Invite your PMs, support team, sales engineers, and everyone in the eng org - including ops, DevOps, security, and anyone else.
Put together training sessions if awareness is low. What are feature flags? What are they for? What can they do? Make sure everyone in your software delivery organization can answer those questions.
Once you have people in the tool and they are at least notionally aware of the feature flagging concept, a big change for execution teams to make is flagging by default.
Oftentimes, teams wait until they find “the right use case” to get started with flags. Maybe you’re refactoring right now and so you don’t need flags, but once you do a new feature you’ll take a look. Or, maybe you have something already underway so you’ll look at flags next time. Or, maybe this feature is going to roll out to everyone, so it doesn’t need flags.
These are all the reasons we’ve heard why it’s hard to find the “right use case” to get started. That’s why we recommend not waiting for the right use case at all. Just add flags, now, to every change you’re making!
And while “every change” can sound like a lot, and obviously we can’t literally mean every single change, we do honestly mean most changes. Frontend, backend, APIs, user-facing, tech debt refactoring. You can put it all behind a flag. And, don’t worry whether or not you know what you’re going to use the flags for. You may not think you need the flag, but it’s an almost free level of optionality that you will very likely find you’re glad you have later.
If you’ve done a rollback or a hotfix in the last month, you had an opportunity to use a flag, because if that change was behind a flag, it could have been turned off instantly. If you’ve asked customers to give feedback on something recently, you had a chance to use a flag, because access could have been granted with a flag or new instructions sent to specific users via a flagged UI element.
Even in listing these scenarios, I want to be careful, because you may not think of wanting to do these things until right before a change is released. Or, even after it’s released. That’s why the right time to add a flag is now, even if it seems unnecessary. Because having the option later is always better.
At the start of the post, I said feature flags were a way of changing your engineering organization’s culture.What that boils down to is fundamentally separating the idea of a release from the idea of a deployment.
Just like CI permanently changed engineering culture (if you were here before CI) in terms of how teams managed quality and CD changed culture in terms of how teams coordinated releases, feature flags change how you think about risk and change management.
If you adopt feature flags as a core part of your software delivery mindset, you will find some subtle but important changes in how you plan releases:
Together, these add up to an engineering team that thinks about what releasing changes means, who does it, and what the risks are in very different, more collaborative, more learning-focused and less stressful ways. When all of that happens and feature flags have really become part of your culture, you will find they’ve gone from a nice to have to a core part of how you think about delivering software.
Ready to get started with feature flags? Why not start your free trial and play around with making your first flag? If you’re not ready, keep educating yourself! Read our piece How Feature Flags Help With Trunk-Based Development.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.