Feature Flag

You are a Developer on a team at a small-sized company that uses aerial drones to map golf courses. The company’s latest project is a highly anticipated web application that promises to redefine your market offerings. Soon, by applying footage that was previously only used for promotional marketing, the company will also allow customers to better understand existing and potential landscaping concerns. The team consists of a Scrum Master, a Product Owner, several Developers, QA engineers, and a UX designer. The company leadership is invested in seeing consistent progress, and they rely on the Scrum Master and Product Owner to keep them informed.

The sprint started a week ago, and you’ve been assigned to work on a critical feature for the new web application. Your task is to integrate an API service that provides weather forecasts. This service, provided by a third-party company, is supposed to be connected to your app so that users can see upcoming weather events and receive explanations for how that weather could impact their landscaping conditions.

However, this task is proving to be more complex than anyone initially expected. The service you’re trying to connect to has its quirks—its documentation is incomplete, and it occasionally sends back confusing data. You’ve spent hours figuring out how to properly interpret and use this data, making sure that your app can understand it and show it correctly to users.

While working on this, you discover that the way some older parts of your app were built is causing problems. Imagine these older parts are like an old house’s wiring that’s not up to code anymore—it still works, but it’s risky and could cause bigger issues down the road. So, you decide to take some time to fix this “wiring” (refactoring the old code) to prevent future bugs and crashes. This isn’t something that was originally planned for this sprint, but you know it’s important.

As the days pass, you make significant progress. You’ve cleaned up the old code, and the connection to the weather data service is almost working—although it’s not quite ready for users to see. You’ve been running tests and everything is looking good from a technical perspective, but because the feature isn’t fully finished, it’s hidden behind a “feature flag.” This means that while the work exists in the app, no one outside of the development team can see it yet.

The challenge you face now is that, even though you’ve accomplished a lot, there isn’t anything tangible that you can show to the Product Owner or leadership. They’re looking for visible results—something that users can interact with and that moves the project closer to launch. The improvements you’ve made are critical, but they’re behind the scenes. To someone not involved in the coding, it might look like you’ve spent a lot of time but delivering them nothing.

The API integration isn’t fully functional yet; it’s still behind the feature flag and hidden from the Product Owner’s view. The refactoring work you’ve done has improved the code quality but doesn’t have any immediately visible impact on the user experience.

During the Sprint Review, your team gathers to demonstrate their progress. Other Developers showcase new UI components, fresh UX designs, and working features that the Product Owner can interact with. When it’s your turn, you describe the complexity of the API integration and explain the refactoring work you’ve completed.

The Product Owner looks confused and asks, “So, what can I see? How does this affect our users?” You explain that the changes are more about laying a solid foundation for future development, ensuring that things run smoothly later on.

The Scrum Master nods, understanding the technical side, but you notice a frown from the Product Owner. The leadership, who is also attending, appears disinterested, asking about the tangible results and customer-facing progress. You feel like you’ve done important work, but it’s clear they’re not seeing it the same way.

After the review, the Scrum Master pulls you aside. “I know you’re working hard, but we need to find a way to better demonstrate your progress. The Product Owner and leadership want to see things they can measure and understand. Or, basically just be able to sell.”

You leave the meeting feeling frustrated. You’re contributing valuable work, but it feels like no one else appreciates it. You start to wonder… Is there a problem with how you’re communicating your progress, or is the team not understanding the technical complexities involved?

What is your decision?

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.