Feature Injection Clarified (Hopefully)

Feature Injection is a very helpful process framework created by Chris Matts that is not explicitly used as much as it probably should.

I suspect the main reason it is not adopted more is because people don’t really understand what it’s all about. There are several articles and blog posts that explain feature injection, but for whatever reason many practitioners don’t find them easy to understand.  Examples of some of those references include:

• The InfoQ Article Feature Injection: three steps to success by Chris Matts, and Gojko Adzic which tends to be the most referenced article.
• Chris’ 2009 Real Options Comic Books which includes quite a bit about Feature Injection that he distributed at Agile 2009. I’m proud to admit that my acreage was the inspiration for the setting in the comic books.
• Liz Keogh’s blog Post BDD in the Large  which describes Feature Injection in relation to Deliberate Discovery, Real Options, and BDD. I admit I personally get a little wrapped around the axle with the six layer hierachy, but that’s probably more a reflection on my perspective on hierarchies than Liz’s description.
• Jesus Gil Hernandez’s post Feature Injection: From Outputs to Inputs does a good job of describing the idea of working from output to input which is a key aspect of feature injection in how it relates to the use of traditional business analysis techniques..

If you have not read these yet, I encourage you to give them a shot. You may find that they make perfect sense to you. If not, here’s my attempt at providing a more useful explanation.

Feature Injection is based on understanding the value an initiative intends to deliver, delivering the features that provide that value, and building a shared understanding about those features primarily through examples.

Let’s look a little closer at the three key ideas.

• Identify the value
• Inject the features
• Spot the examples

Identify the Value

Feature injection begins by creating understanding about the business value an initiative is trying to deliver (in other words, why are we doing it in the first place). In a for profit organization, an initiative delivers business value when it increases or protects revenue or reduces or avoids cost in alignment with organizational strategy. In a more general sense, I like to gauge the business value of an initiative based on whether it helps an organization meet one or more of it’s objectives.

For example, let’s say you are working at a health insurance company facing the prospect an increased claim volume but they would prefer to not add staff too soon.  One area they feel would help them process more claims with the same staff is in the claims intake – they still receive a considerable number of paper claims which have to be entered in to the claim processing system.  With that in mind, the health insurance company establishes an objective:

Reduce the number of paper claims received from 1000 per week to 500 per week within six months.

Once you understand the objective you can identify a solution you think will meet that objective, and identify the assumptions that underlie your belief that solution is the right one.

To continue our health insurance example:

Building and hosting a website where single provider offices can submit their claims will help us reduce our paper claims.

Assumptions:

– Most of our paper claims come from single provider offices

– Most single provider offices have internet access

– Most single provider offices do not have medical billing systems

– If we build a website, our single provider offices will use it.

Inject the features

Once you understand the value you are trying to deliver, and the assumptions that impact that value, you can use that information to guide what you do next. You want to select chunks of value (which I will call features ) that allow you to make progress toward meeting the targeted objectives or help validate assumptions. Which aspect you focus on first will depend on how far along you are in the initiative. At the start, you will most likely spend more effort on validating assumptions (you can also think of this as reducing uncertainty) and follow up with delivering features that you know will deliver the value you seek.

This is where analysis techniques and the idea of working from output to input come into play, especially those representing displays of information or reports that stakeholders are looking for in order to answer some questions or make some decisions or support a broader process.

Once you understand the outputs, you can work backward to figure out what processes are needed to produce those outputs (including the rules that act in those processes) and the inputs needed to create the outputs. You are effectively performing analysis in the opposite direction of development, which tends to bring in the inputs of a system first, then build the process, and finally create the outputs. Said another way: because you are pulling value from the system via the outputs, you leave a hole at the beginning of the system into which features are injected. That’s how the name feature injection is derived; as we pull business value from the system, we inject the features that create that value.

For our health insurance example, the team would probably first undertake some actions to validate the key assumptions mentioned above. If those assumptions prove correct, the team can then model out what the online claims system would look like (rough wireframes should be sufficient) and start iteratively building the system, collecting feedback and frequent increments throughout the process.

The key point here is that you identify value first, then iteratively identify the features that you need to deliver it. Don’t brainstorm a big list of possible changes and try to figure out what each feature could contribute to business value, focus only on those features that directly lead to satisfying your objective.

Spot the Examples

We typically use models to describe the outputs and processes and the inputs used to create them. These models are helpful for creating shared understanding with everyone involved in delivering the features, but they are rarely sufficient. One way to make the overall understanding of a model clearer is to add examples. Examples serve two purposes: First, they provide concrete guidance in very specific situations to people who tend to ask “Yes, but what about this situation?” And second, examples give the team a way to test the models and make sure they account for different situations that may occur.

The thought process surrounding feature injection is a huge influence on how I approach all projects, and while I very rarely mention the name to the teams I’m working with, I’ll often introduce the ideas. Most of the people I talk to say things like, “Yes, that makes a lot of sense. Why didn’t we do that before?” or, “Yeah, we do that, with these few tweaks.” Starting with the value you want to deliver, using that value to decide what feature to build next, and describing that feature through the use of real life examples, proves to be a simple, effective way to build the right thing, and not build things that aren’t necessary.