58

I am currently managing an in house team of developers, late in a sprint my boss requested that the team gets some work done by Monday. He mentioned that if the work cannot be done on the Friday, that the team should work on Saturday.

The team got disgruntled, since they:

  • want to work fixed hours (40 hours a week), and do overtime during weekends if absolutely necessary
  • want to switch off on the weekends.
  • are not paid for working weekends.

I want to mention this to my boss, how can I do this in a non-confrontational way? Has my boss got a right to ask for my team to work on weekends?

Improve this question
19
  • 20
    Maybe you shouldn't try to adhere to a "sprint" religiously and do the work on Monday? – Matti Virkkunen May 8 '16 at 10:23
  • 8
    if they don't pay you the extratime, simply find a better company – dynamic May 8 '16 at 12:03
  • 71
    If you don't get paid in the weekend, don't work the weekend. You're overcomplicating your situation. – Mast May 8 '16 at 17:54
  • 10
    Why are you asking for a "non-confrontational way"? I'm not suggesting you start calling your boss names, but there has to be some kind of confrontation, right? It's your obligation towards your team to go and confront your boss with the consequences of his request. – marcvangend May 9 '16 at 9:09
  • 8
    "Sure, Boss, I'd be happy to ask my team whether any of them will volunteer to work this weekend". – Dawood ibn Kareem May 9 '16 at 10:14
41

What does "deadline" mean? There's the kind of deadline where your company signed a contract and will lose a million dollar payment if you don't deliver on Monday, and if you don't finish the job before Monday, you might as well not bother coming to work because there is no money to pay you.

And there is the kind of "deadline" where your boss promised his boss that the software would be done on monday, without any real need to do so, and he doesn't want to look stupid to his boss. That's a deadline for your boss, but not of any importance to the company.

In this case it's not a deadline. It's a sprint. There is absolutely no need to work overtime for a sprint.

Here's some things to put to your boss:

  1. Ending a sprint on Friday is stupid. If you end it on Wednesday or Thursday then you can add extra work without stepping on anyone's toes - IF you think it's needed. You can also release things to the public because someone will be in the office the next days if something goes wrong.

  2. A sprint takes as long as planned. If you don't do everything you wanted to do, you didn't do everything you wanted to do. You don't make the sprint longer. Your boss needs to learn better sprint estimates.

  3. You don't add to a sprint after the sprint is started. If someone runs out of things to do during the sprint they may start on something from the next sprint, but in no way do you add to the sprint.

Improve this answer
23
  • 23
    The customer would say, can i have x thing done, boss will agree, I have to then stick it in since my boss starts to freak out that he will lose the deal if he doesn't. The whole point of Agile is to allow changing priorities. However, to add something in to your schedule, you have to take something else out. – Jane S May 8 '16 at 13:08
  • 3
    @JaneS I thought that once the team commits to at the sprint backlog at the start of the sprint, the sprint is set. Hence, changing it mid way through is bad practice, and a sign of poor planning? – bobo2000 May 8 '16 at 16:00
  • 2
    @bobo2000: Your boss seems to be very nervous. He's not going to lose a deal over this. If your "boss" is the one running the business, then most likely he will make his business a lot more profitable if he learns to stand up to his customers. – gnasher729 May 8 '16 at 18:11
  • 5
    @bobo2000 That's exactly correct. Hence I said change your schedule, not your sprint. In pure Agile, you finish off this sprint, then readjust your priorities in the sprint planning meeting for the next sprint. – Jane S May 8 '16 at 20:56
  • 3
    @JaneS told the team today what the OP has mentioned about how to organise the sprint. They agreed. Bad habits die hard, so I expect people (boss and other members of the sales team) to fall back into their old ways. Agile is great, really love it, but it's very hard to get a whole organisation to think in an agile way. – bobo2000 May 9 '16 at 11:32
110

Reading your question and while completely agreeing with keshlam's answer, I think the right question to ask is, as a manager, "how can you get your boss to prioritise new work rather than imposing an increase in workload without considering the impact on the team?"

If you are:

  • Late in a sprint (and potentially on time); and
  • Asked to add something into the sprint

then you have to manage the boss's expectation. Whenever that's happened to me, I say something like this to the boss:

