This article is a guide for a passionate developer that wants not only to do his job, but also to do it well, to learn something new and to spark the spirit of curiosity and inventiveness of the people working around him.
Why have I concentrated on TDD? Because it’s a first step. It’s the first skill which distincts the code-producer from a software craftsman.
In this article I will not describe what is TDD and why it is so good. If you are reading this then you surely know what the TDD is and you are actively using this technique.
I would like to speak about why your team doesn’t use it and how to convince them.
During your career you can evolve in different kind of teams, in different companies on different projects. You can meet really innovative great teams that produce great solutions with a very good quality. And you can say to yourself “Hey, we also could use this feature/this approach/this product in our team, it should greatly improve the quality/speed/maintainability!”
But what would you do if you found yourself in a team of code-producers that are not very optimistic about difficult words like TDD, BDD, continuous delivery and other emergent technologies? It could be an experience issue or just developers who are not interested in improving things.
The saddest is not the lack of TDD but the absence of initiatives to find more progressive methods.
How to change this situation?
One method is to hire a coach who could boost the TDD, BDD, DDD, continuous delivery and/or other skills of the team.
And what if the management can’t afford to take the coach?
You can try to coach your team by yourself! It will cost only your efforts but you could also receive a lot of useful experience from this.
Bruno Boucard, the software craftsmanship coach has mentioned 4 stages in the coaching of a team:

• TDD Clean code
• Refactoring Bad Smells
• BDD
• Legacy refactoring.

Each stage takes about 2 months.
While doing it by yourself it’s more difficult to organize this process in stages, so your role will probably be to “push” and to “guide” your team into discovering all of these features.

Step 1 – preparing the ground

Ok. Let’s try to understand why the team doesn’t use the TDD.
Do they know about TDD? If the developer doesn’t know about it, coding dojos and Katas are probably the best way to understand the idea and to see the advantages of this technique.
You can organize these dojos to explain the process and stages of the TDD and emergent design. And the katas are good like exercises to gripe the principle.
But the most common situation is that developers are familiar with this technique. And even at the question “What do you think about it?” they answer “It’s really cool and efficient!”.
But later you are going to help one of your teammates and you will see that he is going to implement directly a new feature/fix a bug, and only after that thinking about the tests (if he didn’t forget of course).
While trying to understand why the devs don’t use the technique that is very efficient on theirs opinions, I asked them a lot of questions like “Why didn’t you do it in TDD?” and the most common answers were:
“It’s not adapted to this task”
or
“It’s just a quick fix, I don’t need to do a TDD here”
or simply
“Ah, I didn’t think about it” – this one is the most frequent.
I’ve been able to distinguish three of the most common reasons of these situations:

1. The developers have a (false) impression that it takes more time to do the task using the TDD than without using it
2. The developers have no reflex to use it. They really don’t think about it when starting doing the task
3. Not testable components block the process

Step 2 – planting a seed

What is the easiest way to show that it’s more quickly to do tasks with TDD?
It’s a demonstration!
Why does it faster?

1. Using resharper automatic code generation and refactoring modules, you can go much, much more quickly!
2. Emergent design. When you are developing from-usage then the solution is clearer in our head.
3. Use your IDE on 100%! Hotkeys, code analysis, templates!

One of the best way to show it is pair programming! You can concentrate on one task and on one developer to boost up his performance and to share how he can earn time while using the TDD.
So pair-programming is an habit that you should have in your team.
And what about reflexes? From my experience the only way to adopt instinctively the usage of the TDD is repetitions and exercises. Doing it again and again until automation. The developer shouldn’t even ask himself “Can I do it in TDD?”. It should be a natural reflex.
All the methods that I’ve mentioned are also good for this purpose: coding dojos, katas, pair programming.

Step 3 – fertilization

Pair programming is a really good thing, but you can meet a new problem while using it – it’s time. If you have 4+ developers in your team then you will spend all your time pairing with them.
Another way to do it is mob programming (http://mobprogramming.org/).
Mob programming is working together with 2+ people on a single real task. There is one driver with a keyboard turning every 10 minutes. The rest of the team is guiding the driver, discussing the solution AND (the most important), discussing the techniques to use and sharing knowledge.
Mob programming is something between pair-programming and coding dojos and it combines the advantages of both of them:

• Working on the real task will help to see the deadlocks of the teammates and you could resolve them together. For example – how to do the TDD on not testable components like IO.
• Sharing knowledge of the project
• Sharing techniques and hotkeys. After correcting 2-3 times how the driver is doing his code, he will remember the hotkey and he will use it later.
• Forming a common developing style for developers. It will help you to better collaborate as all the code will have the common style.

Step 4 – growing a tree

What’s next? Should we stop here?
No! It should be a good start to trigger your developers and there are a lot of ways to continue guiding them and develop yourself:

• Share the conferences/meetups to learn something new together and to look how the other teams do. It will enlarge the field of vision of the team and it could be the source of new ideas.
• Go into a better collaboration with your client/BA team with BDD. It will also boost your team equality. One developer is not only dedicated to write the code but also to challenge the requirements to find the best solution.
• Brown Bag seminars is another great way to discuss interesting subjects while taking your lunch break. Here you can discover something new for you or discuss a new feature/technology/library etc.

 
In the closure I would like to say that this role requires a lot of efforts, patience and time but not only your team will learn something new but it will also be a great experience for you.