So who wants to join in? Joseph, Daniel - you guys in if I host it? We could make it a fishbowl discussion. (see http://leanca.mp/2012/01/formats-of-leancamp-sessions/)

I think presenting some of the principles of TDD would be useful, and count on the brain-power of the people in the room to help find useful connections. For example, the idea of small units might bear fruit when thinking about choosing an MVP, and working out what to test and how to test it.

Is it worth digging into ping-ponging and other TDD methods for sense-checking? Those might be good for uncovering business and customer assumptions.

Interesting thought. I'm still forming ideas about shared lessons but perhaps if I got down some of the aspects I feel important in TDD we might extract something.

One of TDDs key aspects is that you express in plain English the behaviour of a unit before the unit exists. What makes that even stronger is you pair on writing the test. So this forces very early on a discussion ("should it really do that?").

In TDD we also often use a ping pong style pairing. One person writes a test and then the other person has to make that test pass and so on. Again this forces discovering unknowns, as the person writing the code does not have the same mental model as the person who wrote the test.

There is a mentality of failing fast and making the smallest possible step in order to complete the test. Often to the scale of doing something very quick and dirty and improving as you build further tests.

One key difference I see is that with TDD the tests persist, and provide useful feedback throughout the lifetime of the units. Every hypothesis is validated upon every change. The tests often provide a form of documentation for people to understand how something works.

Making things easy to test forces us to change the way we build our software. It forces the principles of isolating external dependencies, avoiding coupling between different units, working in small composable units. TDD helps us discover the smells of bad design in our system.

Let's work with some specific examples to make this more tangible. I'll suggest one, but if anyone else has their own example, please share and we can go with those.

Since Leancamp borrows a lot from Barcamp, one assumption that came along with it is that it needs sponsors. Our current hypothesis is that it doesn't, but that hypothesis only became clear recently, after we'd run a bunch of tests assuming that sponsors must be included in some way. In London, we went ahead without sponsorship to get the show on the road. Now, I'm interested in testing that hypothesis in other locations.

It would have been better to spot this assumption sooner. How could HDD and TDD approaches have helped here?

This suggests to me that business is or can be considered a meta-concept or abstraction of software. And that naturally must be true if the software delivers a useful business functionality.

Therefore it seems if you adopt TDD (prevents waste due to pursuit of objectives that are built on poor foundations)

You are very likely to adopt the analagous Hypothesis Driven Business - It prevents waste to try to deliver business services to markets that have no foundation !