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?
Even Chris says it’s a terrible name! It was called that because you inject features into a project because you need them, in the same way that you inject dependencies into a class – not because they’re available, but just because they’re required. Being a fairly naive dev I jumped all over it and spread the term, and now it’s too late. Sorry Chris!
I think labels are important, if only as anchors so that you can go look things up. I spend quite a lot of time teaching Agile, and even though I rarely use the term while teaching, I let people know it’s there so that they can go and find more information later. Same thing with Feature Injection, BDD, etc.
I really like the term “coaching charades”. I’ll remember that one. One day it will be a label too.
Another example of a label that has outlived its usefulness, “user story”. See the post and subsequent discussions on Alister Scott’s Blog (http://watirmelon.com/2012/10/17/where-is-the-story-in-user-stories/)
LIz, I think you hit the nail on the head with the use of labels. They are handy tags for concepts to go look up more information about something.
I think you have the right idea about helping people learn about the concept first and then mentioning, almost as if in passing, “oh and by the way, that’s often referred to as ….”