If you want this done before Monday, then we have to stop other work to pick it up. What other priority from this sprint is now lower that will have to be pushed into the next sprint?

Make your boss choose whether this work is so urgent that it needs doing by Monday that other work will be delayed, or whether it actually can wait until the next sprint and be scheduled accordingly.

Remember, you are the manager of this team. One of the most important functions of a good manager is to manage your boss's expectation to ensure that your team is not crunched by an arbitrary thought in senior management's mind. I have stood my ground on many occasions when a boss tells me something is urgent. Invariably, I get my priorities and schedule or reschedule accordingly.

If your boss is attempting to increase the workload such that your team MUST work more than 40 hours a week to meet commitments, then you need to talk to you boss about hiring additional resources to increase the capacity of your team to keep the workload of team members to a sensible level.

Improve this answer
18
  • 37
    Convincing folks to do real agile, rather than waterfall in agile drag, is extremely difficult unless there is but-in, and willingness to say no and to defend that answer, all the way up the chain. Many of us are fighting that battle these days, and yes, it requires skilled managing upward. – keshlam May 8 '16 at 3:43
  • 14
    Every time I've tried to get someone above me to actually spell out a change in priority in ways similar to suggestions in this answer, the person has gotten mildly annoyed and used meaningless doublespeak to avoid making a decision (e.g., "just make these both your top priority"). As much as this is probably the best approach, it is still likely to fail, in my experience. Perhaps I'm terrible at managing boss's expectations, but I think most bosses just refuse to have their expectations managed, to the point of complete rejection of reality. – Todd Wilcox May 8 '16 at 4:42
  • 13
    @ToddWilcox I find that documenting when you get a stupid decision (in writing!) is the best way of passing accountability back to them. "You wanted this done, I warned you it would impact X and Y (show email trail), which it did. How do you want to proceed next time?" – Jane S May 8 '16 at 7:38
  • 6
    @bobo2000 That is exactly the type of impact I am talking about. Quality, functionality, fast. Choose any two. Now present that data to your bosses when they ask for work to be jammed in to fit with already specified timeframes. – Jane S May 8 '16 at 11:54
  • 7
    @bobo2000 When they tell you "it's all important" you should counter with "naturally it's all important or it would not be on the backlog, but surely one thing is more important than the other?" In a web-shop for instance, you really want good looking product pages and you really want a payment system, but without a payment system people can't pay you money so clearly that is more important. Find a similar example for your product. – Cronax May 9 '16 at 5:54
24

Your boss has the right to ask.

You have the right to decline.

Your boss has the right to consider your answer when employee review time comes around.

Pick your battles, and consider that companies do tend to remember who is and isn't willing to make an extra effort when the company is hard up against a deadline.

Improve this answer
16
  • 12
    Also look at why you are crunched at the end of a sprint. As the manager, it's your responsibility to ensure that timeframes are realistic and that expectations are managed. – Jane S May 8 '16 at 2:23
  • 60
    "willing to make an extra effort when the company is hard up against a deadline" is one thing, willing to do a day of unpaid overtime is another. – jcm May 8 '16 at 4:08
  • 5
    @bobo2000 This is why you track your estimation accuracy over time. Also, if the tasks are too hard to estimate, then they're not granular enough. Try breaking them down further if you can, it may help your accuracy. – Jane S May 8 '16 at 12:37
  • 10
    In my experience everyone gets asked for "extra time" once in a while, and as long as it's "once in a while" it's not a problem. However, when "extra" becomes the norm then a line has been crossed, the relationship has become abusive, and it's "election time": people get to vote with their feet. – Bob Jarvis - Reinstate Monica May 8 '16 at 16:55
  • 6
    @bobo2000 No, I mean that the issue in your question has nothing to do with estimating, it's because your boss is trying to jam more into a sprint. If this is going to be a common thing, you may need to reduce the overall number of story points you intend to complete in a sprint so you can allow space to add in "unscheduled" work. It's not pure Agile and it may mean that your team is often taking more stuff out of the backlog to fill the sprint, but if your boss insists on breaking your sprints there may be no choice if you still want to finish the scheduled tasks. – Jane S May 8 '16 at 21:07
11

