Pols Consulting

I remember having a rant at the eXtreme Tuesday Club a few years ago, “Who cares about working software, if it’s not what the business need? Delivering Business Value is the most important thing!”

This was triggered from seeing too many agile teams get bogged down in the minutiae of the process.  They did not think about how the business would benefit from what they did or how they could deliver value early.  Delivering working software was the only important measure they cared about.  They missed the subtlety of the Agile Manifesto that talked about delivering valuable software:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

I saw several agile projects that delivered software the business did not want.  Chris Matts and I made it our mission to bang on about Business Value back at the Agile Development Conference in 2003.  We published a paper in Cutter in 2004 based on our experience of applying these ideas on our projects.

It’s great that this is starting to get traction in the agile community.  There was even a whole track dedicated to this very subject at Agile 2008.  This has to be a good thing.

On reflection, I think the moniker Business Value was a mistake as it confuses the conversation.  People start assigning a Value to what they do:

• This project will attract 120 new registrations per month This statement is expressed as an absolute rather than a model. The greatest problem with this statement is that it’s impossible to re-evaluate the business value if market conditions change. There is no mention of the cost of generating this revenue or the amount of capital investment required to generate the revenue.
• This project is worth $12M
• This project with generate 4 million page hits in the first year.

Several speakers at Agile 2008 talked about business value Story Points. Joe Little proposed assigning Business Value points to each item in a backlog.  My experience is that this consumes a vast amount of energy and the business people start making up large values to game the prioritization process (Luke Hohmann has a nice posting on why prioritizing the backlog by ROI like this does not work).

I really enjoy watching the BBC television series Dragon’s Den.  Entrepreneurs pitch for investment in the Den from five Angel Investors (The Dragons!), willing to invest their own money in exchange for equity.  When the Entrepreneurs provide a Value, the dragons always probe for the model:  ”How much does it cost to manufacture?”,  ”What’s the size of the market?”, “What form of distribution channel are you using?”, “So how did you come to value your business at $8 Million?”, etc.  It’s impossible for the Dragons to make a sensible investment decision from a simple value.

This is why chris and I always say Business Value is a Model, not a number.

Software development is also an investment and, just like the Dragons (although I’m not suggesting our customers are dragons!), the Business need to probe the model to assess the value of the software investment.

Another problem is the model is is a state of flux.  Few businesses exist in a vacuum.  Markets change, assumptions become invalidated and competitors launch disruptive technology.  If you assign a value to a story based on a model, there is a danger that the model’s assumptions have changed by the time you want to implement it.  People take the business value number for granted and rarely question its validity.  I prefer a less formal approach, and simply use the model as a litmus test to verify if the next chunk of work makes sense as and when you need it.

Creating solutions that deliver the maximum business value should be the primary purpose of what every development team does, regardless of their process.  It’s more then just consuming stories or taking for granted that the items in the product backlog make sense.

This post is a bit of a therapeutic release valve. Last night I tried to book some airline tickets.  It took nearly 3 hours; although it felt much longer. How hard should it be?

I started out trying www.kayak.co.uk. It has a refreshingly intuitive user-interface and it searches lots of web sites for the best prices.  Just what I was looking for.

I particularly liked the nifty flight filters you can use to explore how the time of the flight, or the choice of airport impact the price.  Although I did find myself having to scan around the search results page (see above) to hunt down the date of the flights (I didn’t expect to find it in the heading. I guess the annoying advert in between the heading and the search results did not help).

The killer problem with Kayak is that it’s only a travel search engine (a friend described it as all fur coat and no knickers!) You can’t book the flights on Kayak and they have no control over the quality of the data. It turned out that I couldn’t book any of the flights returned in the search results!

They all pointed to a dreadful site called cheaptickets.com (the name should have triggered some alarm bells!).

When I first clicked the link from Kayak to Cheaptickets.com it spent ages displaying the following:

before it finally gave up and said (at least it said sorry!):

I tried clicking the link again (glutton for punishment).  This time the error message read:

We’re sorry. Due to changes in airline availability, the fare for your selected trip is no longer available.

It presented a list of alternatives that I could select.  At least it’s been helpful!

So I, rather naively, selected one of newly presented alternative options, and waited, … and waited, … and waited some more before it responded with (yes, you guessed it):

We’re sorry. Due to changes in airline availability, the fare for your selected trip is no longer available.

Not one of the recommend suggestions actually worked! What kind of web site gives you a collection of impossible to select products?

Aaaahhhhhh.

Next I tried Lufthansa.com – the cheapest option was £1600 per passenger, just to travel within Europe.

I then moved onto Lastminute.com.  I entered the dates and airports all over again and just when everything was looking good, I got this:

Aaaahhhhhh.  I was starting to think “Sod it – I don’t need a vacation!!”

In final desperation I went to expedia.co.uk.  I tend to stay well clear of expedia for multiple destination flights due to the high chance of sustaining a repetitive strain injury from the amount of mouse clicking required to complete the simple task.

