Do we really have to create new labels?

A recent experience I had made me wonder why we come up with new labels for things and what we hope to accomplish with them.  In this case, it was the idea that Chris Matts originally came up with and calls Feature Injection.  What it really means is to focus analysis efforts in the opposite direction of how development usually goes.
Development typically works in this order:

Input -> Process -> Output -> Value

But analysis should work backwards so that we focus on the key aspects.  In other words, do analysis this way:

Value -> Output -> Process -> Input

There are several people who have made attempts to explain how feature injection works, the most common and current description is this:

Value -> Goals -> Capabilities -> Features -> Scenarios -> Stories -> Code

That was described by Liz Keogh.  This is a very elegant description (although I differ a bit in the perspective of what she meant by goals.  What she described as goals, I would refer to as constraints.)

This description is great conceptually, but I suspect people may still have trouble applying it.  Take the team I was working with when I thought of the most recent application of Feature Injection.  Had I said “Oh, well what you have to do is apply feature injection, where you start with the value and work backward, working through goals (regardless of how you define a slightly less obscure concept than value) I would have lost them.

What really helped me was the fact that I actually understood why you start with Value first, and described it in terms of their project.  After I spent a couple of minutes explaining it (without, by the way using the words feature or injection in that order) they had the look on their face like “well duh.  Why didn’t I think of that?”  In fact I had a couple of people come up to me during one of the breaks in the discussion and ask  “Should we have known to approach analysis this way?”

Now I get we need labels to identify things, but I think labels can often get in the way (Product Owner, Scrum Master, Waterfall, Scrum, Agile, Lean, Kanban, TDD, BDD, Pair Programming, DevOps, Continuous Deployment, Continuous Integration) especially if those labels don’t accurately describe the concept they have been attached to.  Product Owner, Scrum Master, and yes, Feature Injection may be some of those labels.  To go along with the current craze to have things driven by something, Feature Injection may be better named “Value Driven Development” but I suspect that the abbreviation may remind too many people of something that gets transmitted when you are having an awfully personal encounter with someone you probably should be.  Perhaps Value Driven Analysis may be even better.

For what it’s worth, Gojko Advzic recently refreshed my memory on Chris’ reasoning for the name in the first place. It was a take off on the name dependency injection.   I can’t remember the parallel that Chris drew between letting value drive analysis (and development) and giving an object it’s instance variables.  Considering many of the people we would want to discuss Feature Injection with have never heard of dependency injection, it’s probably as about as meaningful as calling an agile development framework after a type of play in a sport that may not be familiar to a large part of the audience.

My new challenge is to be able to explain things without having to give a name to it.  Kind of like coaching charades.  Damn, did I just coin a new term?