agile42

Feature Injection Applied to Service Delivery

What is Feature Injection? And how and why should that be applied to service delivery?

On
18 September 2011
In
Scrum, Scrum & XP
Tags
backlog, pull, real options, vision

Recently, I worked with a service delivery team in a company that is currently changing into an agile product development organisation. The company develops and runs one of Germany's biggest websites. Let's call them Awesome Online. After introducing Scrum and Kanban to all development teams over the past two years, executive and product management have started to introduce agile and lean thinking into the organisational structure and culture.

Motivation

A main motivational factor for the development teams was the definition of product visions for all products, and the application of Feature Injection as introduced by Liz Keogh to their development process—using pull on all levels to define goals, capabilities, features, stories and scenarios.

The ops team, responsible for the work environment of all employees and the operation of the website, has been seen as a cross-divisional function, leading to the team feeling undervalued. I asked them, “what is the product you deliver? Why do you not have a product vision?”

“Why should we?”, was their reply. They had not been introduced to Feature Injection yet, and after discussing it we all saw the potential that this could mitigate another more important challenge: prioritisation. They decided to give it a try.


A Short Overview of Feature Injection

Feature Injection was first developed by Chris Matts. Liz Keogh extended the model in this InfoQ article in 2009. I summarise here what she now teaches in her BDD tutorials (next one in November). This introduction is my current understanding/phrasing of what she taught me.

Feature Injection

Every Product has one Vision. This should be compelling, specific, and shared, and can usually not be realised in a single step. Therefore, you define goals as steps towards it. The business owning the vision usually has some idea of a date for the next goal, bringing in development to negotiate which capabilities could be realised by that date. From there, development pulls features from the capabilities, and stories from the features (as needed, eliminating the need for a backlog). Capabilities and Features can be thought of as Real Options, only committed to in detail when the most (and best) information is available (usually, later). Testers help developers to identify the best examples for the scenarios, which are then implemented in Code.

Feature Injection Completion

Over time, when these options are committed and executed, the elements of the model are realised from the bottom up: 

  • Code is written implementing scenarios.
  • Scenarios are tested to check that stories are done.
  • With all its stories done, a feature is completed.
  • With all its features completed, a capability is produced.
  • With all capabilities produced, the goal is reached.
  • When the last goal is reached, the vision should be realised.


 

Product Visions

Back to the situation with the team. We used the elevator pitch template from Crossing the Chasm by Geoffrey A. Moore. When we started discussing who was the customer, we found two. And two products, leading to two vision statements. This is the one I chose as an example for this post: 

For the AO employee
Who needs a fast and reliable, secure working infrastructure
The AOWE
Is a work environment
That should enable the employee to do her work effectively and efficiently.
In contrast to the BBWE
Our product
should be individually configured to the employee’s needs,
Should be personally taken care of,
Should allow greatest personal freedom while keeping AOWE secure,
Should allow data exchange between teams,
And should be continually and innovatively improved.

(BBWE is the BigBusiness work environment, BigBusiness being the larger enterprise that AO is part of.)

Four team members produced two (draft) visions within one hour. Time well invested, I think.

Pull Value

We continued our journey towards the value by defining goals for the first product, the work environment. We found there are two at any time:

  1. Reliability (which is a continuous goal for this product, not attached to a point in time)
  2. The next big thing they’re working towards (which would be the “normal” goal for a product development team), with a date.

(This is specific to a service team, I think. A product development team should usually work on one goal at a time, the next release of their product.)

We started to work on the stability goal and first found a good wording:

“The AOWE should be reliable.”

(The use of the word should is intentional.)

Capabilities and Features

What capabilities does the AOWE need to be reliable?

  • My data should be available at all times.
  • My internet connection should be fast and reliable.
  • My periphery should be usable and efficient for my work.
  • My software should be up-to-date and suit my needs.

From each of these capabilities we pulled features:

  • My data should be available at all times.
    • I should be able to read my mails.
    • I should be able to read/write on network drives.
    • I should be able to access version control.
  • My internet connection should be fast and reliable.
    • My computer should be defended against attacks.
    • My bandwidth should be greater than 5Mbit.
  • My periphery should be usable and efficient for my work.
    • My devices should not be older than 4 years.
    • In case of a defect, I should get a replacement within 48 hours.
  • My software should be up-to-date and suit my needs.

Focus on the Outcome

You see where this leads:

  • The team got a clearer understanding of their “customers’ needs”.
  • These capabilities and features can easily be prioritised against each other, leading to simple “pulling rules” for their Kanban board and minimising discussions about the importance of single tasks.
  • The product of this team and its value gets better visibility in the organisation.

Most tasks of this team are not programming tasks, so they won’t write user stories and scenarios for most of the features, but they can assign the help desk tickets to the features, giving structure to their work.

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

Discussion Comments are closed.

Comments are closed.

Comments are closed.

Comments have been closed for this post.

Latest entries

Interview on Dutch TV

Niels Verdonk explains what Scrum is and how it has helped a customer of agile42, AAFM ...

 

Bridging the Unknown

In an Agile transformation small steps and reassuring inspections of the path ahead are not random ...

 

Article on Agile Leadership in Swiss magazine Computerworld

New article published in the issue 6/2017 of Swiss Computerworld

 

SUGSA Coaching Day in Pretoria

Regina Martins will present at the first SUGSA Coaching Day in Pretoria

 

Managing Work Without Resource Managers

Moving to self-organized teams causes a manager’s role to change focusing on creating a safe-to-fail environment, ...