How Flagship Enriches the Lives of Tech Teams at AB Tasty

Guillaume Jacquart
December 30, 2020
7 min read
Flagship.ioFeature FlagsHow Flagship Enriches the Lives of Tech Teams at AB Tasty

We developed Flagship – our feature management tool – to provide tech teams with the capabilities to deliver frictionless customer experiences more effectively. Naturally, we also use Flagship at AB Tasty, but in the past, we also had to master our development cycles without the tool. 

In this article, I’d like to give you insight into how our tech teams’ work has changed due to Flagship. How did we work before? What has changed, and why do we appreciate the tool? Without further ado, let’s find out!

What a typical development cycle without Flagship looks like

The beginning of a typical development cycle is marked by a problem, or user need that we want to solve. We start with a discovery phase, during which we work towards a deep understanding of the situation and issues. This allows us to ideate possible solutions, which we then validate with a Proof of Concept (POC). For this, we usually implement a quick and dirty variant – the Minimum Viable Product (MVP) – which we then test with a canary deployment on one or two clients.

When the solution seems to be responding to customer needs as intended, we start iterating the MVP. We’re allocating more resources to the project to get it into a robust, secure, and user-friendly state. During this process, we alternate between developing, deploying, and testing until we feel confident enough to share the solution with our entire user base. This is when we usually learn how most of our users react to the solution and how it performs in a realistic environment.

The pitfalls of this approach, or: Why we developed Flagship

Let’s see why we weren’t happy with this strategy and decided to improve it. Here are some of the main weaknesses we discovered:

Unconvincing test results.

A canary release with one or two clients is great for getting first impressions but doesn’t provide a good representation of the solution’s impact on a larger user base. We lacked qualitative and quantitative test data and the ability to use it simply and purposefully. Manual trial and error slowed us down, and our iterations didn’t always produce satisfactory results that we could rely on.

Shaky feature management.

Developers were often nervous about new releases because they didn’t know how the feature would behave under a higher workload. When something went wrong in production, it was always incredibly stressful to go through our entire deployment cycle to disable the buggy code. And that’s just one example of why we needed a proper feature management solution. 

We see tech teams around the world know and fear the same difficulties. That’s why we created Flagship to help them – and us – innovate and deliver faster than ever before while reducing risks and headaches. 

I spoke to some of my tech teammates to determine how their work lives have changed since we started using Flagship. I noticed some major themes that I’d like to share with you now.

We know the impact of a new feature

Our product teams need to make a clear connection between a business KPI and a feature under test. In the past, we’ve fiddled with Google Analytics for a rough idea, but without distinct control and test groups for our experiments, we couldn’t know if our changes made a difference.

With Flagship, we no longer have to guess and can follow a scientific approach. We now know for sure whether a business KPI is positively impacted by the feature in question.  

Suppose we publish a new feature while the marketing team starts a campaign without us knowing about it. We may get abnormal test results such as increased traffic, engagement, and clicks because of this. The problem: how can we measure the real impact of our feature?

Flagship lets us define control groups to reduce this risk. And thanks to statistical modeling (Bayesian statistics), we get accurate data from which we can make a reliable interpretation.

The discovery phase lives and dies with qualitative information – but how can you get reliable data? Our answer is to conduct controlled experimentation and progressive deployments.

One time, we worked on a new version of one of our APIs and used Flagship for load testing. Fortunately, we found that the service crashed at some point as we gradually increased the number of users (the load). The problem wasn’t necessarily the feature itself. It had to do with changes in the environment, which can be easy to miss with traditional web testing strategies. However, we could stop the deployment immediately and prevent end-users or our SLAs with customers from being harmed by the API changes. Instead, we had the opportunity to further stabilize the API and then make it available to all users with confidence.

We iterate faster by decoupling code releases from feature deployments

We often deploy half-finished features into production – obviously, we wrap them in feature flags to manage their status and visibility. This technique allows us to iterate so much faster than before. We no longer have to wait for the feature to be presentable to do our first experiments and tests. Instead, we enjoy full flexibility and can define exactly when and with whom to test.

Additionally, we no longer have to laboriously find out who can see what in production during feature development, as we don’t have to integrate these things into our code anymore. Instead, we use the Decision API to connect features with Flagship’s admin interface through which we define and change the target groups at any time. 

What’s more, everyone in the team can theoretically use this interface and see how the new feature performs without involving us developers. This is a huge time saver and lets us focus on our actual tasks.

“Flagship helps me take back control of my own features. In my old job, I was asked to justify what I was doing in real-time, and I sometimes had trouble getting my own data in terms of CDP MOA, now I can get it.”

Julien Madiot, Technical Support Engineer

We can rely on secure deployments

Proper feature management has definitely changed how we work and how we feel about our work. And by managing our feature flags with Flagship, the whole process has become much easier for our large and diverse teams. 

EVERY feature has to be wrapped in a feature flag – this is possibly one of our most essential rules in development. But it pays off:

  1. They’re ON/OFF switches. Let’s not lie: we still make mistakes or overlook problems. But that’s not the end of the world. Especially not if our code is enclosed in a feature flag so that we can “turn it off” when things get hairy! With Flagship as our main base for feature management, we can do this instantly, without code deployments.
  2. They help us to conduct controlled experiments. We use feature flags and Flagship to securely perform tests and experiments in real-world conditions, aka in production. A developer or even a non-tech team member can easily define, change, and expand the test target groups in the Flagship dashboard. Thanks to this, we don’t have to code these changes or touch our codebase in any way!

They cut the stress of deployments. Sometimes we want to push code into production, but not yet for it to work its magic. This comes in handy when a feature is ready, but we’re waiting for the product owner’s final “Go!”. When the time comes, we can activate the feature in Flagship’s dashboard hassle-free.

DevOps engineers have many responsibilities when it comes to software delivery. Managing our feature flags with Flagship is an effective way to lift the burden off their shoulders:

I honestly sleep better since we started using Flagship with Flagship 🙂 Because I’m the one that puts things in production on Thursdays. When people say ‘Whoops, we accidentally pushed that into production,’ now I can say, ‘Yeah, but it’s flagged!’

Guillaume Jacquart, Technical Team Leader

Wrapping up

I hope you found the behind-the-scenes look at AB Tasty both interesting and informative. And yes, if there was any doubt, we actually use Flagship for Flagship feature development! This helps us improve the product and ensure that it serves its purpose as a valuable addition to modern tech teams. Would you like to find out how product teams at your company could benefit from our tool? I’d be happy if you decide to give Flagship a try! Follow this link to book a demo.

Info
Flagship Sign Up
About the author
Guillaume as Technical Team Leader at AB Tasty is responsible for leading the development team and align the deliverables with product and company vision. He's especially in charge of Flagship, AB Tasty's dedicated platform for feature flagging and continuous delivery.

You might also like...

Product Manager vs Product Owner: What’s the Difference?

This post highlights the differences between the roles of a product manager and a product owner and when you might need both.

Why You Should Slot Feature Flags into Your Agile Roadmap

One “beacon” that will keep your Agile product roadmap grounded, and your products moving in the right direction, is a simple function — the feature flag.

How Can Teams Use Feature Flags in Mobile App Deployment?

This article looks into how feature flags can help tackle the most common challenges with mobile app deployment with some real life examples.

crossmenu
Copy link
Powered by Social Snap