This weekend the company I work for had a “competence weekend”. This is something we do 3-4 times every year. We go to a hotel or something like that and teach each other stuff. This weekend, me, Chris and a guy named Marcus talked about Agile development in general, and TDD in particular.
Marcus kicked of everything by doing a presentation on TDD, on the why’s and how’s of it. It was a nice presentation, although not quite polished yet.
Then me and Marcus pair programmed together for an hour, showing how PP and TDD work together. Chris had prepared an assignment, and he discussed with the group what we were doing. I didn’t feel that this was very succesful – I’ve worked so much with Marcus that we don’t need to talk very much when we work together. 
Unfortunatly, this meant that we didn’t show the team how important communication is during pair programming.
After lunch we had a long TDD/PP session, where everyone was paired up, and given an assignment. It was a chance for everyone to try the theories for real. It was a great success.
The next day, I had planned to give a short presentation on how everyone can use agile techniques on any project, but I was getting sicker and sicker, so Chris stepped up and did it instead. After the presentation the whole company had a long discussion about Agile design. Like always when you are discussing methods in theory with people who have no experience of the methods, the arguments got heated, and soon we stopped listening and learning.
Things I learnt this weekend:
1. Stop talking long before people might start feeling hurt or run over.
2. When you demo TDD/PP, be loud and clear, like a cartoon character.
3. I really like where I work.
Agile Software Construction
Another very smart architect at work who happens to have my first name who is a believer in agile methods has been busy championing the incorporation of SCRUM into our lifecycle. I wonder if I could convince him to speak with others about dropping Th…
Left by Thought Leadership on December 19th, 2005
[...] One of the cool things about Dotway is that we have these “competence weekends” three or four times a year, where we go away to some hotel and geek out about something more or less of technical nature. As Andrés mentions recently we spent a weekend learning about TDD. One of the things that we discussed was how to test code that is not public. Normally you place your tests in a separate assembly and reference the production code. However, that means you need to make types and members public to be able to test them. So if you want to keep the implementation details hidden (with internal access level) you will need to have the tests in the same assembly as the production code. That brings further challenges in setting up the build environment to create different builds, since you naturally do not want to include the tests in the released code. [...]
Left by Unit testing internals on October 4th, 2006