Time Pressure Improves Productivity & Quality…Up to a Point
Suppose you’re working on a project that has a major deadline a year from now. You’re agile, so you might release every couple of weeks if that’s appropriate for your customers and the product.
But the big deadline—the one everyone is focused on—is a year away.
And, let’s suppose you’re on schedule. It’s not going to be easy, but the general feeling is that if everyone stays focused and avoids major changes in scope then the team will deliver on time.
But the Boss Wants It Immediately
Now, what if I told you I just got an email from your boss. She said there’s a massive bonus in it for you and the rest of the team if you can shorten that schedule. Finish in one month instead of twelve and there’s a huge bonus.
Would the promise of a massive bonus entice you to deliver in one month what you expect to take twelve months?
Probably not. No amount of overtime or extra focus is going to help a team cut more than 90 percent from a realistic schedule.
The Boss Wants It a Little Sooner
Instead, what if your boss offered that massive bonus to reduce the twelve-month schedule down to eleven months.
For the right incentive, most of us could be enticed to shorten our lunch breaks, stay a bit more focused during the day, keep meetings to a minimum and fully productive, stay a little late occasionally, and do whatever else was needed to cut a month from a one-year schedule.
In fact, many of us work that way when we need to without the promise of a massive bonus, but simply because our organizations and leaders have tapped into our intrinsic motivation. And we want our products and organizations to succeed.
The U-Shaped Relationship Between Productivity and Pressure
What this means is that there is a U-shaped relationship between productivity and pressure. Research by professors Ning Nan and Donald Harter bears this out.
As shown in the following figure, they found that reducing estimates given by teams by up to 20% leads to a reduction in delivery time for projects.
A U-shaped relationship between pressure and schedule shows that modest deadline pressure can reduce schedule. But excessive pressure prolongs the schedule.
This research fits with my experience.
Excessive time pressure often reduces productivity and extends schedules. One reason for this is that excessive pressure is often accompanied by team members working excessive overtime. Too much schedule pressure also often leads teams to taking (or being forced to take) actions that appear to increase productivity but really worsen it. Writing “quick and dirty code” or skipping some testing are examples of things teams are sometimes told to do to speed up development that have the opposite effect.
The first parts of the chart above also match my experience. Teams with no deadline pressure at all seem to take longer to deliver than teams with slight pressure. It benefits a team to know there’s urgency to whatever they’re working on.
In the face of urgency, teams usually respond by working a little faster, usually through greater focus or diligence.
But does that additional productivity from slight pressure come at the expense of quality?
The Effect of Time Pressure on Quality
The question of how time pressure affects quality was investigated by Magne Jørgensen and Dag Sjøberg. In their research, they found a significant increase in defects introduced when programmers were given a schedule that was estimated incorrectly: 40% below what it should have been based on their prior work.
This led them to theorize a relationship between pressure and quality as shown in the following image.
Estimates that are too low lead to lower quality.
On the left in this graph are estimates that are too low--the actual amount of work exceeds the estimate. This leads to reduced quality as team members rush to deliver the product. Accurate estimates lead to improved quality. An estimate that is too high, or “padded,” doesn’t lead to increased quality over that achievable with a realistic, accurate schedule.
Implications for Agile Teams
So, what do these relationships between time pressure, productivity, and quality mean for agile teams?
At a minimum, I think they illustrate one of the benefits of iterations. The short iterations or sprints of agile mean that a team’s next deadline is usually no more than a month away. I suspect that puts teams in the sweet spots shown by this research and in the two graphs.
Should Leaders Add Time Pressure?
Does this mean product owners, Scrum masters, or managers should seek to put a little artificial pressure on teams?
No, I don’t think they should.
The gains in productivity and faster delivery created by time pressure are real. But they’re minor. And if too much schedule pressure is applied, quality could drop dramatically, as shown in the second chart above.
To put it another way, there are minor benefits to a little schedule pressure but there are major risks to too much schedule pressure. That means leaders should be cautious of applying any additional time pressure.
The inherent pressure on a team of needing to have something fully delivered every few weeks is generally all the pressure a team needs.
What Do You Think?
I’d love to know what you think. Have you been part of a team that was expected to deliver much more quickly than team members felt realistic? Or have you been part of a team with absolutely no pressure to deliver? How were productivity and quality impacted on those projects? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.
If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.
Business Analyst, Programme Architecture at Network Rail
4yVery interesting thank you, I like a project with a visible overall deadline that is achievable of course
retired educator, author, volunteer, mentor
4yindeed -- with the operative words being "up to a point."
Senior Global Product Manager at Schneider Electric
4yMakes perfect sense!
Senior Director, Applications Development at Pegasystems
4yI agree that artificial deadlines is not a good solution. Our problem is often that while we are good at achieving 2-week sprint objectives we sometimes struggle with the overall project deadline which can be months out. Blame some scope creep and story complexity that each sprint offsets some of our gains towards the whole project. We also need to keep the project deadline in sight, not just the sprints.
Agreed. Focus should be on producing increments early not faster