Skip to main content

BDD, Feature Injection, and the Fallacies of Product Ownership

Product Ownership is very difficult.  Take a big step away from the Agile Manifesto and think for a moment about project stakeholders, user stories, and how they don't fit together as neatly in real life as they do in Mike Cohn's User Stories Applied, as awesome as that book is.  How in the world is it possible for there to be a single person standing in for all project stakeholders in negotiating with the team?

From http://www.implementingscrum.com/2007/04/23/the-cast-of-implementingscrum-infamous-yet/

Conveniently, Cohn himself points out The First Fallacy of the Product Owner.  And that is, of course, that such a being actually exists:
On an ideal project we would have a single person who prioritizes work for developers, omnisciently answers their questions, will use the software when it’s finished, and writes all of the stories. This is almost always too much to hope for, so we establish a customer team. The customer team includes those who ensure that the software will meet the needs of its intended users. This means the customer team may include testers, a product manager, real users, and inter-action designers. (User Stories Applied, p. 8)
As Cohn says, the Product Owner may in fact be a "customer team" of some sort.  And this team needs to somehow get onto the same page so that if the non-product-owners on the team have a question, they get only one answer, no matter who on the team they talk with.  Scary, but true, and very real life.  Can that be done?  Yes, certainly.  But it requires trust and discipline on the "customer team," and it may not come naturally at first.  And wait, there's more!

The Second Fallacy of the Product Owner is that the main people with whom the project must be concerned are the real users of the software.  Such a fallacy relies on a confusion between project "stakeholders/sponsors" and project "end users."  They are not the same!  What do you do in a corporate environment in which the "customer" with the budget is an executive decision-maker who will never use the software or even see it?  On real projects in corporate environments, your product owner needs not only to understand and manage the desires of competing software users, but also to build a consensus all the way up the executive chain of any sponsoring stakeholder organizations, and keep these sponsoring stakeholders as well as the end users (not to mention developers, testers, and other team members) all on the same page.  And of course business goals and user needs keep changing.  And that brings us to the related:

Third Fallacy of the Product Owner, which is that "business value" can be determined by operational end users.  Don't get me wrong.  Executives, and even some line managers, are the last people in the world you should go to, if you want to find out how software is used in the wild.  You will certainly build a big, unfortunate loser piece of software if you just listen to "the brass."  They don't know!  They probably don't even know all the systems their employees use to keep the business running.  You must listen to the real users of the software.

But if your goal is to deliver "high value" software first, and "lower value" software later, then the real users won't have the full picture either.  You need the executives to make decisions like "just skip that whole part of the old process--that never made sense."  And this begins to get very tricky indeed, because the "customer team" is now dealing with Stakeholder A who may be in a position to deeply change Stakeholder B's job, or even eliminate it.  So if you're under the impression that the "customer team" is one big happy family off in the "Product Owner room" all together, you need to let that go too.

So where do Behavior Driven Development (BDD) and Feature Injection come into the discussion?  My colleague Jeffrey Davidson just put together a brilliant slide presentation on these very topics, which you can see here.  BDD and Feature Injection are both methodologies which have been described as a step forward in terms of gaining a common understanding of system behavior between the "business side" of a team, represented by the Product Owner, and the "development side," represented by the developers and systems testers.  Because BDD and Feature Injection allow the system to be described as a series of examples, rather than a series of "the system shall" statements, business people focus on business value, and developers figure out the best technical way to get the business value out fast.

But BDD and Feature Injection provide something even more valuable, if you're being asked to be a Product Owner, or to be part of a customer team.  Both techniques provide a way to get real software users and executive stakeholders onto the same page, and to keep them there as well.  And that is a very good thing.

BDD, as Jeff says, is all about describing software in terms of examples, instead of in terms of the components that make it up.  (Please also see this timely repost of Martin Fowler's bliki post on "Specification By Example.")  "Given" a certain circumstance, "When" a certain real software user does something, "Then" you should see a certain result.  What does the Given/When/Then formulation do to help the customer team?
  1. High level user stories ("features" or "epics") described in terms of given/when/then give real software users a succinct view of how the software brings overall revenue to the firm.  You may also incur this type of benefit by revising the order of the traditional Mike Cohn style user story elements:  "As a <role>, I <need to incur a specific business value>, by <feature>."  Here the roles are far more likely to be executive roles like "as the CEO" or "as the CFO," but it's wonderful to know what it is that the team is building, in terms of the overall flow of revenue to the company.
  2. Low level user stories, the size that can be developed by the team, clarify to executive stakeholders exactly what real software users are doing and why.  Most normal executives cannot withstand even a single "the system shall" statement, but they may participate eagerly in a discussion couched in terms of "given/when/then," and be able to allay fears among the real software users that they have a specific need for some part of the system that is particularly obnoxious to use.  That's a good thing too.
What about Feature Injection?  Feature Injection, invented by Chris Matts, and explored in print primarily by Chris and fellow FI aficionado Liz Keogh, says that you need to start all software development discussions by talking in terms of the type of business value that makes sense to the CEO and the CFO. Chris and Liz will tell you that the team should be describing, with examples, what the new software will be doing for the business when it's done.  So the process is:  1)  identify the value, 2) identify the feature that will give you the value, 3) describe that feature in terms of examples.  Kent McDonald provides a nice, "gentle" introduction to Feature Injection here.

A customer team which combines Feature Injection to build word bridge between "value" and "features," and then describes those features entirely in terms of BDD's "given, when, then" scenarios may find itself aligned not only with software developers and testers, but also with itself.

Comments

  1. Thank you for the link to my presentation. I am super-excited about BDD and the sister philosophies of Feature Injection and Real Options.

    I am convinced this set of tools are a huge addition to the BA toolset. Using these, I can easily move the business from talking about solutions and features to real problems, allowing me and my team to address real business needs.

    It's a huge win for everyone when a development team is concentrated on solving business problems and adding value; BDD helps us get there.

    ReplyDelete
  2. Yes, and your deck is really beautiful too! Thanks for getting that info directly from Chris Matts!

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica