Delayed Value

Having my last look at the board today, I found it interesting that we have work items sat in the “Ready For Production” column. The total items in this has grown over the last couple of weeks – we now have 7 items ready for “Production”.

These items all have a varying level of “Business Value” (value) associated with them – but are sat in the system. They are all blocked by the same thing – the legacy system has a quarterly release cycle.

This poses a couple of questions:

  1. Is there a threshold before the amount of value being delivered outweighs the cost of putting that value live?
  2. Should every single piece of item developed be pushed live as soon as it is ready – therefore giving you an instance ROI?
  3. Are the items of high enough value to the customer if they can just sit in the “Done” column for a couple of weeks?
  4. Do the customers have visibility of what is “Done”?

My gut feel is that the first question is a cop out – the cost of pushing things in to a live environment should be minimal because you should really have seemless CI. It should be of no extra cost to put code in to a live environment. If it costs – you need to spend time & money on improving this build & deploy system. This is an Internal Quality as Martin Fowler puts it.

If you push every single piece of work live you need to have customers who can accept a constantly changing system. This maybe difficult but I think it depends on what you are delivering – i.e. defect fixes, and minor enhancements could be dropped in at any point. With large changes in functionality – it depends on how involved the customer has been with the development. Here we probably can’t do it, because the customer is not overly involved.

The above statement probably answers the last two questions as well. It’s all about the customer deciding on what to develop – this way they can decide upon the items with the highest value. They also know when items are complete.

This is one of the 4 principles in the Agile Manifesto – “Customer Collaboration”.

BDD – Initial Experiences

I’ve recently discovered BDD or rather there has been an increase in communication about this topic around me – someone mentioned Cucumber at XPManXL!

I found the extremely well written Cuke4Ninja site, and started to discuss Specs more with my colleagues. Jason highlighted that SpecFlow seemed like a good implementation for .Net development.

This all seemed to align with both Gojko Adzic at Agile Yorkshire which I unfortunately missed, but made up for with attending XPManchester where John(no) gave a presentation/discussion about BDD for his Masters… He asked us to implement a Chess Kata using some features which he has developed – these can be downloaded from GitHub.

I spent a bit of time trying to implement the features. My first experience of BDD! I found it quite overwhelming initially with all the specs running. I.e. I had quite a lot of specs/tests running and didn’t know where to start.

Retrospectively I should have included a single feature – implemented it till green and then incrementally added features as I went along. This is something I am going to do on my second attempt. I plan to throw away my initial code and start again. Although I’ll probably use a similar design I’m interested to see how after my initial attempt how it will differ – will it be better design?

Initial thoughts are that features are a way to have a shared vocabulary between developers and business users. I also think that they are the Acceptance Criteria which are usually written on the back of User Story cards.

I’m also slightly confused at when to start delving deeper from high level features in to say lower level “Behaviours/Features”. This I’m sure will become apparent as I spend more time using BDD.