Being in a rush is counter-productive. It is stressful for the people doing the work and the quality of the work suffers. In software development that translates into an ever increasing amount of spaghetti code and an architecture of quick fixes which then leads to a slow down. This slow down then leads to greater time pressure, and the rush gets worse.
Real deadlines do exist, and sometimes out of necessity a team has to pull out all the stops and make a short-lived dash. The big problem arises when this mad dash is the normal state of affairs.
Sprints are an excellent vehicle for creating this constant state of rushing. The name of the timed-boxed iteration - the sprint - is pretty accurate.
Sprints create a regular and artificial deadline. Always being two weeks from a deadline creates a state of constant time pressure where it is all too easy to cut those corners. Weekly sprints are the worst for this. You are always a few days away from your deadline, the day when you have to demo your work to an expectant client to whom you have laid down a commitment. Most people take commitments seriously and want to keep to their word. So they work more hours and cut more corners.
What makes a sprint commitment? A series of estimations. That's right, we call them estimations and yet we make a solemn commitment to complete them. That is called "double speak", and the indoctrination tries to make people believe that there is no conflict there.
I only make a promise when I know I can keep it. But Scrum forces me to make promises to the client that I have no idea if I can keep.
So what happens? We often don't make the sprint. The client loses faith, managers berate the developers and says go faster, the Agile consultant says we need to make better estimations. All because of a group hallucination that estimations are real. The developers get kicked from all sides for not fulfilling the fallacy that software development timing can be accurately estimated.
There is a way to avoid all this mess: Avoid iterations with a commitment or a demo at the end. If you want to work in time-boxed iterations then fine, but don't agree to any commitments about completion and don't guarantee a demo. The best way to reduce the constant state of rushing is to do away with the artificial deadlines.
Timed-boxed iterations, or sprints, are just bad for this. It is too easily abused and too easy for developers to get fixated on the deadline. A continuous flow model where work is demoed when it's ready seems a better way. No commitments are made except to work at a sustainable pace, with a focus on quality. Demos are done when it makes sense. Rather than twisting and contorting ourselves to meet artificial deadlines, let us demo our work when it makes sense.
If you really are a self-organizing team, and you struggle with the sprint model then try out something else that fits. Don't let yourself be pushed into a stressful and unsatisfying pace. You are the experts, be a self-organizing team and define the work practices that produce better results. Managers will often push you to be faster, produce more, some might argue that's their job. It's your job, as a professional, to tell them how that is achieved, realistically.
I'll finish we a great quote I have used in a previous post but I just think it is great:
“Perhaps the most important condition required for Agile to work is for management to be clear on the distinction between estimates (a measurement) and features (a control knob) and never push on estimates. Pushing for a low estimate is like pushing a speedometer needle higher: it doesn’t make you go any faster, and now you don’t know how fast you ARE going. If you punish a messenger who brings you bad (schedule or other) news, better get used to only hearing good news - until the bad news can’t be hidden any more. If you want the truth about the state of a project, it had better both be safe and seem safe for people to tell it to you.”