We'll respond shortly.
There are often times when you’re building a feature, and have broken it into smaller user stories. But this new feature won’t be completed for a month, and you’re releasing into production every week. You can’t break the continuous integration build cycle, but you also can’t release an unfinished feature.
In the old days, you would:
This process is dangerous for a couple reasons:
Simple in nature, feature flagging means to wrap logic code around certain pieces of code that aren’t ready for prime time. The code goes out to production, but the code logic ensures that it isn’t shown.
As a PM, your goal is to always be receiving feedback from users. Hiding a feature too long can prevent that feedback. Martin Fowler (of all sorts of fame), writes in a post:
“Your first choice should be to break the feature down so you can safely introduce parts of the feature into the product. The advantages of doing this are the same ones as any strategy based on small, frequent releases. You reduce the risk of things going wrong and you get valuable feedback on how users actually use the feature that will improve the enhancements you make later.”
Feature flagging isn’t just for half-completed features, you can enable this for beta programs as well. A specific set of users can see your new features, or you can have it set to be enabled randomly for A/B testing. Don’t forget to include metrics tracking or you won’t know which is better. For an example of taking things a bit too far, see Graham Siener’s post on using feature-flipping for tracking user interest. They played around a bit with RollOut, an open-source framework to jumpstart flagging.