Earlier today I listened to Liz Keogh describe Feature Injection and state that “Feature Injection is a useful model but it does not work in practice”. The Feature Injection Liz describes is nothing like the Feature Injection tools I work with. The one Liz describes is a way of breaking down projects.
To differentiate them, from now one, I’ll refer to the one I use as “Value Mapping”**. I will also describe how you can use it relating to the Cynefin framework.
The key differentiator in Cynefin is between outcomes that are certain and outcomes that can only be known in retrospect.
If you are dealing with a product where the user has choice as to whether they use it, you are almost certainly in the complex or chaotic quadrant. In complex, you need multiple safe to fail experiments. Feature Injection Value Mapping can help by forcing you to look at the value to the user and the organisation. Once the value is better understood, you can identify a number of options (hypotheses) to deliver that value (Those multiple safe to fail experiments). You can then use feature injection Value Mapping to identify the dependencies needed to deliver the value and the options to deliver them. Value Mapping in this usage is very similar to Impact Mapping.
If you are dealing with a product where the user has no choice to whether they use it, you are probably in the complicated quadrant where enterprise software hangs out. You can use feature injection Value Mapping to help the user find the value and then get them to draw the output they need from the system to deliver the value. You can then use Feature Injection Value Mapping to identify the delivery options. One extra point, in enterprise software land you often do not want to specify the user group in advance.
From experience (been using it for a decade now), people on projects tend to zoom in on complicated problems like clever maths and stuff. Value Mapping is great for quickly surfacing complex issues such as necessary changes to business practices. Complicated problems are much easier to risk manage than complex ones… you just need to do analysis or find the right expert.
** A name that Dan North came up with.
The IT Risk Manager 
July 6th, 2014 at 11:53 pm
Hey Chris, my most sincere apologies if I’ve given the impression that Feature Injection is only about the breakdown of the project. A more accurate description would be that “misusing it in this obviously terrible way” doesn’t work in practice.
This is the same model you taught me years back, and because I had been doing Agile for a while, I never expected that people would treat it like Waterfall (yes, I am a naive idealist). Of course you don’t break everything down; you use it to find the experiment with the most valuable discovery (or, as you put it, “hunt the value”). The whole of the last part of my talk is about that (from 19:40 onwards). But that way of using it is *also* part of Feature Injection for me. If I haven’t made that clear please forgive me and let me know what I can do to help clarify your part in that bit.
These days I’m using the model in complete conjunction with Cynefin. My LKUK talk is probably a better exposition than the webinar (I hate webinars): https://www.youtube.com/watch?v=G2X_7ojZwtU
Here are the learning outcomes from the course I ran for a client this week (included a bit of Pair-Programming workshop for contextual reasons: https://twitter.com/lunivore/status/485106634839298048 – F.I. is short for Feature Injection) – interested in your feedback.
However, given I’m also mixing the language of “capabilities” into it these days (rather than the “themes” or “feature sets” you taught me), and some BDD as well, and have no doubt diverged horribly because I’ve not hung out with you half enough, maybe it is time for me to give a different name to what I’m doing. If you’re happy for me to do that, I’ll try to think of one / find out what the best Cynefin-guided way of naming stuff is (I’m pretty sure it’s not asking Dan). Would also love to meet up and look at where we’ve diverged and where we’re still the same.
Thank you for your part in teaching many wonderful things I’ve learnt and helping me be aware of many things that I know I don’t know.
July 7th, 2014 at 9:00 am
Hi Liz
No problem. I just wanted to call out that what you were talking about is not the same as the stuff I do.
A capability is an option for an organisation. Its been a long while since I talked about themes or feature sets, I certainly would not advocate it now. The whole naming of things is something I try to avoid these days.
Let me know when you want to meet up.
Chris
July 7th, 2014 at 10:31 am
I find names valuable just as an anchor for the body of knowledge that surrounds them. I hope that any interest I’ve generated in Feature Injection has resulted in more people being led to your work, even if my approach isn’t the same (and I do usually call out that this is the case!)
July 7th, 2014 at 6:47 am
In my current interpretation of Cynefin the Complex domain would place you in a situation where you can’t determine the value to the user, it can only be discovered in retrospect through multiple safe-to-fail experiments and where phenomenon like serendipitous discovery and exaptation come much more to the fore.
July 7th, 2014 at 8:51 am
Hi Anthony
This is my current understanding. I am still learning as well. 🙂
Complex and Choas are unknowable. The outcome can only be understood in retrospect.
In Chaos, you do not have enough of an understanding to do anything and so you simply act to stimulate the system. Then you sense and respond.
In Complex, there are enough constraints for an outcome to emerge. It may be beneficial or otherwise. If beneficial, give it more energy. If not, dampen it. You cannot determine the value to the user. However, you can create a hypothesis that the thing you create will be valuable to a user. Value discovery does not require multiple safe to fail experiments, however doing many can be more effective. Your experiments can be deliberate and Dave encourages oblique discovery.
You can create an environment where serendipitous discovery is more likely but I would not have it as the dominant approach to moving problems from Complex to Complicated. Instead I would want an organisation with enough agility to respond to serendipity and exaptation by the customer, and an openness to exaptation. (Zen and the Art of Motorcycle maintenance has a classic exaptation anti-pattern)
Are we aligned, or am I still missing you?
Chris
July 7th, 2014 at 10:29 am
For me, the goals are proven, but the core (differentiating) capabilities we’re delivering are an experiment (and the features which implement those capabilities even more experimental than that!) So I think this is aligned.
July 9th, 2014 at 6:27 pm
What’s a capability?
July 9th, 2014 at 6:27 pm
Serious question! I’ve never found a definition that’s helpful and I’d love one!