TDD Workshop

I recently led a test-driven development (TDD) workshop for the team that I am currently coaching. We’ve been working together for several Sprints (every Sprint bar none has resulted in valuable functionality that has been put into production). We’ve previously looked at unit tests in detail and I had made a strong recommendation to try to write the tests before the code under test. Over the last couple of Sprints, the quantity and quality of unit tests in the product has increased dramatically.

One of the outcomes of our last retrospective was that the team requested that we revisit the area, this time focusing on TDD. So I scheduled a couple of hours for a workshop.

I kicked the workshop off with a few slides to explain the philosophy behind TDD, explaining that TDD is not just about testing (or even mainly about testing) but has a great deal to do with design and documenting what services the code provides. I found a quote from Bob Martin that I really like:

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”.

The introduction led to an extensive discussion about the pros and cons of TDD. In this type of situation, I’m not looking to convince people that a particular technique is valuable (you can’t make people believe in something) but to get them to try it out and then reflect on whether it works for them and the team.

I fired up Eclipse and went through some examples (based on material from Frank Westphal’s excellent book Testgetriebene Entwicklung mit JUnit und FIT).

By the end of the workshop, everyone had agreed to give TDD a try in the current Sprint. As normal, we’ll reflect on our experiences at our end of Sprint retrospective.

On Key

Related Posts

man in gray sweater standing in front of his colleagues

The Three Pillars of Scrum

Scrum “by the book” is very simple and it’s a great place to start, but teams that want to get outstanding results understand the journey has only just begun. The three pillars model can help your team on this journey by allowing you to maximise the effectiveness of each part of Scrum.

The three pillars of Scrum are transparency, inspection and adaptation. They can be used to “inspect and adapt” your Scrum implementation and set you and your team on the path to really excellent Scrum.

measuring guitar pick

Can Agile be Measured?

Measuring Agile Transformations Organisations run their agile transformations with teams staffed with trainers and coaches. They often track the progress of their work through the

Scaling Agile Meetup

We’ve moved our Scaling Agile Lean Coffee to the platform. You can join the group here:

The upcoming events will be published in the group. At the time of writing, the next event is 12th May at 18:00 BST, 19:00 CEST. There is always a lively discussion so why not bring your burning topic on agile transformation or scaling agile to the group? It’s free to join.

Register your interest in ELCAS-approved training with ScrumCenter