5

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?

  • 1
    Maybe its a good idea to ask a similar question to actual programmers on programmers.stackexchange.com . If you turn the question around a bit, how could you be motivated by an external to embrace TDD and CI? – Niels van Reijmersdal Dec 10 '14 at 9:31
  • What's the business value to you or your organization to encouraging this adoption? I know the answer from my own perspective, but you'll get better answers here if you can articulate the value from your perspective. – Todd A. Jacobs Dec 12 '14 at 21:14
  • It is a possibility that some programmers who are competent in writing new software and/or troubleshooting bugs in source code might be less competent in setting up software, editing configurations or watching over daily automation reports. I'm not saying there is an inverse correlation - what I'm saying is that the two skill sets might not have any correlations whatsoever. If this is the case, be prepared to look for helping hands either within the team or from other teams who can get through the initial hurdles. Keep in mind that programmers are still responsible for continuous maintenance. – rwong Dec 24 '14 at 20:57
5

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

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
  • Good answer by Niels. I don't have good answer but if possible one can have the matrix with bugs reported by QC team before and after following unit testing. That will help developer that they can figure out issues well before anybody else can point out and they can fix it much before they are caught by QC. – Tabrej Khan Dec 11 '14 at 12:13
  • @TabrejKhan to add what? :) – Niels van Reijmersdal Dec 11 '14 at 12:15
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.