At first glance, this title might evoke images of the proverbial tail wagging the dog. Feature toggles, at their core, are "if" statements tied to runtime configurable settings. So am I asking how you adjust your development process to use "if" statements in your code? No, I'm not doing that. What I am doing is suggesting that using feature toggles requires more than just code changes. It requires changes in philosophy and approach as well. To illustrate, let me draw a parallel. The agile manifesto and the movement it inspired took the world by storm. Suddenly, doing software well meant going agile. So what did companies do? Well, they went agile. One of the big draws of agile, especially for leadership, came from a faster shipping cadence. Ship software every few weeks? Get feedback much faster? Beat competitors to market? Yes, please! But companies didn't just accomplish this by saying to the software teams, "alright, start doing TDD, CI, and all of the XP practices." Shipping software every two weeks instead of every six months required the entire organization to modify its approach, and not just granular technical adjustments. Everything around requirements specification, quality assurance, and the deployment/release process had to change as well. It's this kind of thinking that also needs to happen with feature toggles. Sure, developers can slap "if" statements into the code, but there's a lot more to it than that.
With Modern Software, All Roads Point to Cross-Discipline Approaches
I touched on agile as a parallel for what needs to happen with feature toggles. And I'd like to touch on it again, along with some other things, in a slightly different context.
The agile movement, at its core, was about facilitating collaboration between software developers and representatives of "the business" (e.g. product developers).
DevOps aims to break down barriers between software developers and folks in operations.
Growth hacking fuses the technical with an emphasis on marketing and, well, growth.
Automated testing approaches blur the lines between traditional and current quality assurance (QA) approaches.
Noticing a pattern? Over the last 15 years, companies of all shapes and sizes have realized significant improvement in their software delivery by breaking down traditional organizational silos and being more cross-discipline. The results have been indisputable. But doing this places a burden on you to modify the software development process. Cross-discipline and "throw a binder full of specs at the software developers" aren't compatible. A cohesive, cross-disciplined team has more roles and new rules of engagement. For feature toggles, you're going to need to establish some norms among the disciplines, particularly combing product-management-focused people with the DevOps part of the house.
Define Feature Toggles vs. Configurable Capabilities
The first thing that I'd suggest is to establish some definition precision. As you go, this will help you avoid spats over turf and miscommunication. Consider that you could have a bit of dissonance over the definition of a feature toggle (emphasis below is mine):
A feature toggle is a piece of code that allows runtime configuration of the software.
A feature toggle is a setting that lets you turn features on or off.
At a quick read, you might think that these definitions are more or less the same. But consider the emphasis, and ask yourself who might describe them each way. My point is that both a product manager and a software developer might lay "claim" to the feature using subtly different language. To avoid that, I would suggest that you establish different terms for each thing.
A feature toggle is the nuts and bolts, technical implementation of enabling or disabling parts of the software at runtime.
A configurable capability, on the other hand, is the idea of turning features and business value on or off in the software.
The specific names you use aren't as important as the fact of differentiating between them.
Development Process Ground Rules: The What vs. The How
With some terminology in place, establish an important ground rule. A cross-discipline approach works both by finding poly-skilled people and by having people with different skill sets work in close proximity. For instance, with DevOps, you might hire some people that have both traditional development and traditional operations experience. You might also simply form a team that consists of staff plucked from the development and operations groups. As you hammer out your approach to feature toggles, you're going to be asking people to collaborate more tightly across the disciplines of product development and DevOps. When you do that, it's easy to think that tighter collaboration means "everyone gets in everyone else's business." Don't fall into that trap because that's a recipe for constant bickering and frustration. Tight collaboration doesn't mean completely doing away with specialties and areas of responsibility -- it just means more frequent interaction among them. So establish ground rules right off the bat. The product folks determine the configurable capabilities -- the "what." For instance, they might determine that the subscription model requires the ability to turn off administrative functions for arbitrary users. The technical people then determine the "how." In that same scenario, they might decide to achieve the "how" with a database setting or with a local config file. Can each discipline offer opinions to the other? Sure, of course. But each should ultimately have its own purview to avoid mutual micromanagement.
Product Management Checks In and Spends More Time with Dev
Let's now expand on this a bit. What do product management's responsibilities look like at the intersection of this world? Well, you obviously have traditional product management responsibilities:
Turning market data and research into feature roadmaps.
Setting pricing and subscription models.
Serve as champion/CEO of their products/product lines.
But in a world where you're adopting feature toggles, things get more intense in some respects. Specifically, market research becomes more interactive, and it starts to happen in real time, through the actual product. This is powerful, but it requires frequent interaction with technical staff. Get used to the following.
From initial conception of features, you need to think immediately about what you'll need to configure at runtime.
Get used to thinking of the software as a collection of configurable capabilities to help you with market research.
Sync up regularly with the technical staff about what toggle options you currently have and which are coming.
Work with the technical folks to keep careful tabs on all the data you need.
Developers Adopt a New Technical Approach and Mindset
For developers, the changes in how you do things are a bit more familiar. After all, this isn't software developers' first rodeo with increased cross-discipline collaboration, as I mentioned earlier. So in terms of incorporating feedback, this is just another version of that, such as working with operations to make the software easier to manage in production. For software developers, most of the difference will come in how they look at the software. Looking at it as a configurable array of experiments is going to be new and a little weird. Here's what they'll need to do.
Learn to put increased emphasis on designs/architectures that promote modularity.
Home-rolled feature toggles will get unwieldy in a hurry, so make sure you get feature toggle management software quickly.
Understand that treating your product as market research means that a feature isn't done until you've proved that it makes the business money. Prepare yourself that the thing you've just built may get scrapped.
This will all get easier if you understand the business and its research better, so pay attention to the product people when they explain the rationale for different features, capabilities, and experiments.
Make sure that you're furnishing the business in general with the data and information it needs regarding those experiments.
Do your best to hand the keys to the toggles over to the product manager.
Work Toward Product Folks Having the Production Controls
On the note of that last bullet point, I'll close by answering perhaps the most important question you might have about adjusting your development process for feature toggles. Who is responsible for flipping the switches and turning features on or off? Why, the product people, of course. I know what you're probably thinking at this point. During this entire post, I've referenced the trend toward cross-discipline approaches to software products. Why do I now create a silo? Well, I'd argue that I don't. Anyone with the requisite knowledge and organizational authority could and probably should be a product person, at least to an extent. At really small organizations where people wear many hats, you can't avoid this, but even in larger, more specialized shops, you may have someone that writes code and also serves in a product management capacity. Great! By all means, let that person control the feature toggles. But they're doing so not as a software developer, but as a product person. And that's critical. The beauty of a modular system making use of feature toggles and of a mature development process is that the people with the most information can make quick and expert decisions.