At the current project we face plenty of challenges. The staunchest is probably that the team can’t adhere to deadlines and management can’t get a grasp on the ‘why’ of it.

We move in bi-weekly sprints, working toward a deadline that has been set by… well… someone higher up, based on something they know that we don’t. I suppose.

I don’t mind tight deadlines. They can be a valuable tool, if used responsibly. But be aware that there’s a great many horrific problems with deadlines, if they are not.

• Frequent tight deadlines aren’t real deadlines anymore. They don’t represent anything anymore.
• To whom is the deadline important and what for? We don’t know. Do you? Tell us!
• Why should the team care? Tell us!
• Too tight deadlines diminish hope. Too loose deadlines encourage sloth. Are you willing to bet on hitting that sweet spot?

It’s not the lack of respect for deadlines that’s the problem though. It’s the perception that the team doesn’t work hard enough. Not hard enough to match the expectations.

Right now, in my context, these deadlines are used as a heuristic. They are there, just like the time registration, the burndown chart and some other, less popular, procedures to keep track of one thing: Time.

It is believed, that if management can get a hold on time and apply the right amount of pressure, the team will function at 100%. That being 8 hours a day, constant coding.

I find that there are at least two things wrong with that approach.

1. A team’s productivity and motivation isn’t intensified and certainly not sustained by having your team under the pressure of having to adhere to rigorous charts and metrics.
2. A focus on time will result in less qualitative work and the team as a whole will eventually suffer.

If taken too far, these procedures produce nothing but a beating stick, fearfulness and extra time spent cheating the system.

And boy, can you cheat the system. We’ve all seen those movies in which a tyrant tries to find a certain person or group but his seemingly faithful subjects work against him and hide the lot?
It’s somewhat like these movies, a whole team can support, carry and submerge each other’s discrepancies.

Needing to help someone, having to fix your local environment, being called to a quick meeting,… All are good explanations on why you weren’t able to finish that task. It’s a sign of a good team when all its members protect each other.

Facing this challenge, my advice would be to find another way to motivate (like stressing the value their work brings). Or suggest to do some expectation introspection.

As a tester, you can find subtle ways to influence this situation. During planning, I point out all the little stuff that is overlooked but carves daily chunks from your schedule.
When asked the question: “How long will you need to test this” (which is asked still way too often) I answer that “It depends on many uncertain parameters”, of which I then give the shortlist: Quality of the product, availability of developers/functional people, the stability of the environment, # time available at the time, # of bugs found,…

Slowly, but (hopefully) steadily, awareness will grow that there is a great lot more to software development than writing code. We’ve got this team that more resembles a group of friends. That’s a great basis to work from.