Expo-C and Behaviour Driven Development

I have just spent two days with a collegue at the conference Expo-C in Karlskrona, Sweden. The first day of the conference was a treat. Dan North from Thoughtworks had a whole day on the topic “Health Factors for Agile Development”. A whole day of agile discussions without one single powerpoint slide. Well spent time. Agile development, for those not in the know, is a loose collection of methodologies that in a many ways turn the traditional waterfall method upside down.

I am in some ways already using at least some of the principles of agile development. It is however difficult in a large consultancy company with its own huge methodologies for everything around application life cycle management, development and so on. Even so, I do know a few larger companies that use agile methods, that have used them for some time. One example is Iona that are big in integration. They pushed XP heavily when I last had a conversation with their recruitment departement in Dublin five years ago. Even though I have always liked the principles of XP and other agile development methodologies I have never liked the fanatical “all or nothing” message. That is why Dan Norths session was so refreshing.

Dan North seems to have a very pragmatic view of agile development. Sometimes words like pair programming pops up and it is clear that he is a fan of that. But Dan mostly push forward the importance of converting from the traditional waterfall process into a more iterative process. I think it is important not to misinterpret this as having the same meaning as iterative in RUP for example. In mastodont methodologies like RUP iterative is more about splitting large projects into a managable chunks – or releases. That is not being iterative.

Maybe the most important message is that agile development really is about communication and trust. That is what it boils down to. As Dan put it – “if possible; send email instead of documents, use IM instead of email, call instead of sending email or walk over to the other guys desk instead of calling”. Bring communication as close to the people involved as possible. This is hard in an organisation or in a consultant/client situation where there is no trust. Most documentation in traditional projects don’t really have a clear receiver. It is only used in the blame game that follows a failed project. When you trust each other, and work together towards a solution, problems occurs more seldom. Development, if you think about it, should be all about collaboration, to work towards a common goal, and having fun doing it.

Later on I might write something more on BDD, Behaviour Driven Development, which Dan North spoke about in a smaller session the next day. BDD changes the terminology slightly around Test Driven Development in a way that I think makes this more acceptable to many developers.