There are 2 points here. Your boss wants to:

  • Add things in a sprint (and especially toward the end of it)
  • Have the team work on a Saturday when they are not supposed to

A sprint defines a set of features the team commits on delivering at the end of it. Adding new things during the sprint is by definition a problem.

As their manager, it is your role to protect your team from such problems.

Having people work on a day off usually indicates that the planification was poorly done, and that both the workload was not well estimated and the priorities were not well evaluated.

Both those points point toward issues in organization and planification.

When a sprint is started, it should not be modified until completed, so the team can be confortable and efficient.

Now, obviously, this is theoretical, and things happen that require moving priorities. In which case, I would recommend replacing features from the sprint point for point.

That is, here is what I would suggest you do:

  • Evaluate the priority of what is asked
  • If (and only if) the priority is really high:
  • Evaluate the point value what the stackholder (the boss) request
  • Evaluate the health of the current sprint
  • Make a replacement plan where you remove features from the sprint to integrate what is asked.
    • Make this plan with the team to make sure there is no conflict in the scheduling and no non-sense (e.g.: don't remove a task if someone else depends on it, don't remove the final task that gives meaning to 3 months worth of work...)
    • Suggest that to the boss.

Don't mention the Saturdays, neither to the boss, nor to the team*. If the boss insists on it, be firm and rely on your plan to show that you can deliver what the boss asks, but also that the boss cannot just ask everything and get it.

*There are a few cases where working extra can make sense, but it is never about adding new features, and certainly not adding things on top of what is already promised. If for example you discover a problem that threatens your clients and needs fixing now, then it makes sense to basically drop everything else and fix it right away.

Improve this answer
7
  • "As their manager, it is your role to protect your team from such problems" - however, your manager probably feels that it is part of your role to get extra effort (i.e. unpaid overtime) out of the team when necessary. Failure to do so is likely to be a career-limiting move. – Carson63000 May 9 '16 at 1:38
  • From my reading of the OP's question, it does not seem to be the case here. – njzk2 May 9 '16 at 2:34
  • For anyone reading this who doesn't know what "planification" is (i.e. someone not very familiar with English), it roughly means the execution of a plan. – Fund Monica's Lawsuit May 9 '16 at 13:31
  • 1
    @QPaysTaxes It usually focuses more on the preparation of the plan, though – njzk2 May 9 '16 at 13:52
  • 2
    Long term, when your manager has all the guys who can find a job elsewhere running away and is left with those who can't find another job, that will be a career limiting move to him. – gnasher729 May 9 '16 at 14:10
-2

A lot of these answers focus on Boss Management, I am going to take a different approach.

The Answer, directly

First to answer your question, your answer should be, "Of course I agree to work weekends if it means meeting a sprint deadline." The reason for that is clear (to me).

From a coders standpoint

A sprint, when used correctly, is a "deal" between (in this case) coders, and non-coders, about when a set of work will be done. It's a wonderful tool, because while, in the real world you need to be flexible, once the sprint starts the finish line doesn't move. In addition to that, in order for a sprint to be used correctly, the "coders" (either individually or as a team via a lead) get to have a major, nearly exclusive, impact on what goes into a sprint. Now the company (or client, or whatever) may want you to do more in a sprint, and that can be a goal to work on, but that doesn't matter. If all you can do is one task in a sprint, then that's all you agree to.

Here's the layout I use. I have a weekly sprint (in this example) with work due Monday. I look at the backlog (or what ever) and put enough work in the sprint to fill 4 days. That means, Monday - Thursday, I have a full workload. Not overfull, just full. Mondays, I put a little thin because we have the sprint setup and tear-down meeting(s), and Fridays, I do not schedule any work at all. This leaves me with 1 full day, with technically nothing to do.

In the real world, that extra padding, means I don't have to work weekends, and that Fridays are usually "code light" days, where I am just covering things that got delayed the rest of the week. The rest of the day I can spend do administrative tasks, like looking ahead to the next week and preparing for the next sprint. Of course, if something happens, and I need an "extra day's work" to finish of my sprint tasks, it's not a big deal. Yes, it means my normal "administrative Friday" becomes a "scramble to get it done Friday", but these things happen from time to time.

From the company perspective

