I have started to feel comfortable enough about our BDD
practice to begin presenting on the techniques. Liz Keogh came to my last
presentation at London .Net Developers Group and suggested that I needed to
look at Feature
Injection as part of BDD practice now. Chris Matt’s comics are a good
starting point for Feature Injection.
I’ve not tried Feature Injection, but think its definitely worth a look for
anyone using BDD. I’m keen to get a better understanding of how it might modify
our ‘today’ practice. This is just really some early notes on what I know now.
Liz Keogh has a useful article on how sees the overall process of BDD when
using Feature Injection over at InfoQ. The shift in
how user stories are phrased seems to be one key to understanding this.
Business Value is now being recognized as a key driver for why we are
delivering a piece of work. So we re-phrase the classic Role-Goal-Motivation
User Story as:
As a <role>
I want to <goal>
So that <motivation>
In order to <achieve some outcome which
contributes to the vision>
As a <stakeholder>
I want <some other stakeholder> <to do, use or be restricted by
Liz calls these stakeholder stories to emphasize the difference from user stories.
Distilling the Vision
Notice how the outcome, the reference to the vision, why are we building
this software now comes first over the goal. We emphasize that it is not enough
to say what, but also to say why. How does this story help us meet the vision?
When I talk about BDD I often shorthand it as “Build the right
software” in comparison to TDD which helps us “Build the software
right”. Feature Injection seems to take this process one step further by
saying that it is not enough to restrict the developers to only building
software that satisfies a specification, but also to ensure that those
specifications are authored only for those stories that deliver on the vision.
So where does the vision come from? In DDD terms the Vision results from the Distillation
process. Identify the core domain and produce a Core Domain Vision statement.
So the technique of Feature Injection reinforces DDD’s Distillation technique.
Both Liz’s article and Chris Matt’s comics identify some standard techniques
for helping to distil what is core domain from what is not. Given that vision
the stakeholders then work to identify the broad features of what need to be
delivered. User stories come from decomposing these features.
Our software lifecycle tends to begin with Iteration -1 in which the Big
Plan, how we think we might build some software to satisfy a Vision is taken to
sponsors. At that point we have only the results of Distillation (what DDD
calls a Distillation document) and enough understanding of the Feature Set we
need to provide a rough costing (folks want to know the order of the costs to
understand whether the business value justifies the cost – software is an
economic proposition). We then move to Iteration 0 or project Chartering, where
we might capture initial stories and produce what Crystal calls an Exploratory
What I like most about Feature Injection at first reading is this
explicitness with which it highlights what happens in Iteration -1 and
Iteration 0. These are no longer ‘locked in the attic’ in agile process terms,
but brought to the fore as a vital part of the methodology. I have come across
too many teams that have no idea about Iteration -1 or Iteration 0, push
straight into Iteration 1 and build the wrong thing. So any process that
highlights the need for this to occur gets a thumbs up from me.
What is Business Value?
If we are suggesting that our focus is on business value, how do we assess
value? Chris Matt’s admonition to focus on delivering business value over
features is something about Feature Injection that I really warm to, as again
and again we try to point to the fact that the most important metric for us is
business value. In particular Feature Injection suggests ‘popping the why
stack’ until you can arrive at a definition of business value that meets Andy
Poll’s advice that ‘A project creates business value when it increases or
protects revenue, or reduces costs in alignment with the strategy of the
organization’. That’s pith because it not only identifies revenue or cost as
the driver, but alignment with business strategy. For Chris, the place to look
for business value is in the outputs of the system. It is the outputs that you
can measure for business value. So once we identify an output, we ‘pop the
stack’ to find its business value.
Whither Use Cases?
Of late I have been wondering about the correspondence between examples and
use cases and questioning whether as we emphasize modelling from examples that
use cases did not have it right all along. So it is interesting in Liz’s
article to pick up on the same question from Eric Evans, and respond that
“You can’t ask a business person for a use case unless they’re already
technical enough to know what a use case is. But you can ask them for an
example”. That implies that they are two different approaches to the same
goal, but the user is placed in the driving seat with examples. It’s a good
explanation of the difference.
Intersection with DDD
Interestingly enough at Domain Driven Design Exchange, Gojko Adzic presented
on the intersection of BDD and DDD and feature injection was at the heart of
how he saw the two corresponding. You can see Gojko’s presentation here.
Gojko’s main assertion, as I understand it, is that having used Distillation (figuring
out what is Core Domain where you
expend modelling effort, as opposed a Supporting Domain, where you don’t) to
decide what to build we hold Specification
Workshop to drive out the scope using Feature Injection. We then model
using to the scenarios outlined for the stories to create a Ubiquitous Language. At
the same time Eric Evans spoke about his perspective on Agile and DDD, looking
at DDD’s need to produce a Ubiquitous Language and asking if that was in
conflict with Agile preference for “Last Responsible Moment” over
BDUF. Again the solution space seemed to me to focus on modelling from
examples, with enough modelling up front, followed by further modelling as the
model is stressed. You can see Eric’s talk here,
which includes a prototypical discussion of his Whirlpool approach.
Is there too much focus on the UI here though?
One of my concerns about the process as written is some of the focus on UI.
I understand the principle that the user consumes through the UI and it is
therefore the only valid test of the system, but this overlooks the extent to
which the UI is in flux during the early part of development. Indeed the
approach identifies that we need to release early to get feedback on the UI and
revise. Those revisions cause issues for tests that are focused on the UI,
because as the UI changes, the tests break. Rick Mugridge in Fit for
Developing Software is to test the business rules, not the workflow.
Now I don’t want folks to get the wrong impression here. We product a Balsamiq mockup of our user interface as part of the discussion on any story, often as part of our describe step, and we iterate over it. So I am certainly not saying that the UI is not vital to successful delivery to the customer or to understanding what is to be delivered. However I am more cautious around automate testing that focuses on the UI as the driver for development. I would rather drive from the rules than a UI focused test. We still have story tests to help ‘build the right thing’, in Fitnesse (replace with Cucumber, Fit, Slim, Specflow, StoryTeller etc) but they are subcutaneous tests. Much of our UI testing is via Exploratory Testing, and automated UI suites check only stable areas and act as smoke tests for regression issues.
All in all, very interesting stuff, that I will be looking into more as I try to refine my BDD practice