Do Scrum sprints mean to work at the fastest pace possible?

Question

Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.

I recently interviewed with some companies that do Agile, Scrum to be more precise and there are some things that don't quite seem like Agile to me. I'll take one case that particularly interests me right now, that of Scrum sprints.

One particular project manager I talked to (yes, I said project manager) proudly stated that people in her team understand ("were told" is what I picked up from the context) that you don't go home when the working hours are over, you go home when the job is done, no matter how much it takes. What I've read in between the lines is that we pack as much features as possible into a sprint and work overtime to make it happen.

Now, I haven't done Agile by now (worked with financial and governmental institutions which most still do prefer waterfall) but my understanding is that:

• sprint in Scrum is the name for the generic iteration in Agile;
• the team should work at a sustainable pace and try to avoid long term overtime as that has effects only on the short time and the effects are dwarfed by the problems they incur in the long time.

Are my statements right? And, should I take the manager's presentation as a red flag?

Answer 1

You don't have to search far to see that these practices goes contrary to the principles behind Agile. One of the principles behind the Agile Manifesto states:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A few years ago, Scrum made a subtle but important change. Instead of teams committing to the work that can be achieved they forecast what they think they can get done.

The change comes because of abuse, which sounds very much like the don't-go-home-until-its-done attitude you describe. In development, there are many factors outside the teams control that they can't commit to - to use the a weather analogy, you can't "commit" that it will be rainy tomorrow.

To directly answer your questions:

• yes, Sprint is the name for an iteration in Scrum see this answer for the difference
• yes, teams should work at a sustainable pace. The only certainty of overtime is that it will reduce the teams productivity long term.
• yes, it is a red flag!

Answer 2

Yes, you're right, and if I were told what you were told, I'd run away from there as fast as possible. They're just using agile as an excuse. Sounds like the classic death march.

Answer 3

There is one key thing that may make this acceptable: the team accepts the scope of the sprint.

In Scrum, teams don't just get assigned work. The product owner negotiates with the team to prioritize product work and technical (debt) work. The project manager, product owner, and team then negotiate on what gets pulled into a sprint and what the scope of that work is.

In this world, the team is essentially saying "we can get X work done, tested and shipped this iteration". So I would expect a team to occasionally work overtime to meet these commitments.

That said, so many places bastardize agile - and so few team leads can negotiate effectively with people who are usually their bosses... I would take this as a huge red flag.

Answer 4

Scrum is broken into sprints where you estimate out a set of tasks to be completed in the duration of that sprint (typically 2 weeks, but I've seen anywhere from 1 day to 4 weeks). I think this creates an incentive to misestimate tasks. POs (product owner) will want low estimates to get a big committment per sprint. The team will put big estimates to generate nice burndown charts for the PMs to see. These are, of course, indicative of a crappy organization. You really want to get accurate estimates and not be afraid to either fall short and carry stories over to the next sprint or finish early and pull extra tasks off the backlog. I think the term "sprint" creates this image of people working faster.

Answer 5

No: scrum sprints are a timebox, nothing more, nothing less. At the start of the sprint / iteration, the team gives an estimate of the amount of story points they believe they can achieve, based on things like previous performance, availability, upcoming events, open impediments, etc. They then negotiate with the product owner about which user stories get put into the sprint. That is (or was? see other answer) the commitment the team gives to the product owner.

During development, if it turns out things aren't really as predicted (it is software development after all) and there is a risk the team will not meet the commitment, they inform the product owner that there is a risk one or more stories will not be completed.

And that's fine. Sure, it feels bad, having to admit at the end of the sprint that the sprint failed, but it's not defeat, it's an opportunity for improvement. Because at the end of the sprint / start of the new one, you get to do a sprint retrospective, and the first thing anyone will ask is 'Why did we fail this sprint, and what do we need to do to not fail it again?'. One option would be to give off less commitment (= take up less story points).

tl;dr: Sustainable Pace. Scrum is about cadence, something the team can keep up indefinitely on a sprint-to-sprint basis. Working overtime isn't; the team will become overworked, work will become sloppy, members will call in sick or quit altogether, and then you have a whole bigger problem than a failed sprint.

Answer 6

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

From the Agile Manifesto folks

Working overtime all the time doesn't sound sustainable to me.

That said, I see no issue with a spring commitment being a strong one (if that's the way the team wants to work), and having to work overtime when you overcommit or screw up estimates is a good incentive to get better at estimating or communicating expectations to PO.

Answer 7

One particular project manager I talked to (yes, I said project manager) proudly stated that people in her team understand ("were told" is what I picked up from the context) that you don't go home when the working hours are over, you go home when the job is done, no matter how much it takes. What I've read in between the lines is that we pack as much features as possible into a sprint and work overtime to make it happen.

That's not Scrum. The proposed workload for a timebox is based on the team velocity, not on the manager's wish list. They are simply trying to trick you into believing that working endless overtime is "Agile", which it isn't. The team will get more efficient while working undisturbed and focused, but Scrum is not a magic wand for endless efficiency gains.

Either the manager has a slight misunderstanding of Agile, or (more likely) he thinks that developers are that stupid. On the other hand, when the team accepts the sprint again and again, knowing that they will need to do overtime work, maybe they are indeed stupid and don't deserve it any better?

I guess, you know the answer ... ;-)