Skip to main content

Just In Time Software Requirements: Introducing "Value Spikes"

I've been pondering further difficulties of being a product owner, both silently and aloud, so yesterday I was happily bowled over by a new idea on the topic from my new ThoughtWorks colleague Jasper "Dutch" Steutel (@dutchdutchdutch for twitterphiles).  He calls his discovery the "design spike," and we ended up talking together about a related concept, the "value spike."  So what's this all about?  Aside from being "Vampire Month" on the Pragmatic Agilist?

From http://io9.com/james-marsters

The Problem

It may be different in a small start-up or a firm well-organized into small, highly integrated business/technology verticals, but in a typical large corporate enterprise with matrixed silos, it is quite challenging for a Product Owner to speak for all of the stakeholders on a project.
  • The PO must be able to speak fluently to the technical people on the team
  • The PO must be able to provide one reliable set of priorities which reflect acquiescence among all of the PO's horizontal peers in the organization, plus their direct reports.  If there are competing priorities among those peers, creating and maintaining this uber-backlog will involve some serious facilitation chops.
  • The PO must also be able to speak authoritatively within the funding hierarchy and hierarchies in which the project finds itself.  The "funding authority" is likely an executive with her own relationships to maintain.
  • The PO should also be a user of the software and be able to speak to the full user experience; the PO should be able to conduct UAT.
  • While they're thus occupied, POs must also be steadily (if not continuously) available to the team. 
Moreover, on teams that believe there should be life for a project before iteration 1, the PO somehow has to make all of this happen at a high level during a quick 2-4 week "inception" period, and then keep the team in touch with the right subject matter experts as the project proceeds.  How can any one person actually do all this?

Spikes

For those of you who aren't already familiar, a "spike" or "tracer bullet" is a short piece of work within an agile project in which one or two programmers may be assigned to do outside of the iteration structure.  The spike investigates unknown technology problems well enough so you can estimate them.  There's a nice explanation in this blog post about these related concepts and their origins.

An example would be that the team discovers it needs to use a new visualization technology for a planned dashboard, but nobody on the team has ever used the technology before.  So the team simply doesn't know how long the work will take related to that new technology.  At the point where the team urgently needs to know the details about how hard it is to work with the new technology, the group agrees to send a pair of programmers off for a pre-specified amount of time (a "time box") to learn enough about the new technology so that the project work can be estimated.

Any work the programmers do in this spike typically will be thrown away--the spike produces team learning, not reusable software.  Once you know how long the tasks related to the new technology are going to take, you can make appropriate decisions about what to include and what to postpone from your current planned release, compared to other features which have already been estimated.  You adjust the backlog accordingly, and the team moves forward.  Conceptually:

Spike allows for backlog adjustments based on needed new information.  But note that no new working software has been written during the spike.  The output of the spike is just learning.

Design Spikes
 
Dutch, who has brought many years of product management experience to ThoughtWorks, points out that on a product-oriented team, you may be as likely to need a "design spike" as a "technology spike" before you can complete backlog grooming, or even complete a story that is currently in play in an iteration.

In this case, the developers may or may not know how to write the software behind the story, but what is very clear as you talk it through in the team room is that nobody knows what the desired user experience should be for the software.  What do you do?  You take the story out of play for the current iteration, and hold a workshop for the PO and any SMEs who can speak for customers, or even customers themselves, and determine what the user experience should be.  This could be expressed as a wireframe or a photograph of a white board--unless the question is specific to the design at the CSS level, you may find it more helpful to come out of the design spike with team learning about the desired user experience, not a complete web page template.

Note that in an idealized "Continuous Delivery" project, every iteration actually calls for a software implementation of a design spike, and so-called A/B user testing determines what your next step should be by measuring the way actual customers use the software.  Notice what happens here--if you're working with known technology, you may do an entire project without doing a software spike, in the standard sense of the word.  Even though some of the software gets thrown away, you're always building the real software, not a throw-away architecture.  But from a design perspective, continuous delivery is nothing but a set of design spikes which result in team learning, and throw off the software itself as a side-effect.

Value Spikes

So let's take the spike concept back to the poor, overworked Product Owner stuck doing a vendor workflow implementation for internal use at a very large company.  This thing is not being ported to an iPad any time soon.

The team is all sitting around in the team room talking about the new dashboard you're implementing in this sprint.  As it happens, the developers are not familiar with the visualization technology, and they are eager to go off and have a spike to figure it out.  And goodness knows they deserve it--all they do is write integration code all day long.  But wait--before two lucky programmers run off to play with something new, it turns out that the team stops to ask the Product Owner what the value of this dashboard is going to be.  It seems like a lot of architectural investigation for a product that is going to use 3D to visualize work orders going from the "pending" state to the "done" state.  Why, you ask, is 3D necessary for this?  What is the value?

Most likely the Product Owner does not know, in this environment, how the team ended up with a request for a 3D workflow state change visualizer.  There are a lot of players, and there's a lot of politics, and it's a big project, and this is only one of a thousand requested features.

This is where the "value spike" comes in.  Just as you should stop work to get a general idea of the effort involved in specific stories, or the user experience required, you should also stop work to allow the Product Owner a time box to assemble the right SMEs for a meeting to determine the authorship and impact of a requirement whose value seems questionable.  The PO does not have this information top of mind any more than the developer has information on every possible technology ready to hand.

In this case, the PO will return within the time box with a fresh view of the value of the feature, and just as happens with a technology spike, the PO will do a new cost/benefit analysis based on the value the feature will bring compared to the cost it will take to develop it, and modify the project backlog accordingly.  It looks like this:

Seem familiar?



In case the suspense is killing you, in our hypothetical case we'll stipulate that the Managing Director who staffs the data entry area has trouble understanding why things are so slow.  The project sponsor, manager of these data entry people, has made it her top priority to make the staffing problem crystal clear.  She would implement "Smellovision" if it were possible.  This feature jumps to the front of the backlog, the team completes it, the sponsor is happy, and everyone has a good day.

Design and value spikes should be tactics that every Product Owner keeps handy.  You don't have to be omnipotent if you have a technique that lets you become expert on one little piece at a time.  And that's as close as we get to Enterprise Fun these days.

Comments

  1. Hi Elena
    I like your Problem statement for the PO and
    I get the Design spike, but I am not clear about the Value spike. Are you saying that the team stops everything and waits for the PO to come back with confirmation of value and a modified backlog, or that just the 3D feature story is put on hold and other stories are worked on as some sort of dashboard is needed anyway? Doesn't the change of backlog depend on the cost benefit analysis which in turns requires the team to spike the technology to get a reasonable estimate, so shouldn't that happen anyway? If the overworked PO has missed understanding the benefit or value of a feature before putting it to the team then the long term solution would be to scale up the PO function in the customer team to reduce these errors rather than relying on spikes as part of the process?

    ReplyDelete
  2. Hi Ian,

    Thanks for asking! I probably shouldn't have chosen an example in which both a technical spike and a value spike would be needed. You are right--in this example, both would be needed. But the point I was hoping to make is that even if the technology were known, the value spike would still be needed, and not to determine screen behavior--just to determine value.

    My feeling is that the business environment is as prone to require an occasional spike as the technical one, either because things are changing in the market, or because more depth of analysis is needed.

    In other words, for a cost/benefit analysis, we should allow for spiking on the benefit as well as on the cost. To keep it agile, we should embrace change from the value side just as we do on the technology side.

    From that perspective, I don't regard changes in business value to be "mistakes." My idea was that the value spike would indeed be a technique to take on which would allow for as-needed scaling of PO capabilities.

    Makes more sense?

    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