Last month I was press-ganged by a bed-ridden Andy McLoughlin to talk to the London Facebook Developers Garage about Huddle’s launch on LinkedIn last year. Very short notice and a packed schedule that day meant no time to prepare slides - well, PowerPoint is overrated anyway.
See here for a (5 minute) report on the January event, and here to find out what I had to say (10 minutes).
At Huddle, we run two week agile development iterations, and each iteration is a potential production release candidate. That means that the code developed is of a quality that could be released to production, but it may or may not make sense to do so from a product perspective. For example, when we developed the new meetings functionality within Huddle, the development of the initial release spanned two or three iterations, and to release after the first iteration would have meant releasing an unusable product: you could create a meeting but not delete it. Production ready refers to the quality of the code (meeting creation was implemented, tested, code reviewed, refactored etc.), not the completeness of the product.
So the two week iteration cycle means that we have the option to release every iteration, but we do not always do so. (more…)
In my previous post I mentioned that like most agile adopters, at Huddle we would describe our process of a “blend of XP and Scrum”. Expanding on that a little, I would say that Scrum has formalised the process side of agile and with a few exceptions (terminology, iteration length, and handling mid-iteration change) our agile process looks very like a Scrum implementation. XP on the other hand has much more to say about engineering practices (Continuous Integration, Test Driven Development, pair programming etc) and we draw guidance on development practices from XP.
Which brings me to the subject of this post: Test Driven Development. For me this is an essential, and often ignored, part of the deal with implementing agile development. Test driven development has many much discussed advantages, but for me there is one killer argument for TDD at is goes like this: