Exercising TDD with a Scrum team

Quite recently I was in charge of TDD exercise for a Scrum team at my customer. Some team members had quite extensive experience about TDD, some didn't have any experience at all. I find the setting pretty interesting and eventually the exercise turned out to be more about team building than about TDD.

Every developer has their view about development cycle (coding, compiling, testing etc) and people tend to stick their own way - even when told to try something different. Here is my setup for the exercise:

Goal

Team to learn apply TDD

Duration

2 days

Preparations

• Reserve a laptop with empty Eclipse project, JUnit configured
• Reserve a meeting room for the days
• Team available for the days
• Material for exercise

Execution

• Marko will give the exercise and answer any questions about the problem at hand (10 minutes)
• 2 developers will pair at the laptop, rest of the developers will review the implementation all the time
• We will check up the status every hour together, we can change the pairs if team is feeling so

Rules

• Implementation pair will all the time say out loud what they are about to do and then do it, THINK OUT LOUD
• Do The Simplest Thing That Could Possibly Work
• Everything MUST be implemented test-first
• Remember You Aint Gonna Need It
• No more than 10 minutes design allowed (whiteboard)
• Reviewers can only ask question "Why are you implementing it like that?" or similar, reviewers cannot tell what the implementing pair must do, decisions are done at the laptop

Changing pairs early on really helped as less experienced TDDers saw the more experienced TDDers in action. Team felt exhausted after the first day and there were some questions in the air about productivity of the approach compared to other approaches.

Second day was a bit different. Tests were slowing developers down and design issues became obvious. Parts that were not refactored early on started bugging developers so atleast one of the goals were achieved: team noticing that refactoring is a must. Another interesting finding for the team was that the pragmatic approach of "not thinking too much of a head in the implementation itself" requires great discipline in planning the tests in first place. Soon team started questioning themselves: "So what should I test exactly and why" before coding anything at all.

Sometimes team found themselves stuck on algorithm design and we had to call timeout every now and then. I think it is very important to have the facilitator telling the team that "now the time is up, lets try to test first, code and then see if the design is good - if not, then we atleast know a bit more about the problem".

After the second day we had some working software and every team member had tried to do TDD. Some members had questions still about the productivity but everyone agreed that TDD with merciless refactoring can lead to good designs (once you also do "refactoring in the large" at whiteboard). However, doing good test cases is hard for beginners as they probably are not too much familiar with mocking nor thinking test-first.

Interesting exercise - I as a coach learned also quite a bit how to improve guidance and handle different people during the exercise - we are in people business after all.

Are you interested to learn more or even have a TDD exercise for your developers/team? Do not hesitate to contact me if you are :)