How to get a dev team to use TDD and CI?

Question

I'm a software development program manager who has experienced many of the benefits of test-driven development and continuous integration. But some of the dev teams I work with don't follow these practices. It's not my place to tell them how to do their jobs, but how can I encourage them to adopt these practices without overstepping the bounds of my role?

Answer 1

Lead by example. You can't force people to do what they don't believe in, particularly in your role. But if you work the way you believe is right, and if you quietly show results, then you should eventually win people over to your side. Don't force anyone, simply work in the way you believe is right, mention your positive results, and if they are interested then show them more.

I first realised the power of TDD when one of my team insisted on doing it for his own work. I thought he was wasting time, but I trusted him enough to let him work the way he thought best. Then one day he showed me dozens of bugs he'd found in our software and quietly corrected. He'd found these because he wanted to check the behaviour of the code he was working with, written tests for it, and found holes. He didn't convert the whole team at that moment, but he did convert me. I'm sure he did it for other people, too... just quietly.

On a related note, see this video from Dan North, and in particular story #3, The Coach. http://www.infoq.com/presentations/interactions-career

Answer 2

In my experience this is a process of years. Developers who do not practice "Quality Build In" in their daily process will see it as extra work. They rather be programming...

Quality Build In

Lean manufacturing companies will have quality built in their processes as much as possible. By building quality into your process, you prevent unnecessary rework and scrap. This means that your machines are capable of detecting abnormalities (jidoka) and your fixtures have mistake proofing to avoid mis-assembly (poka yoke).

Management commitment

From my perspective this should be management vision, they should communicate to these teams that this is what is expected from them.

Keep in mind that automated testing adds extra effort in the short term, while being really agile and lean on the long run. Developers time will be spread around 33% requirements, 33% programming and 33% automated testing. This will slow the team down and this might be a issue if management is not in on this.

• Explain why this is a good practise
• Give the team time to experiment with it, writing and running automated tests
• Set realistic goals for code coverage increase per release/cycle

Answer 3

A Results-Oriented Approach

I'm a software development program manager who has experienced many of the benefits of test-driven development and continuous integration. But some of the dev teams I work with don't follow these practices. It's not my place to tell them how to do their jobs, but how can I encourage them to adopt these practices without overstepping the bounds of my role?

While you may not be in a position to dictate good work practices, it seems likely that you are in a position to drive a results-oriented approach. Generally speaking, TDD and CI are practices that are designed to reduce defect rates, and that should be your focus.

As one example, you might draw up a pie chart showing how much time is consumed fixing bugs rather than doing greenfield development on new features. By making the defect rates a visible cost to the developers (who will generally prefer working on new features to fixing bugs), you create an incentive for the developers to inspect-and-adapt their workflow.

This isn't a question of "holding people accountable." Rather, the goal is to create a causal link that helps the developers see the natural consequences of their current development practices. This may be all that's necessary to invite change.

Note that at the end of the day you probably shouldn't care whether they're writing software using TDD and CI, or writing code on stone tablets using cuneiform. What you really care about is software quality and efficiency of delivery, and you should definitely maintain reasonable targets for both of those things. It is then up to the development team whether they want to do things the easy way or the hard way; you can provide guidance if they'll take it, but you have to let some people learn by making their own mistakes.

Focus on tangible results (e.g. defect rates or feature lead times). Set reasonable objectives for your projects. Challenge your teams to improve their processes or toolchains when they fall short of reasonable expectations. You can't protect people from themselves, but you can encourage professional growth, especially if you're providing the time, money, and equipment necessary to implement real process change.