If you’re in software engineering or software development, this dialogue may sound familiar to you when talking about feature flags:

“I want my teams using trunk-based development with short-lived branches and constant merges, and feature flags around all changes are going to be key to making that happen. So, we bought a feature flag management tool, gave everyone access, and…why isn’t it happening?”

Don’t worry if this sounds familiar. When it comes to feature flags and new ways of developing code like trunk-based development, the goal is often much clearer than the process to get there. You may have the tools, but you also have tons of engineers doing important work every day, and getting people to slow down and adopt new methods can be a challenging task.

There is no one magic answer to this question. But, there is one approach we always recommend. It’s so simple that it sounds like we’re joking – but we promise it works. It’s a two-step process:

Step 1: Find a team

Step 2: Add a flag!

Done! And, we’re not joking. Let’s dig in.

Find A Team

One of the biggest challenges in crossing the chasm from wanting these great, modern dev practices to actually having them is, determining who goes first. We recommend finding a team, or even an individual developer, who’s willing to spearhead the adoption of your feature flags tool. Here are some pointers that may help you know where to look:

• A front-end flag is probably easier to implement than the back-end (if there’s no other organizational preference).
• Try to find a team that is currently shipping something. Greenfield projects are great, but they can actually make new practices and good habits slower to diffuse than starting with software that’s actively used.
• You don’t need to find a huge initiative kicking off — anybody who’s willing to read the docs and jump in will do. More on that below!

The above approach works because feature flags, unlike a lot of DevOps tools, don’t necessarily need to be centrally coordinated and planned initially. Anyone can wrap code in a flag and find them useful.

While over time you will absolutely want standardization and governance, in the early days, just having momentum is key. The blast radius for those teams not using flags yet is non-existent, so it’s safe to let some teams start new processes with tools that won’t affect other developers.

Add A Flag

Once you’ve found a team willing to help by leading the way, the next step is to just add a flag!

While that sounds deceivingly easy, the reality is that the internal momentum needed to start doing new things means that just adding a flag can in fact be very difficult. But, here’s a helpful way to look at it: you don’t need to know what you’re going to do with the flag. In fact, the flag doesn’t even have to do much of anything. 

Whether you use the flag for specific targeting, progressive delivery, or just enable it for all users right away, the hardest obstacle to overcome is often just getting started. Sometimes, teams spend time trying to figure out what is the perfect first scenario for using flags based on the development calendar’s next big initiative, but effective change comes with practice, not all at once. The sooner you have any flag in your code, protecting any change, the closer you are getting to your goal.

Some great first steps we’ve seen from our customers include::

• Grab any bug pending a fix and ask the engineer to create a flag around it. Globally enable the flag, so there’s no new custom release or targeting needed, and then observe what it looks like to have a flag in the system as it goes through your environments.
• Circle back on your next release, and add a flag around any change – major or minor – just to get the experience of using a flag to toggle something. Just because a feature is almost done, doesn’t mean you can’t add a flag. 
• Add some backend logging behind a flag, just confirming the flag is changing, and send it through your promotion cycle.

We find that as soon as teams can sit around a screen and see a flag in practice, a lot of the next steps start falling together quickly. With a real flag to work on, teams are able to start quickly leveraging flags more and more. The next step in the process typically focuses on answering questions like:

• What would we need to do to target in this way? 
• How would we control who can change this? 
• How would we want to test a flag on QA?

Having these types of discussions can be done prior to any flag being in place. However, they can be so much more productive when you have a flag in the application that you can toggle to review as a team, creating an actionable feedback loop to help drive next steps.

Start Your Feature Flags Journey Today 

Changing how your dev team works can’t (and shouldn’t) happen overnight. Teams can overthink the problem of how we get where we want to go by trying to make big line-in-the-sand changes. Often, baby steps create the momentum that gets you there – and with feature flags, there’s no better first step than simply adding a flag and playing around with it. Even if it’s in production, that’s the point of flags – it’s risk-free!

‍Harness Feature Flags natively integrates CI/CD and feature flags to create a unique and powerful unified software delivery experience with end-to-end governance, visibility, and control from build to deploy to release. If you’re wondering how to start using feature flags or want to start implementing them right away, you can sign up for Harness Feature Flags for free and start using them with your team today!