So as management in the company, what you really care about are "costs" and "deadlines". Sprints are a great way to figure out what a deadline is from a process that is still largely "magical" to anyone who doesn't write code. What they see, is stuff goes on the list, I get a date, things magically work because these people make it work. The point is, most companies don't care what the due date is, so long as your hitting it, and it seems reasonable.

Costs on the other hand are a big factor. If the company has to pay overtime (in the US even a salaried employee is entitled to compensation for over time if it's constant), then it quickly becomes better to hire a new employee, rather then pay over time, or have to deal with the uncertainty of "flex time".

The company, as a whole should benefit from having a more stable cost base, and a better "completion rate" of sprints, even if that means fewer tasks get done per sprint.

Final Thoughts

If your having a lot of problems where your not getting your sprints done on time, then you (or your company) are not doing sprints correctly. You should be able to always complete a sprint, even if it means a "shorter distance". There are other metrics (i.e. velocity) for getting more done per sprint.

Remember that a sprint is "both sides". Your agreeing to do X by the end of the sprint. Either don't agree to it (break X into smaller pieces) or do what you said you would, even if it means loosing your weekend. At the same time, the "extra work" is not part of that sprint. Make sure to point that out.

Sometimes you will fail a sprint. These things happen. In my opinion, you should be ready to work the weekend in these cases. At the same time, the company should be able to respond to a few missed deadlines. It really comes down to credibility. Are you "working the hours" or are you "working the project"?

"Extra work" is common enough, it can usually mess up a good plan, but that's why I suggest the "extra day" of padding. Sometimes you won't have a lot of coding to do, and you can focus on ticket and documentation quality, or prep work. Some times, you can spend it handling issues like this (in your question).

If this extra work happens a lot then you can address it by pointing out that the sprint is how you setup your due days, and that you shouldn't move the finish line. If it happens a lot then you have a management failure, and you should ask something like "What can we do to better plan our sprints so that we don't have this Jack-in-the-box so frequently?"

Coding is a job where your just gonna have to suck it up some times (there are others). Things happen and your going to have to work more then your 40 hours. You should be ready and willing to do so. Your boss/company has every right to ask, and you have every right to say no, but saying no will look really bad. The key is to make sure that you mitigate and lesson the times that this has to happen. There will always be critical times, but you can usually reduce the number of times to something more manageable. If you feel it's happening too much, then address that by trying to work that "extra" work into your normal sprint workflow. If it's only once or twice a year, then, just deal with it, it can be a powerful tool (you working the weekend on occasion) when you need that extra couple of days off for your fantastic vacation.

Improve this answer
12
  • 5
    I agree with most of your answer, but sucking it up is actually not the right thing to do imho. Instead, the agile mentality should be lived by management as well. If the sprint was too full, well, that happens. Next time you're going to plan less. Lesson learned. But if there is no continuous deliver in place where stuff can get shipped today, tomorrow or when it's done, then it's a management failure to expect everything the day the sprint ends. Sprint contract or not, everyone needs to be agile (i.e. flexible) in a setting like this. – simbabque May 9 '16 at 8:25
  • 3
    I agree, but "stuff happens". OMG our app is mailing out credit card info.... "I'll tackle that next sprint", not a valid answer. So things happen, that are not foreseeable, and you have to "suck it up". But those things should be few and far between. Lets say 1-2 times a year. Not every week, or often, but on occasion. – coteyr May 9 '16 at 9:11
  • 4
    I would like to see a discussion of how working weekends to meet sprint commitments is actually cheating. If you are tracking them, it will skew your sprint metrics by saying "We did X in 5 days" when actually it took you 7. It took you 40% more time than you estimated and you are going to hide that! When you plan your next sprint, accurate metrics will help you plan better. – Gusdor May 9 '16 at 13:37
  • 5
    Wrong in the first sentence: There is no such thing as a "sprint deadline". A sprint has a starting date, and an end date, and what gets done gets done and what doesn't get done doesn't get done. If it doesn't get done, it's bad planning. – gnasher729 May 9 '16 at 14:11
  • 3
    @coteyr: "Our app sends out credit card info" shouldn't happen once a year, it shouldn't happen once in a lifetime. If it happens, you might spend that weekend better writing a new CV. – gnasher729 May 9 '16 at 14:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .