If you’re using Selenium to test your application then you’re being lazy - he suggested that we need to define an API to make our application testable without having to go from the UI. I’m not sure where Javascript testing would fit into this - perhaps using a Javascript unit testing framework would be preferable. We had a similar discussion about acceptance testing at the Alt.NET conference in London earlier this year. I think there is still value in using Selenium to at least test the happy path cases of our application, with edge cases being tested further down.

I’ve never worked on a 5,000 person project but it felt to me like a lot of the ways to make this work were very waterfall-esque in nature. He spoke of Architecture Driven Development which sounded like it was drifting towards being big up front design although with a team this large clearly quite a bit of architecture up front is going to be needed to allow progression. My (perhaps naive) question is why do we need a team with 5,000 people in it?

He spoke about Planning Poker as a way to get more accurate estimates for stories - I think he suggested a 30% improvement could be gained by doing this. Fabio and Jason previously wrote about their experiences of using this technique on their projects. Other ideas around estimation included having a best - worst - likely case and that’s not possible then at least a best - worst case. This is something we have done on a couple of my recent projects and it works reasonably well in helping to identify potentially risks.

One of the questions asked at the end queried the value of test driven development. Dave’s response spoke about testing soon rather than first and he said he wasn’t a fan of testing trivial things like accessors. I wonder what exactly is considered trivial beyond that though - I have often written code which seemed like it would be trivial and I still made mistakes which wouldn’t have been caught if I hadn’t written the test first. He also spoke of an Object Mentor competition they sometimes hold whereby you present your 'untestable' code and if the Object Mentor guys can’t show you how to test it then they’ll buy you dinner.

He spoke about needing to perform a lean transformation on an organisation before attempting to introduce agile practices. The idea being that you cannot change productivity and quality alone, XP/Scrum are not enough. This obviously is following the organisational transformation approach to change which has heavy backing from people at the top of organisations. From my experience, we tend to take the other approach of introducing agile at the project level and showing the improved productivity we can achieve by using this approach. Clearly not on the same scale as Dave Thomas and co. though!

It was interesting that the most important and therefore first thing that he considered vital to successful delivery is having a continuous build server. Without this you can’t build quality into the application as well as the fact that you never know if it actually works or not.

He spoke of the idea of considering areas of organisations that we cannot change as being an API - you can’t step across that boundary, you just have to live with it. He gave the example of systems that our application may depend on - we can’t influence how they choose to develop their code but we can provide acceptance tests that they must pass. How these are passed is not up to us.