Once exposed to bad TDD, teams are a challenge for any technical agile coach. Instead of trying to sell them TDD, XP, or whatever, fix their pains!
TDD is a cornerstone of what we coach. Unfortunately, there is a lot of misunderstanding about TDD. Search the web for ‘bad TDD’ to get an idea. Unfortunately, after a team has been exposed to bad TDD, it won’t try it again! How can we get around this extra hurdle and do constructive technical agile coaching?
I am least successful when people, for whatever reason, are unable to hear my ideas. It may be that they were mandated to attend a training or receive coaching, or it may be that they feel none of the changes I am bringing are in their best interests. [Robin Dymond on firstname.lastname@example.org]
We’ve already gone through a TDD training before. We found it very dogmatic and difficult to apply. We prefer to sticking to what we are used to rather than to spending more time on TDD. [A developer who attended a previous TDD coaching]
My suggestion is pretty simple:
Don’t talk about TDD! Instead, use TDD to fix their pains!
The infamous TDD training
Murex, the company I work for, used to have TDD training in its catalog. Murex is pretty generous with training, and it’s pretty straightforward to attend one. As a result, many developers had learned TDD this way. Unfortunately, the training was not good.
Many developers had concluded that TDD was expensive and useless. Some even took bad habits after attending it. For example:
- Writing all the tests before writing all the code.
- Testing every function independently. This leads to heavy mocking and makes the code harder to refactor.
Forget TDD as a goal
TDD is no longer the ‘killer feature’ that sells agile technical coaching to teams.
In my case, the manager of the Deadpool team found another team for me! He suggested that I check if there was an opportunity with the Kirby team.
As you might already know, if you are a regular reader, I only work with volunteer teams. If I wanted to work with Kirby developers, I needed to find a way to make them want!
Bad TDD is dogmatic, overpromises, and under-delivers. Unfortunately, some Kirby team members had attended the infamous TDD training. I knew that mentioning TDD would play against me.
Understand their pains
The first thing to do is to understand the team members’ pains. There are many ways to identify these pains:
- You can meet with all the team to have a group chat or to run a pain gathering workshop
- You can also have one-to-one interviews with team members. This is useful if you suspect that not everyone will speak up in front of the group
- Otherwise, you can Gemba-pair: spend a few hours to pair with everyone in the team
What is essential at this step is to avoid selling them anything. Just observe, be helpful when you can, but really, observe.
In our case, the Kirby team members were having a hard time maintaining legacy code. Here are examples of pains we have seen in other teams:
- We have good test coverage and a lot of tests, but everything turns red when we make the smallest change!
- We don’t know what kind of tests to use to test the different parts of our system!
- The business is pushing is so hard that we are taking technical debt all the time. How do we find the time to refactor!
- The team just faced important turnover. How can we rebuild the team dynamics without losing 1 year?
Design a custom coaching plan
Once you understand their day-to-day issues, it’s time to come up with a fix!
Maintaining legacy code is a widespread pain for software teams. I could leverage what I had done with Deadpool to propose something to the Kirby team.
In other cases, you might be able to fix their pains without programming. If you can, then do it! You will save everybody’s time, and the team will be more likely to come back for more.
For example, we have designed a test strategy workshop. It helps team members to agree on how to test the different aspects of their system.
Other times, though, fixing the pain will involve installing new programming habits.
In this case, avoid general agile development practices coaching. Instead, come up with a coaching plan that is fixing their specific pains. For example, we used the following coaching plan to help the Kirby team deal with their legacy code.
|Bowling Game kata||Prepared kata Demo||Good TDD|
|Roman Numerals kata||Randori in Pairs||Emergent solution|
|Mars Rover kata||Randori in Pairs||Emergent design|
|Game of Life kata||Randori in Pairs||Bottom-Up (= inside-out) TDD|
|LCD kata||Randori in Pairs||Top-Down (= outside-in) TDD|
|Game of Life kata||Randori in Pairs||Mix Bottom-Up and Top-Down|
|Median of list of lists kata||Randori||TDD on algorithms|
|Roman additions kata||Mob||Mobbing|
|Gilded Rose kata then production code||Mob||Approval Testing and refactoring|
|Gilded Rose kata then production code||Mob||Strangler application|
|Trivia kata then production code||Mob||Mikado Method|
|Trivia kata then production code||Mob||ACL and Bubble Context|
It relies on a mix of code-katas and mob sessions. This is one way of doing it. The Samman Technical Coaching method uses a blend of learning hours and mob sessions. On our side, we have settled on the following recipe for most of our coaching plans:
- Start with a series of katas around TDD.
- Continue by mixing
- katas targetting pain-fixing techniques
- mob-sessions to apply these techniques on their production code
I hear you:
But you just said to forget TDD and to focus on the pain! And now you start with katas on TDD!
As a matter of fact, we have noticed that part 2 does not work unless the team has gone through part 1! As coaches, we know TDD is essential. The key is to avoid selling it directly.
TDD as a workout exercise
With a clear pain and a coaching proposal, it’s time to pitch it to the team. Here is how to present part 1.
We have different arguments to sell the TDD part to the teams:
- From experience, the coaching does not work well if we skip part 1
- Part 1 will train you to new team collaboration practices like pair and mob programming
- TDD speeds up learning by creating the deliberate practice fast feedback loop
Here is the script I use to explain what deliberate practice is and why it matters:
Deliberate practice is the technique used by athletes to achieve world-class performance. Suppose you are a swimmer and you are not very good at turning at the end of the lane. What will have the most impact on your performance? Swimming 2000 meters? Or focusing 30 minutes on turning only?
It’s the same for us. By setting up a fast feedback loop, TDD lets us learn faster through deliberate practice.
Also, no one learns to swim in the deep end of the pool. We all started at the shallow end. That’s why we will begin with simple exercises. We will increase the difficulty as we go. At some point, you will be able to apply the techniques to your production code.
(Side Note: lately, we have been experimenting with TCR as a new way to do deliberate practice. It looks promising. Tell me if you would like to read more about it!)
With these 3 arguments under your belt, you should be ready to pitch your proposal to the entire team. A good pitch starts with their pain, presents a fix, and continues with extra benefits.
Sometimes the pitch gets them all on board. Sometimes, though, the team needs a bit more time to decide. In this case, I suggest a first test session to help the decision.
Deliver a well-prepared kata demo
We start the TDD part of our coaching sessions with a prepared kata demo. We usually go with the bowling game score kata. It’s a great occasion to show what TDD looks like when it’s well done.
We must, in fact, remain very careful! Most developers are tired of being asked to be more productive. That’s why I don’t mention TDD as a way to be more whatever. Instead, I present it as a way to avoid being woken up by bugs in the middle of the night.
Attendees are usually enthusiastic about the demo. Here are examples of feedback I received:
I’m surprised about how nice and simple the resulting code is!
I already learned more in 2 hours than in the full TDD training I attended!
We’ve never had a team stop after the demo!
Don’t sell… Fix pains!
It ends as it started:
Don’t sell TDD, XP, or whatever… Fix real pains!
Next time you start coaching a team
- Take the time to understand their pains
- Present them a custom coaching plan that fixes their most important pains
- Present TDD as a learning tool rather than a goal by itself
This should get you past any prior misunderstanding about TDD.
If you liked this post, you might also learn more about how to get over bad TDD exposition in these articles:
- Wondering what a custom coaching plan might look like? Read: A coding dojo exercises plan towards refactoring legacy code
- Want to learn more other problems you might face when starting coaching a team? Check 7 tricks to influence a team resisting to change its technical habits
- Interested about how a series of code katas can also help people learn a new language? Read: How to learn a programming language in just 20 hours
- Want to get the full story of how we approached teams at Murex? Read The story about how we do Agile Technical Coaching
- Interested in live katas I gave? Watch Live Legacy Code Refactoring with the Golden Master at Legacy of Socrates
- A complete workshop for your team to see what’s a good test strategy