Archive for July, 2013


London radio station LBC celebrates its 30th birthday later this year. It has, by all accounts, been a turbulent history and radio historians amongst you will recall that the ‘LBC’ of today doesn’t really have any connection with the original station. In quirk of regulatory fate, the station lost its broadcasting licence in the early 90s to be replaced with a new service run by, if memory serves, Reuters. This service headed swiftly towards disaster and eventually changed its format and name back to LBC to avoid total oblivion. It was rare for the regulators to not renew a radio station’s licence and it is ironic they did this to one of the better ones.

Nowadays, in our wonderful deregulated radio ‘market’, commercial stations are free to do pretty much whatever they want in the mistaken belief that removing regulation unleashes a tidal wave of otherwise pent-up creativity. What it really leads to of course is a culture where little or nothing of any ambition and passion is attempted and certainly nothing that costs money. Yet good radio needn’t be expensive to do – Its not digging coal out of the ground or landing a man on Mars. It’s sad that the whole thing is so corporatised and much of the fun seems to have gone out of it. It’s all taken way too seriously.

But radio is still an amazing medium. In my option, if ballet is the highest form of dance, radio is still the highest form of electronic communication. You don’t need the Internet, television, twitter, on demand media or anything else if you can open a microphone, talk and make a compelling and interesting programme. That’s the greatest gift to have.

Bizarrely I said all of this at a party last year to someone who turned out to be very senior in the BBC World Service. He almost exploded with agreement and enthusiasm – as if he had spent the last 10 years of his life trying to get the same message across to people. Better still, he bought me a drink.

Happy birthday LBC and in the words of “Radio Ga Ga” by Queen – “You had your time, you had the power, You’ve yet to have your finest hour”

The other day an interesting debate took place at work in our regular Business Analysis meeting regarding testing, Test Driven Development and where the involvement of the Business Analyst ends and the QA/Tester’s begins.

It’s a debate that has come up many times in different guises over the years and I don’t really regard it as a problem that can be “solved” as such. Projects tend to be different from one another and people’s levels of expertise and knowldge are different. The discussion partly concerned who “owns” and completes the feature files needed for development to commence.

If you define a feature as a collection of user stories and user stories giving rise to a series of scenarios then one solution to the BA/tester divide is that the BA produces the features and User Stories (and epics if necessary which is a different topic) and the QA/Tester then augments these with the scenarios described in the automatable GIVEN-WHEN-THEN syntax. Or the BA can list out the scenarios as best as they are understood at that point and they then work together to complete them.

The latter approach is what I would favour, but in any event this is probably what has to happen simply because without wishing to sound too pompous about it, as a BA the QA/Tester only knows what you tell them. Unless you have a tester with bags of domain knowledge it simply won’t be possible to have a clear-cut hand-off from the BA to the QA/Tester. You can’t really expect them to just go off and write meaningful tests independently.

But there is a much more interesting debate to be had around what is needed in addition to the stories and scenarios to enable people to build the solution. I have encountered people over the years that think stories and scenarios are all you need. This is rubbish. User Stories are a great technique and TDD has improved things, but it’s important we don’t get carried away and drift into a fantasy world. Not every characteristic and behaviour of a system can be expressed as stories. It just isn’t possible. You need to supplement them with other techniques or you risk either being swallowed up in a miasma of over elaborate stories that will have your users and customers zoning out (one of the common problems that used to happen with Use Cases) or creating a shallow, oversimplified view of the world that just isn’t detailed enough.

Our old friend UML can help at supplementing the stories. It is unfortunate that many people still seem to insist on misinterpreting UML and believing it is a methodology, in some way at odds with the agile movement. It isn’t – it is simply a communication tool. Of course, if you feel you don’t need it and stories are all you need, then I can say is – good luck…