Feature Injection: three steps to success
Feature Injection is a business analysis process framework that allows teams to exploit the value of the traditional business analysis techniques in projects involving frequent iterative deliveries, such as the ones implemented using agile and lean processes. It focuses test-driven-development and behaviour-driven-development on delivering business value and ensures that a team only builds features and projects that deliver value, avoiding the wastes of scope creep and just-in-case code.
This article is a high level introduction of Feature Injection and related techniques. We explain the key elements of the framework and support them with a realistic example. To keep the article relatively short, we also provide references for further investigation instead of going into details of individual tools and techniques.
Why should you care about Feature Injection?
Imagine that you are working for the IT department of an online store that sells books and consumer electronics, and the VP of marketing starts a new project to integrate with a third party sales analytics solution. The third party vendor convinced her somehow that integration would be useful, but the requirements are vague, often expressed such as “send them all the data we have”. After the initial analysis, your team is knee-deep in difficult decisions around data structuring, export file management and masking to comply with privacy and data protection laws. You know that credit card data cannot be sent out, but nobody really knows whether customer's home address and date of birth that can go without masking. Marketing people insist on sending data out in real time, regardless of the complaints from the architecture team about the operational impact on day to day trading. When an architect voices his concern over beers to the senior director of sales, his high school friend, the entire project is shelved, officially awaiting further analysis. Does this sound familiar? Then read on to see how you can avoid it.
If you are working in an IT department of a large organisation, your team most likely has to balance and prioritise between the needs and requests of multiple stakeholders, and engage more than one person or even group while preparing for software development because the knowledge is not centralised. You probably feel that as soon as you deliver a feature someone requests a change to it, and it seems as if the business users have not really thought through the required solution from end to end, leading to a lot of scope creep and wasteful rework. If you are working as a business stakeholder in such an organisation, you probably feel that incremental or evolutionary development approaches driven only by immediate scope (such as user stories) fail to deliver business value. Both problems are caused by organisational complexity of large businesses and systems and visible with two related symptoms: business users that communicate with delivery teams often do not have a clearly defined and communicated idea where the business value on a project is coming from; delivery teams focus too much on low-level function detail and lose sight of the big picture.
Feature Injection is an effective way to prevent such problems, while avoiding the pitfalls frequently associated with more traditional staged development processes such as paralysis by analysis, long analysis phases and wasteful work on analysing requirements that will change before implementation. The goal of Feature Injection is to link the business analyst community with the agile development community. From one perspective, Feature Injection allows traditional business analysts, used to UML / Use Cases or SSADM, to participate effectively in Agile and Lean projects with a slight shift of emphasis and without a steep learning curve of new techniques. From the other perspective, it helps agile and lean software development teams to benefit from just enough analysis and just in time, to prevent scope creep or fail to deliver business value in complex enterprise projects.
Three steps of Feature Injection
Feature Injection was discovered through practice rather than designed as a process. The initial idea was conceived by Chris Matts while doing pair analysis with Rohit Darji when they had to share a desk due to space limitations in the dot com era. Andy Pols and Matts evolved the idea further in 2003 while looking for a way to get traditional business analysts involved in an agile project. Matts extended it while working with Sanela Hodzic in 2004, introducing the use of examples to validate or break models. The final piece of the puzzle, looking at an IT project as an information arrival process, came out a conversation between Matts and David Anderson at the Agile 2007 conference.
Distilling the core ideas, Kent McDonald defined Feature Injection as a three-step process framework (Feature Injection : A gentle introduction. presented at Agile2009):
- Hunt the value.
- Inject the features.
- Spot the examples.
This framework scales well – it can work for small as well as big projects as teams can use different techniques to achieve the required effect and focus on different areas of the process depending on their particular constraints.
Hunt the value
Many projects start out as requests for functionality and then teams chase an unknown business value. For example, a request to build a nicer user interface might come from the need to improve employee satisfaction, which itself might come from the need to reduce staff turnover in order to reduce operational risk. While passing through layers of organisational hierarchies and different roles involved in delivering software, this information often gets lost. When the real reasons for a project are not clearly identified and communicated, delivery teams have very little chance to actually deliver them. Teams also cannot identify other ways to deliver the required business value, which might be easier, cheaper or faster to implement.
To ensure that software delivers the expected business value, we first have to clearly define and communicate it. Several existing process frameworks try to deal with this with different levels of success. User Stories require explicit statements of business value but many teams struggle to get this right, resulting in story card hell. In particular, with complex enterprise systems the value is not always obvious to the development teams and requires higher level clarification and analysis. Mark Denne and Jane Cleland-Huang describe an approach to driving software deliveries based on financial modelling in Software by Numbers, but teams often struggle with this because business value is hard to describe with a single number and estimating such numbers is no easier than estimating how long something will take to deliver. A number assigned to expected business value tends to become the “foundation” upon which a project is built on and is rarely visited or challenged. This can lead to death march or zombie projects.
In Feature Injection, teams first “hunt for value” by creating a model for business value delivery instead of trying to describe it with simple numbers.
For example, a value model for the sales analytics integration example would be something such as: we will profit from increasing repeat sales to existing customers, we expect to use sales analytics to offer items people are likely to buy proactively rather than being a passive purchasing system. We expect to increase our sales by 10% the first month and by 200% over six months by using this approach.
A model is better than a simple number because it makes explicit the assumptions underlying the value. Such a model can be used to evaluate whether or not to include business features suggested by various stakeholders, and effectively prevent pet features from blowing up the scope of a project. For example, the model based on periodic contact with customers makes it obvious that real-time analytics are an overkill.
A model for the business value allows us to create a strategy, a way of saying “These are the things we do now and in the future” and perhaps more importantly, a way of saying “these are the things we will NOT do now or in the future”. The key thing is that the business value model is used to align the project delivery team with the business investor or sponsor.
An explicit value model supports and encourages the team to frequently re-evaluate the value a project delivers as new information becomes available. For example, we can measure whether customers are actually buying suggested items a week after the first features are delivered and decide whether the analytics are providing the value we expected. We can use this information to decide to modify the analytics used to suggest features, focus on a particular type of suggestions that works well or and monitor customer satisfaction before investigating opt-out features.
Making the assumptions explicit also helps to build a shared understanding of where the value is coming from, allowing a team to spot new opportunities or prevent going into dead ends. For example, the architecture team might suggest using some readily available statistics, such as 10 most popular items sold weekly, to test if the customers will react positively to proactive sales. This can be done without integrating with a third party provider, and possibly offer some quick return on investment.
- Here are some tools you can use to hunt for value and develop a model
- Popping the why stack / five whys. We start with the feature request and pop the why stack until we reach the output and ultimately the value.
- Asking “how would that be useful?”
- Purpose alignment model
- Boston Consulting Group Market Maturity Model
- Inspection templates. Especially useful for non functional requirements (“no design” etc for real requirements (ref Competitive Engineering)
Chris worked on a project to calculate credit exposures for an Oil company. He joined the project shortly after the solution had been selected. The solution involved an overnight batch process to calculate the exposure the company had to counterparties.
The project had been started due to losses that had occurred over the previous few years. The project was meant to prevent similar losses occurring. The company wanted to prevent traders from entering into business with counterparties that would exceed their limit now and in the future. The value was understood.., sort of.
One of the stories involved a company that knew it was going to go bankrupt. It had gone into the market a couple of days before it declared bankruptcy and sold options. It took in the option premiums in the knowledge that it would never pay out on them. (This is similar to an insurance company taking in insurance premiums when it knows it will go bankrupt and thus never pay out the policies it has written. The company had exceeded its limits and received more than it should have been able to. The Oil company lost more than it should have done.
The only way to counter this situation would be to build a real (near real) time system that updated the exposure to each company within a few minutes of a trade being done. The overnight batch system would not capture this value,
The system would allow the company to see future projections of the exposure which would allow them to identify points in the future when the counterparty would potentially breach their limits.
Inject the features
Once a model is defined, we do more than just evaluating whether to accept or reject a suggested feature. We can proactively create a list of features that drives towards delivery of business value based on our models. This is the core of Feature Injection.
The worst mistake with any piece of analysis is to start with the inputs, yet this is precisely what many teams do while delivering iteratively as technically something has to come into the system before it is used. In the opening story of the article, the team hit the dead end with data protection requirements and operational concerns exactly because of this. Starting with the inputs of a system leads to endless “What do we need?” questions and spending a lot of time analysing each suggested item to see if it is really needed. This is a common recipe for analysis paralysis. Inputs into a computer system have no value on their own other than as a dependency to create an output.
To deliver value, Feature Injection helps teams work back from the outputs. A business value model tells us the value we are after. We can use it to identify the minimal set of outputs from the system that will deliver that value. For each output, we can use traditional business analysis modelling techniques to document the business transformations necessary to generate those outputs. Those business transformations will also identify the necessary inputs.
For example, to increase repeat sales to existing customers using the model described earlier, we could initially focus on increasing sales by proactively offering items frequently bought together or items bought by people with similar buying patterns. We now have two business value increments.
- In the first case, the delivery team suggests that the data is already available and there is no need to perform fancy analytics. They suggest that setting up a nightly job to run a simple data query and record the best suggestion for every item in the inventory, then display that as a suggestion during the check-out process.
- In the second case, the delivery team suggests that they could export sales information with product and customer identifiers, without any sensitive personal data, which is enough for the analytics package to produce suggestions. A weekly e-mail job would then send suggestions to customers depending on the output of the analytics package. The scope is significantly different in these two cases and the model for the value also allows us to evaluate which of these approaches to take.
While discussing these two options, an analyst on the delivery team also puts forward a completely alternative third suggestion:
- Offer customers free delivery on their next purchase if it is made within a certain period by repurposing the existing free delivery coupon system. The features required to implement this would be automatically issuing a new free delivery coupon after each purchase and tweaking the outgoing confirmation e-mail to include this information.
Traditionally what would happen is that the business would come up with half-baked solutions instead of the value they want. They bought an analytics package and it worked great during the demo, but they did not really think through it end-to-end. Because we now understand that the value of this piece of work is to deliver new sales, there are many ways to satisfy that and they each become a separate piece of work. With the business value model, we can evaluate suggested solutions. The key thing is, because we’re doing it based on value, we can start slicing the value. Instead of having a single deliverable, we can have several deliverables for a single business value item. We can start to get feedback quickly on whether this works or not.
Working from outputs to inputs will prevent analysis paralysis as at each step. Instead of evaluating whether a particular feature is relevant, we proactively design features that are relevant and drive the inputs into the system to enable such features. The business value scopes the outputs and the outputs scope the processes and inputs.
Tools to use to inject features:
- Traditional Entity-Relationship Modelling
- Object Modelling (UML)
- Models built in spreadsheets (See case study)
- Effect mapping
Sanela Hodzic and Chris Matts first applied this back to front approach on a system to calculate the credit exposure of an oil tanker. This complex situation was modeled in a spreadsheet.
The output is easy to describe. You need the date the exposure starts, the date the exposure ends and the amount of the exposure. These exposures could be aggregated to give the profile for a counterparty as shown below.
From the graph, the system shows that the fourth month has an exposure of two million when the exposure on the three tankers overlap. The credit department would want to prevent any business in April that could increase that exposure.
Now that we know the outputs, we can inject the features to calculate the values. We work backwards from the output to the inputs. For the amount, we need the number of barrels of oil in the tanker multiplied by the price of oil per barrel. We can get the price of oil from the “oil price” system so we stop there.
The number of barrels is more interesting. On the original contract, the number of barrels has a tolerance of 10% so to be on the side of caution we set the it to be number of barrels to be 110% of the contract amount. We can get this information from the “oil contract” system.
When the oil tanker is specified, we can get a more accurate figure for the number of barrels od say tolerance 2%. This information would be in the scheduling system. However this additional accuracy benefits the traders as it frees up capacity to more trades. Adding this information is another business value item.
When the oil is loaded on the tanker, the exact number of barrels of oil is known. This information is in the operations system. Once again the beneficiaries are the traders.
The start and end date are also specified in the contract. Once again, they have tolerances. For example January, or Q3, or H2. Obviously the longer the time an exposure exists for the more punitive its effect as it cannot overlap with other trades. So to calculate the start date, need the earliest date the oil can be loaded. The exposure ends when the counterparty pays the invoice. To calculate the latest possible payment date, we need the latest date the counterparty can for the oil which is the latest date the oil can be loaded ( contract system ) plus the payment terms ( billing system ). Once again, when the tanker is scheduled ( scheduling system ) and loaded ( operational system ) reduces the tolerances.
We now know the data we need in the system. We can also the deliverable into several deliverables of value. One for the data in the oil price, contract and billing system which is the minimum required to calculate the worst case exposure. Then additional deliverables to add scheduling and operational systems.
Our first business value increment might look like this…
Once we have identified the values we need to source from outside the system, we can stop. Feature Injection has a defined end point and as a result does not suffer from Analysis Paralysis.
Spot the examples
Injecting Features provides a set of “happy paths” to create the outputs, which will deliver the business value. It does not, however, provide all of the variants of input that can occur to affect the outputs or all the cases that need to be considered for successful delivery. To identify these variants we have to expand the scope. Feature Injection expands the scope of injected features in a very particular way, that is uniquely effective in ensuring a shared understanding – by using examples. Examples are a natural way to communicate and clarify ideas in day to day conversations. We use them without really thinking about it. For example, searching for “for example” on Google returns more than 300 million pages. Examples are also a very effective way to validate and check our assumptions in requirements and get from things that customer say they want to what they really need.
With Feature Injection, teams expand the scope of features and provide detail by investigating high-level examples of use, by applying both traditional business analysis techniques and emerging collaborative specification techniques.
Expanding the case study above, we asked the business experts whether there were any examples that did not fit into the example we had constructed. The business did not need to expand the model, they just needed to provide examples for us to check against the model.
Initially, we would have simple examples like a contract with a fixed oil price. ( We need the price from the contract and a way of differentiating fixed and market price contracts. )
Then they started sharing stories of types of exposure that had caused problems in the past. They were supplying gas to a company that went bankrupt. The gas fed a power station that kept the lights on in a city. When the engineer turned up to turn off the gas they were still supplying to the power station, the police informed them it would be a federal offence to turn it off. The effect was that the exposure on this kind of contract went to the full amount on the start date of the contract. ( We need some way of identifying contracts that cannot be interrupted - a new attribute in the contract system – and the end date of the contract ).
The business were able to understand the examples and provide ever more obscure examples.
As well as modeling the data in a spreadsheet, it was modeled as an entity-relationship model. This helped us focus questions looking for interesting examples. E.g. Does a contract only ever cover a single shipment of oil (tankers) or can they cover more than one shipment of oil (barges).
For example, the sales and marketing teams suggest after a brief discussion that offering free delivery for every repeated purchase doesn't make sense, but that it might work for items that are not heavy or bulky. As an example, they offer that free delivery on a single book would be acceptable, but a free delivery for a fridge doesn't make sense commercially. This opens up a discussion on where to draw the line and what to do if a customer buys a single book and a fridge. Suggestions start flowing about splitting the shopping cart, managing multiple carts and the architecture team then again uses the business value model to suggests trying out something simple: offer free delivery to customers that only order books. This can be implemented quickly and the team can measure the impact before investigating how to manage mixed item shopping carts. Testers also offer an example of a customer from another continent purchasing a single book, voicing their concerns about international delivery which can dwarf the profits on selling a single book. This leads to a further reduction of initial scope on only domestic customers. The team notes the concerns and business analysts are given the task to work with the database administrators on coming up with good thresholds for future expansion of the delivery offer on electronics and international orders. Meanwhile, the delivery team has enough concrete information to start diving into details to deliver the initially agreed set of features. After this initial delivery, the team and business stakeholders can evaluate the results against the value model for the project and decide whether it is worth pursuing further the free delivery functionality, or change to an alternative way of increasing repeat sales.
High level examples provide enough context to focus related development processes such as test-driven-development and behaviour-driven-development. They can be broken down into smaller, finer grained examples that describe how different functions of a system need to work in order to support the high level examples. If they are detailed enough, the examples can also be automatically validated against a system in development, providing an objective measure of progress and a foundation for a living documentation system.
Tools to use to spot the examples:
- Traditional Entity-Relationship Modelling
- Object Modelling (UML)
- Examples in spreadsheets (See case study)
- Refining specifications with Examples
- Domain Driven Design
About the Authors
Gojko Adzic is a strategic software delivery consultant who works with ambitious teams to improve the quality of their software products and processes. He specialises in agile and lean quality improvement, in particular agile testing, specification by example and behaviour driven development. Gojko is a frequent speaker at leading software development and testing conferences and runs the UK agile testing user group. Over the last eleven years, he has worked as a developer, architect, technical director and consultant on projects delivering financial and energy trading platforms, mobile positioning and e-commerce applications, online gaming and complex configuration management systems.
Chris Matts is a business analyst and project manager who builds trading and risk management systems for investment banks. His aproach to IT risk management is based on what he has learnt from investment banking risk management. Chris tweets at @papachrismatts. He blogs here and here.
Mike Hartington Jul 26, 2015