22

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?

Improve this question
5
  • No real experience with Agile either, but from what I understood, your sprint workload should be balanced with the duration of your sprint, so either the developers are underestimating their workload or the manager is just giving them work without asking for their feedback on the workload. In this case probably the latter. - Correct me if I'm wrong, though
    – Andreas
    Jan 6, 2014 at 12:52
  • 4
    @gnat I think the questions are too different
    – Andreas
    Jan 6, 2014 at 12:55
  • 27
    "... 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...". Run like the wind. She's an idiot.
    – JᴀʏMᴇᴇ
    Jan 6, 2014 at 15:41
  • I voted to reopen this question. The question of the proposed duplicate is-agile-the-new-micromanagement has in common with this question, that the manager calls something "scrum" and the asker wants to know if this is really scrum. This question is about "overtime" the proposed about "it is not allowed to talk to other developpers".
    – k3b
    Jan 6, 2014 at 20:40
  • "... 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" seems like a direct conflict with the key concept of sustainable pace - I'd work there if I had to put food on the table. HST, if this occurs from time to time, I've no problem with it. Sometimes, despite every effort, there's a crunch, and the customer comes first. But she makes it sound like that's a regular occurrence, and that it's admirable. What it means is that they are not doing root cause to understand why it's occurring and fix the underlying problem.
    – Don Branson
    Jan 6, 2014 at 21:24

7 Answers 7

Reset to default
28

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!
Improve this answer
23

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.

Improve this answer
6
  • 3
    Wouldn't a death march typically have an end? That project sounds like an eternal hell if that's how they work sprint after sprint.
    – DXM
    Jan 6, 2014 at 22:00
  • 5
    Nope, in a death march there is always "we just need to push to the next version, then we can refactor and fix bugs! oops, we promised the client the next next version in two months, just need to push to the next next version!" and so on, you get the idea.
    – Miki Watts
    Jan 6, 2014 at 23:03
  • 2
    @DXM it has an end when everyone quits or is laid off. Death March projects may last years.
    – Dogweather
    Jan 7, 2014 at 5:57
  • 3
    @DXM death marches end when you die.
    – Dave Hillier
    Jan 10, 2014 at 12:13
  • hmm, I guess I was projecting my own experience there. Somehow in my mind mismanaged projects are a combination of death march followed by months of indecision of where to go next. Longest our team sat on their thumbs with empty backlog was almost 8 months. Then we'd be given 4-6 months for a release with statement "we are on an annual release cycle"
    – DXM
    Jan 10, 2014 at 14:16
11

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.

Improve this answer
8
  • 8
    "occasionally work overtime to meet these (wrongly estimated) commitments" => making wrong estimates into a habit
    – gnat
    Jan 6, 2014 at 12:54
  • 1
    @gnat - pssh. Estimates are sometimes high. Estimates are sometimes low. If underestimation becomes a trend, it's certainly a problem. But that is largely why iterations exist: to help refine estimation.
    – Telastyn
    Jan 6, 2014 at 13:01
  • 8
    Programming sweatshops generally don't accept negotiations by workers.
    – maple_shaft ♦
    Jan 6, 2014 at 13:01
  • 1
    @gnat: If you find, as a team, that you are habitually underestimating the work, you should commit to less work in the next sprint.
    – Bart van Ingen Schenau
    Jan 6, 2014 at 17:30
  • When management goals are to get as much work done as possible, regardless of the limits on working hours (and experience indicates this to be true in the vast majority of cases), and employee goals are to get the most work done without exceeding paid working hours (I admit that some managers may argue that this is optimistic), then regardless of the inherent error in estimation, scheduling will always trend to >= working hours. The logical extension is that employee goals must shift to underestimating. @BartvanIngenSchenau this is how that habit naturally develops.
    – Steven Evers
    Jan 6, 2014 at 22:52
1

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.

Improve this answer
4
  • 1
    except that PO should have no part in the estimation process. If they were to be agile, the teams would be solely responsible for coming up with estimates and based on what the team estimates PO can only change backlog priorities.
    – DXM
    Jan 6, 2014 at 22:06
  • 2
    "The team will put big estimates to generate nice burndown charts for the PMs to see.": This is one reason why I think this whole mechanism is flawed. I think a manager can get much better performance from a team they trust than by forcing a team to provide estimates to be fed into charts.
    – Giorgio
    Jan 6, 2014 at 23:37
  • The team should, but like I said, they have an incentive to pad estimates. If the PO is the one paying, they can apply pressure to estimate more aggressively. For background, I work in consulting so the scrum team is my co-workers, while the PO is usually external and paying our inflated bill rate :)
    – jiggy
    Jan 7, 2014 at 16:37
  • @Giorgio an untrustworthy team can always pad estimates and make things worse. But a trustworthy team, even of experts, can learn to estimate better. This is why the estimates are made, and then compared against the actual work, to try to improve their ability to estimate. The mechanism isn't flawed, having a team that is taking advantage of a system is the problem, and will be the problem regardless of the management system.
    – CLo
    Jun 20, 2014 at 20:28
1

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.

Improve this answer
0

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.

Improve this answer
0

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 ... ;-)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.