The ticket moves to “Dev Done” but there are no unit tests and the code hasn’t been reviewed. When challenged the developer says “That’s because I don’t have time for that stuff”. If I hear that I want to know why they feel they don’t have time, then I give them the time.

There are only three categories of people that can steal time from a developer:

• You
• The developer
• Other people

You

Managers are often concerned about productivity. And activity related to quality, like code reviews and automated tests, seemingly slow the developers down. So it is easy to discourage that activity and go for productivity.

That might be you.

Well, just stop. Sacrificing quality for productivity is a very short sighted strategy. Poor quality bites back and the developers end up going slower. You need them to go fast so don’t stop the processes that allow them to go fast.

The developer

Some developers pick up unspoken messages from management types and take it on themselves to increase throughput by sacrificing the quality activities. They are not trying to do a bad job. Quite the reverse. They might be trying to do you a favour because they know you are stressed about productivity. Or they might just be trying to get a User Story finished for the end of a Sprint.

When you notice this behaviour then have a quiet word with the developer concerned. Give them the psychological space to do the right job. Reassure them that although concerned about productivity you are more concerned about maintaining quality. Or reinforce the entry criteria for “Dev Done” and that cheating isn’t allowed, even at the end of a Sprint.

Other people

Other people can also steal developer time. Usually management types. Whatever the reason for this you need to shield the developers from further interference.

Managers outside the team might be more or less explicitly discouraging the quality activities in favour of productivity. You need to set the managers straight about that particular tradeoff.

Managers are also sources for non-project related work. Business as Usual (BAU) always comes in and you’ll need a mechanism for dealing with it. You need to route all BAU work through that process – and throttle it down so that it doesn’t challenge the project work.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.