Connect
023 GETTING THE REST OF THE TEAM DOING TDD
Like the TDD IT drama performed on episodes 14 through 22, once you’ve one person with the ability and drive to actively do Test Driven Development, you’ve got a spark. We’ll review some of the steps that Vanilla Pop used in getting his team to do TDD, and also add in a few more tips that I’ve found work very well.
STEP 1) FIND A SPARK
Find someone who is of a flexible mindset and senior enough to influence others and get them actively working on learning to do TDD on sample code, and then on the code used at work.
Another strategy is to hire a developer who does Agile software development, often referred to as an Agile Technical coach or XP Coach, to join the team for a few sprints. Agile coaches like myself l, have been doing TDD in various languages and in a full stack fashion for a decade or two, so it’s not difficult for us to start transforming your team and code in a few days.
STEP 2) FAN THE FLAME TO FIRE
Active Learning on the code your team writes for work
Teach each individual developer how to do TDD on their user stories. Get your Spark busy for a few Sprints par programming with your developers so they are mentored into how to solve their micro test challenges. There will be a few at challenges at first and design patterns will be learned to remove or change the problems in your existing codebase so that micro tests can be more conveniently added.
reduce release pressure in order that each team member can take more time to learn something as they deliver a feature. Examples: have the team decide to do fewer stories so they deliver micro tests for the code that they deliver. Another way is to select one story to do TDD on by pair programming with someone else, and then the next sprint do the same until everyone has done some TDD on their usual work.
40 in 4 challenge and the danger of the forever beginner
Socialize what your team practices by talking about micro test achievements during standup. (Refer to TMobile standup).
STEP 3) BUILD A FIREPLACE
Get management support
start talking to them about a vision of doing TDD on all production code. Select a time two months in the future when the team will discuss making the TDD practice mainstream for product code.
Making Transparent micro test production
make visible the number of micro tests being created day by day. And talk about, no brag about how many micro tests were delivered during standup. Continuous Integration Servers with a visible dashboard are ideal for this.
stop complaining about writing automated tests. Developers quickly blame the “new thing” for slowing them down. This doesn’t really make anything better. Everyone already knows that learning will take time. It is usual and expected that the team will slow down for two months as they develop this skill. It makes no sense to complain about something the everyone knows will happen and this just makes managers upset that their team’s are upset. My advice is to get over this and focus on the positive aspect of learning a new skill by sharing with your other team members what you learned by going slower. Later you’ll be able to go faster, but you can’t just jump to “going faster” without learning.
Talk about your micro test production during Sprint Reviews so your team members know they will be held accountable for producing durable value, and the stakeholders learn about the team’s new process.
STEP 4) MAINTAIN THE FUEL
The Team’s Working agreement should be to always address failing unit tests as priority one. The only thing more important would be a production problem. When a build fails, someone or a pair must stop what they are doing and resolve the failure.
New code that is added without unit test should be deleted as would any code that fails code review.
Pair Program on all product code (Define production code.)
If two months have passed and the team still having problems with regressions on new code, retrospect on this as this can only happen when failing to create adequate micro tests and points to developers not following the process.
The expectation should be that after 6 months of starting a TDD initiative, regressions should rarely happen, or be greatly reduced if there is a lot of un-tested legacy code. The trend in the bug tracking system should be consistently going down.
It’s been my experience that after one year of doing TDD on a legacy code base, a bug tracking system is no longer necessary other than as a workflow system between support and development. The inventory of bugs should number in the single digits.
Freesound.org Acknowledgements: DudeAwesome
FIND ALL THE EPISODES FOR THIS SERIES AT THE SERIES PAGE.
