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.

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.

I though it was worth sharing some experience we are having speeding up our very slow build from 1 hour plus to around 10 minutes.

In the past we have spent a lot of time exploring why our tests are slow and have never really come up with a good solution. We’re continually extending the test suite, so any savings we make don’t last that long.

The unit tests are quick (~40 seconds), but it’s the acceptance tests that start up and run the application that are painfully slow.

We decided to group the acceptance tests into small logically grouped test suites that can run in 10 minutes or less. Then we added build agents (each running on a separate machine), so we can run as many of these small test suites in parallel as we can.

Every time the build gets too slow we break them down into smaller chunks and add another build agent. Hardware is cheap so it’s easy to sale this solution.

So far this is working really well.

I have just discovered an old post by Jim Shore (http://www.jamesshore.com/Blog/How-I-Use-Fit.html) about how he started out using FIT. He started out by switching from a unit test driven approach to a more story driven development approach.

I encountered a big problem with this approach, though: I stopped doing good TDD. “Storytest-driven development” blurred the line between Fit and unit tests. The “STDD” cycle largely replaced the TDD cycle and, as a result, I had far fewer unit tests than normal.

That was a problem because Fit examples are not unit tests. Fit examples are just that: examples of a business rule in action, from a business perspective. In TDD, I write tests for every line of code that can possibly break. In my Fit examples, I try to talk about every possible business case. That’s a bigger net than TDD, and without TDD, my code wasn’t well tested.

I had the exact same experience. I also found that the design suffered due to the lack of tests (it did not force me to refactor as often as I should) and it had a detrimental impact on my productivity. Story tests are larger in scope and take longer to run. Unit tests provide a much faster feedback loop when you break something.

I wish I had read this before I started using FIT.

As a follow up to my post on pair programming based interviews, I noticed this on a recent job advert:

In chess it is possible to place eight queens on a board so that no one queen can be taken by any other. Write a program to determine all such possible arrangements for all eight. I am not looking for a Chess Games Developer. I am looking for Java Developers who have the OOA and OOD skills to solve this problem….

Which one would you prefer (to receive if going for an interview, or to use to find a good candidate to work in your team)? A test that’s abstract and has nothing to do with the work involved, or one that that involves doing the job you are interviewing for?

I wonder if they have run this test on all of their existing staff to see if their is any useful correlation.

I noticed an interesting discussion on the IXP mailing list about pair programming with developers during an interview. I was surprised by the number of people who thought it was a bad idea.

I have done a lot interviewing for various companies and one of the best ways to find out the beliefs and values of a software developer is to look at their code. The best way to know what someone is like to work with is to work with them! This is why I really like pair programming interviews. It’s one of the best interview techniques I know.

Another nice feature of a pair-programming interview is the continual conversation you have with the candidate. It provides you with ample opportunities to ask sensible questions about the code you are writing. This gives the candidate a better understanding of why you are asking the question. There’s nothing worse than crazy interview questions that make no sense!

There are certain things you have to be aware of. You have to be very good at putting people at ease. You need to explain why you are running the interview like this. Some people get very nervous at an interview. You have to treat it as if you are pairing with a colleague. If people get stuck, you should help them out.

An interview is a two way process . The candidate also gets a much more realistic idea of what it would be like being in the team. They see what it’s like working with the team and experience the development environment first hand.