The other day I saw a presentation by Dan North on Behaviour Driven Development.   I’ve seen some presentations previously on this, as well as having read loads of articles and posts.  As ever, there is little to disagree with, really. On the surface It all makes sense and the ideas are reasonable enough.  There are, of course a number of quite significant omissions in BDD – and if you’re not a developer some basic realities of life tend to get washed over somewhat.  This might not be a problem as such – merely an indication that extra techniques and activities need to be happening outside of BDD to make it work.  That’s fine by me, although some people do insist on getting very emotional and defensive if you dare to start suggesting that agile methods don’t give you everything you need.

BDD is, by Dan’s admission, something that came from the developer community (he himself is a developer) and therefore the developer viewpoint tends to prevail.  Having been a developer myself, I can spot a whiff of the ‘nobody-else-exists-except-for-developers’ syndrome from miles away. Development is the kind of activity that leads to a certain degree of selfishness: Even I found myself lapsing into it sometimes, despite the fact that I was never a typical developer (having come from an analytical background), coupled with the fact I always deliberately try to have as open a mind as possible about techniques and methods.  Dan states the need to ‘reach out’ to other groups in the industry – such as analysts, project managers etc. and ’get them on board’.  Quite how, isn’t explained, though.

The presentation began, as presentations of this nature inevitably do, with a look at the horrendous ‘traditional’ ways of doing things using ‘linear’, ‘upfront’, and ‘waterfall’ techniques. There was a reflection on how they never worked: Again, reasonable enough and good examples and observations were offered up.  He’s right too; or at least I think he’s right: I have to admit I’ve worked on waterfall projects that did work.  I’ve never been quite sure how it all went right, perhaps it is just the human memory selecting out the horrendous parts….  I think the answer is quite a simple one, actually.

The thing about the so-called ‘traditional’ ways of doing things, is that they weren’t created by the technology and IT professions saying ‘lets develop a really intransigent and beauracratic way of running projects that deliberately screws ourselves up’:  They came about because projects need finance – often quite alot of it – and with that comes the need to explain to finance people, banks and so on, in advance exactly what you are going to do with the quantities of other people’s money you are asking for.   With that comes the need to explain, argue, and predict. That in turn leads to ’upfront’ descriptive work.    Have you ever tried to get investment for a business proposition without detailed plans?  It’s not easy, and more to the point, if you dont have them, you’ll get shown the door pretty quickly. If you’ve ever seen Dragon’s Den you’ll have seen evidence of this…

In my view, these ‘traditional’ approaches aren’t something you can blame on IT directly. I can see how they came to be, and It isn’t a conspiracy. I blame it on arcane financial procedures and the professions around them – accountancy and the like, that force people into operating certain ways - often the wrong way.

As an aside, I finally managed to get hold of a copy of ‘Beyond Budgeting‘ not so long ago, as a result of an other meeting I went to by Craig Larman a while back.  I had high hopes for this as it seemed to offer something totally new. Unfortunately one of the central planks of Beyond Budgeting seems to be internal re-charging between departments, internal markets and so on.  Having seen many organisations degraded by this (at best, it causes barriers to be set up between colleagues and at worst the whole organisation is virtually torn apart), I find it hard to accept this. Sorry.  But it is good that people are at least challenging the traditional stranglehold that finance people have over our lives.

Back to BDD.  As I said, It’s all kind of fine,  although it still seems to suffer from the same oversights that most agile methods seem to: That is there is always a big assumption that there will be a large supply of knowledgable people inside IT and outside of in the user community to answer questions and provide detailed knowledge on demand.  If, like me, you find that is often not the case, little or nothing is offered up to help. I think to some extent this is the big paradox of the agile world:  As an analyst, I am expected (among other things) to write acceptance tests and often to know a system down to minute detail. This is fine – that’s exactly what I should be able to do. But If I create artefacts and documents to assist me in doing this, it is dismissed by some as some kind of bureaucratic folly; On the other hand, I am still expected to respond to people’s questions, provide the tests, respond swiftly to the enquiries, explain a system to top management and so on. Again, fine - but what I am supposed to do it from?  A collection of memories? I’ve never been keen on that…

The poor end-user (or ‘customer’ as we are now forced to call them) by contrast, is expected to be a font-of-all-knowledge-super-human at IT’s beck-and-call. They can easily find themselves caught between an unsupportive IT department and the fact that they themselves possibly just picked up the system and what went with it, as an accident of the job they found themselves in.

It is time to think about what needs to be done outside of agile. This leads me to a piece I wrote here about what I loosely and rather boringly call ‘knowledge management’ and some of the problems I often come up against.  It’s important to realise that much of this is driven by what developers come to me with.  At least every week (and sometimes every day) I get developers telling me how they don’t understand the system they are working on and need clarifications and assistance. Not unreasonable and perfectly understandable.  Separately the end-users often have uncertainties and questions of their own. What is going through their mind is often “why are IT asking me this?  They built the system?  Isn’t there anyone around around that can assist me in ensuring I understand it properly and am doing things right?”

In my next post I’ll explain more.

…Oh – and i’ll tell you about UTBTDD..