Claudio Lassala's Blog

“Any tips for getting your Scrum team on board with practicing TDD as a team?”

Yes!

• It starts with the individual
• Lunch and Learns
• Try it with one small story
• Code Review
• Ping-Pong Pair Programming
• Divide and Conquer
• Book Clubs

Expanding each of those points…

It starts with the individual

A few common situations that prevent teams from adopting TDD include:

• Can’t make time in current project
• Legacy system that makes it very hard to practice TDD
• Team members not willing to try it
• Lack of support from the business

Those situations should NOT prevent an individual to do it.

Practice TDD on your own time so you can build your skills.

If others see you do it, they may join you. If they do, great. If they don’t, you are still growing.

Lunch and Learn

If you decide to take it on your own, offer lunch and learn sessions for your team to share your experiences, struggles, successes.

The purpose is not to wait until you become an expert; share it as you learn.

Make it a recurring meeting.

Write down ahead of time the things you’d like to share (including how and why you failed, and how you’ve overcome it – or not!).

People aren’t showing up or look uninterested? Consider putting it out as blog posts. Why? There are always people out there who will relate to your struggles and successes.

Try it with one small story

Pick one small story, or a small piece of a story, and commit to doing TDD.

You may fail (many times). You may succeed. Either way, share your findings with the team:

• was it taking too long?
• Why?
• Lack of knowledge? Practice?
• Difficulties with the legacy code?
• What kind of difficulties?
• Too many dependencies?

Work as a team to figure out how the hurdles could be overcome.
Your weaknesses might be someone else’s strengths. And vice-versa.

Share the experience at the sprint retrospective. Figure out the next step and commit to it.

Code Review

When doing code review, start by reviewing tests/specs.

When writing tests first, consider asking for a code review before implementing it, to make sure you have a good understanding of the problem that needs solving.

During that review, share any difficulties you see. The reviewer might know how to help you. And if not, you may find a clear path ahead of you just by articulating your thoughts and sharing it with someone else.

After done with the implementation, ask for another code review. This time, maybe share how you’ve addressed the difficulties. Also, maybe discuss ways how the test code could be improved.

Ping-Pong Pair Programming

Consider ping-pong pair programming: one person writes a test, the other one writes the implementation. Then swap.

Set a time-box. Do not let interruptions get in the way.

Let others know what the pair is up to so they can help avoid interruptions during the time-box.

Share the lessons learned with the team.

Divide and Conquer

Work as a team.

Divide the challenges so that each team member can focus on learning one thing, and then share the findings with the team.

Here are some ideas on what to learn:

• Test frameworks for the tech stack
• Testing legacy code
• Tools such as Cypress.io, Cucumber, SpecFlow, Selenium, etc.
• How to test code that makes heavy use of libraries or frameworks such as Angular, React, Mass Transit, etc.
• How to write better specifications in Given-When-Then

Book Clubs

Run book clubs!

Build knowledge and skill together as a team.

Choose a book that seems to fit the team’s current skills, set a cadence (maybe once a week during lunch breaks?), start reading, and discuss the findings together.

Here are a few books you may want to consider: Recommended Reading on Testing

In Summary

I have used all of these techniques. Still do.

I pick and choose whichever one works better depending on my current situation. Sometimes the one I pick doesn’t work on a given team. I drop it, and try another one.

Whether the team thinks of TDD as Test Driven Development or Design and whether they use the terms test or spec, that depends on the team’s maturity. Different people, different backgrounds, different ways to learn.

It all starts with one person. Do not wait for that person. Be that person.