[neebz]

Yes. Feature flags changed the mindset of my whole team. I absolutely love the fact that it pushes the whole team towards release-small-release-often mentality. It's a technical solution with many benefits but I love the cultural impact the most.

[alunchbox]

We're currently in the transition, any chance you have some insights to help ease the mentality shift as the team transitions to this vs bi-weekly/monthly deployments.

[neebz]

Some feedback from our transition:

- automated tests are the pre-req of feature flags. kindly make sure that you have good test coverage. otherwise the team loses confidence in code & feature flags which defeats the whole purpose.

- as part of code review guidelines we added one major feedback item: can this PR be merged right now? why not? what can be done to merge it right away? as part of a cultural shift the code reviewers played a critical role. they kept engineers on the their toes at all times.

- feature flags should be part of user stories. in many cases you can't expect engineers to add a feature flag at the end of implementation. the product team should know this at the time of writing user stories.

- as mentioned in many other comments try to clean up code after feature flags become stale. otherwise the code (and respective automated test cases) becomes a huge mess.

- in our case we decided the granularity of feature flags (per-user, per-customer, per-region, per-server etc). we started with per-customer and went from there. worked out fine for us.

- feature flags have major two benefits: "release often, release small" & "decouple releases with big launches". please make sure to instill this in your team every day. mindset changes takes repetition and emphasis. if at anytime you feel that you are not achieving any of these please take a step back and figure out why.