TDD from a Manager's Perspective

This blog post was originally published on the ThoroughTest website, back when that was a thing. As a co-founder and primary content contributor for ThoroughTest, I absolutely own the rights to this post and the source code to which it refers. I intend to reproduce each blog post here on my personal blog since the company is no longer in business. This post in particular was actually written by a guest writer, Adam Johnson. He was a great manager I worked for previously and he graciously accepted my request to have him write a post for us.

Test Driven Development(TDD) is hard. It is hard from a developer perspective and it can be even harder from a manager perspective. Not only does a manager need to help drive TDD within team members, they also need to ensure the management chain above them understands the benefits of TDD.

Helping a team strive for test driven development is a slow process. Each developer will progress at their own pace. There will definitely be push back about "how hard it is" and "why are you making us do this" but being consistent in the message is key. It needs to be a collaborative effort when working with your team, not a top down mandate even if it is perceived as much. It will take numerous peer/pair programming sessions to help nudge team members in the right direction. It is important that proper peer programming is done, not a solo driver like the TDD expert on the keyboard for the majority of the session. Having a TDD champion that is a team member also helps drive the message home with the team. Working in concert with the manager, they can help other team members start down the long process of doing test driven development.

The long process not only occurs within the team, those outside the team also need to understand it is a long process. It really starts with the team's manager. If that person doesn't buy in to the benefits of TDD, it will be a long uphill battle trying to drive TDD within the team. After the immediate manager's buy in, the product owner and product manager will be the next to convince of the benefits of TDD. For a new team starting out with TDD, this means a slower velocity than what they previously had. In fact, any kind of metrics used by the team will change as it will take time for new members to get TDD. This is where the manager of the team needs to push back. It requires a manager willing to take all the heat to ensure the team is producing quality code and continually improving as they go through this process. There will absolutely be questions about why the team slowed down or why did this release not have as many features but once that release goes out and the total cost of ownership goes down due to the increased quality, the outsiders will start buying in.

The development manager needs to be consistent in the message to the team and the message to those outside of the team. Whether you are 1 day from releasing or 100 days, that hard process will get easier with each passing day. By delivering a consistent message and understanding that it is a long and hard process, the benefits will soon come to light not only for the team but for the entire organization.