I entered the data and it presented me with the various options for the first flight.  The idea (if you’re feeling charitable) is that you select the first flight, it presents the options for the second flight.  You select the second flight and it presents the options for the third flight.  At this point it tells you that this combination of flights will cost several thousand pound. You gasp, mutter something under your breath, and start all over again; randomly clicking flights and hoping for the best.  With any luck you will be able to remember which ones you have already clicked on.

There is another option. You can choose “view complete trips” and Expedia will display selected combinations of flights that are ordered by price.  I clicked this.  Some of the options were very close to what we wanted – except that one of the flights left at 6am.  So I adjusted the time of this flight to see what would happen to the price and all the other flights changed too.  Aaaahhhhhh.

Eventually, clicking like a madman, I manged to find a comination of flights at the time we wanted that we could afford.  I thought the internet was supposed to champion the consumer?  All I got was a shonky and painful user experience.  Something I don’t want to repeat in a hurry.

That’s better.  It’s all out of my system now.  Deep breaths… Think nice calm thoughts…

One of my clients was telling me about the problems that they are having with “Aspirational Planning“.  I thought this was an excellent description of the problems lots of organisations have with planning.

Then it slowly dawned on me that he was serious – they really do create “Aspirational Plans”.  They are fully aware that they don’t reflect reality (as they take so long to prepare), but the senior management love to spend lots of time and (other people’s energy) creating detailed plans of what may or may not happen one day.

The teams on the ground just roll their eyes when I ask about these plans. I’m going to have my work cut out on this one.

The old bambinos made me laugh with this suggestion.

An improvement on XP’s stand-up meeting, or scrum’s daily scrum is the New Bamboo Hang Up Meeting. You are only allowed to talk while performing pull ups from a steel girder. Not only does this keep the meeting short, but ensures the team reamins physically fit

These are fantastic.  See the full set on http://www.redbubble.com/people/Balakov

David Anderson gave a talk about kanban at XTC a few weeks ago (11th March 2008).  David’s pictures os  projects using kanban struck a chord with me.

My current project is split across multiple locations (well, countries!) and we keep track of what we are doing in Jira.  Jira is great for tracking and chunking work into releases, but it wasn’t highlighting our process bottlenecks.  We’d been caught out a couple of times by juggling multiple streams of work and having too much work building up in UAT.

I emailed David’s slides around the team and asked people if they thought the kanban view of the project would be helpful. The technical people thought it was a great idea, but the business people couldn’t see the point – they already had this information to hand and did not think it would be worth the effort.

One of the guys (Paul Allton) did a little experiment using ruby to automatically create a kanban work-in-progress view of our existing jira data.  It’s gone through a few iterations, but this is what it looks like now:

Taking the kanban picture to the standup was fascinating.  The people who thought it was unnecessary suddenly became animated about the bottlenecks. This picture makes it very easy to see the state of the project and where people need to spend their energy.

The poor man’s kanban (because we’re not really doing kanban, and it would be much better if we had a physical board) has proved very popular with the team.

I enjoyed reading Keith Braithwaite’s post on tests and gauges. I like the way Keith uses the the metaphor of gauges in metalwork to describe Fit style tests:

You don’t work anything out from a gauge. What you do is apply it to see if the workpiece is within tolerance or not.  And then you trim off, or build a bit up, or bend it a bit more, or whatever, a re-apply the gauge. And repeat.

I agree with Keith.  The fit tests I write are business facing and for the benefit of the business customer.

On a recent project our customer got really enthusiastic about our fit tests, so much so that he got extremely upset when I implemented a story without a fit test.  He refused to let the system go live until we had the fit test in place.

The story in question was very technical and involved sending a particular xml message to an external system. We just couldn’t work out what a fit test would look like for this type of requirement.  Placing the expected xml message, with all it’s gory detail,  in the fit test wouldn’t have been helpful as it’s a technical artefact and of no interest to the business.  We could not work out what to do.  The customer was not around to discuss it, so I just went ahead and implemented the story (very naughty!).

The Customer was using the fit tests to show him what the system was doing.  In this case he wanted to be sure that we were sending the correct product information in the xml message.  To resolve the issue, I suggested that we have a Fit test that shows how the product attributes get mapped onto the xml message using xpath; although I still thought this was too technical for a business user.

We gave the Customer a couple of links to explain what xpath was so he could explore if this was a good solution for him. To my amazement, he was delighted with xpath (I now know who to turn to when I have an problem with xpath) and filled in the fit test.

The interesting bit for me (and why I’m posting it on the blog) is that as soon as he knew what the message looked like and how it was structured, he realised that it did not really support the business – we were sending information that was outside our scope of our work and should have been supplied by another system.  He was also sceptical about the speed the external team could add new products due to the complex nature of the xml.

Most agile people I tell this story to think we have the “perfect customer”!  I agree.

No one thought it was a bad idea to run acceptance tests on the live system.

What could possibly go wrong? Everyone knew that orders for “Mr Test Test” and “123 Test St were not real orders!

That is, everyone except the marketing department.