024 Getting the Whole Organization doing TDD

Last episode, we talked about how to get a team to do TDD, meaning to use micro tests to grow their product code. Getting one team to do it is helpful as it creates proof to the organization that it’s not only possible but quite valuable. But the next step is how to get organization wide adoption. Without organization acceptance, a team that is doing TDD can be screwed up by changes in their management or PO. This happens all the time. A team has learned something valuable in a grassroots sort of way, and then management changes, doesn’t understand what the team is doing, and steps in and stops it. So getting an organization to adopt it creates a future proof for TDD and it becomes part of the companies culture, hiring policies, and career path. So after a team successful shows the value of TDD, it’s time to operationalize it.
Step 1) Educate the Top
Include management, architects, and POs in the change
Management needs to be able to understand TDDs cost and benefit so they won’t step in or influence it in a negative way. Nothing developers hate more than feeling uncertainty that they’ll get “yelled at” for doing TDD. The challenge between teaching management, architects, and POs is that these three populations have entirely different needs and ways of viewing TDD so the messaging, the goals, and how technical the conversation must be various greatly.
Step 2) Grease the Skids
Developers need to learn how to use a unit test library, how to refactor code, how to setup a continuous integration server, and how to build a design using test first. All these things take effort and will initially slow developers down. Even if management is on board, the developer population will accept or reject the TDD notion on their own. Although not everyone needs to be onboard, a critical mass of 40-60% of the developers on each team need to be open to giving it a go in order for team adoption to take place. Adding in learning incentives for a couple of years goes a long ways to pushing the “undecideds” of the developer population into giving it a shot for a few months, which, based on my coaching work, will be the amount of time to go from TDD novice to proficient.
A good implementation of this that I saw was where the VP allocated a bonus for each developer, and the team lead was responsible for defining challenging yet attainable goals for doing TDD. In this case, a target for the number of micro tests was set. Like the 40 in 4 challenge mentioned in the previous episode, this target should be something that takes 2-3 months so that the developer, upon reaching the goal, is proficient at TDD.
Step 4) Set a standard
Set a standard that will act as a “floor” to the teams’s definitions of done. A convenient way to make standards visible and easier to rollout is through Continuous Integration. Here is an example:
have a continuous integration server
the server must execute and make visible the compile step
the server must execute and make visible micro test execution
the server must execute and make visible the code coverage from micro tests
the sever must execute and make visible the macro test execution
you can’t ship with failing test cases
the server must execute and make visible the design debt
new code bases must have 90% code coverage
The last bullet is difficult because for large legacy code bases, it will could take years or even decades to reach 90%. But all the excuses fall away when it comes to building brand new code from scratch. New classes added to a legacy code base should have very high code coverage too, but it becomes difficult to implement that check with a Continuous Integration server.
Step 3) Sustained System
Hiring policies need to be explicit around targeting people who either already are proficient in TDD or who are already open to learning it. It doesn’t make any sense in this day and age to hire developers who are anti-TDD. Such a hire will only cause stress with their fellow developers and add’s negative weight to the organization. So make doing TDD and Pair Programming part of the interview process. In organizations with salary bands, include test automation and refactoring as part of the levels.
​