What If I Can Only Deploy Every 2 Weeks?

Creating a culture of shipping is going to be a problem if your company only allows for a single, coordinated deployment ever N number of weeks. If that's the case, I would suggest taking time to understand where that constraint is coming from. It might be fear-based. But, it might be part of a contract; or, part of some security and compliance requirement.

If the constraint is fear-based, you have some wiggle room. You have an opportunity to demonstrate that building products with feature flags—and working small and shipping more often—is actually safer. This won't be an easy argument to make, given the context; but, if you're reading this book, I suspect that you're the right type of person to lead this effort.

Perhaps you can start by getting permission to experiment with work that is outside of the main product-suite. Or, perhaps you can apply this approach to internal dashboards where bugs aren't considered a mission critical issue.

If you can get your foot in the door somehow, and start pulling stakeholders into the product conversation, I know that people will see the value.

But, I acknowledge that this is an uphill battle. And, I wish that I had better advice to offer. I'm sorry that I don't.

With that said, even when infrequent deployments are an organizational constraint, feature flags still add value. Being able to dynamically change runtime behavior still creates a safer development environment and unlocks certain use cases.

Without frequent deployments, you'll never get all of the value that feature flags provide. But, you will get some value; and, if there's any message that you should take away from this book, it's that some value is always better than nothing.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4567