Boss wants my team to work weekends

Question

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?

Maybe you shouldn't try to adhere to a "sprint" religiously and do the work on Monday? — Matti Virkkunen, May 08 '16 at 10:23
Depending on your contract the boss may actually order you to do this - work overtime - as part of your job. Question is why it is so important? — Thorbjørn Ravn Andersen, May 08 '16 at 10:57
@Raystafarian they are paid a salary which is 40 hours a week. — bobo2000, May 08 '16 at 11:50
if they don't pay you the extratime, simply find a better company — dynamic, May 08 '16 at 12:03
Your second question is obviously not possible to answer without knowing your country, and/or state, and possibly the employment contracts. Yet you don't even mention your country. — pipe, May 08 '16 at 16:20
If you don't get paid in the weekend, don't work the weekend. You're overcomplicating your situation. — Mast, May 08 '16 at 17:54
Ask your boss if he wants to increase or decrease productivity. Because overworking and demotivating the team by forcing them to work on weekends will absolutely ruin productivity. — limdaepl, May 09 '16 at 06:40
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 09 '16 at 09:09
"Sure, Boss, I'd be happy to ask my team whether any of them will volunteer to work this weekend". — Dawood ibn Kareem, May 09 '16 at 10:14
i have no other life. so working on weekends will not bother me — , May 09 '16 at 12:02
How does salaried employment work in the UK? Is it a set 40-hour max? Can the boss require you to work without extra compensation? — GHP, May 09 '16 at 14:00
@Graham as far as I know, payment for overtime is not mandatory in UK. — T. Sar, May 09 '16 at 14:01
" late in a sprint my boss requested that the team gets some work done by Monday" -- if you change the scope part way through then it's not a sprint. Which doesn't stop your boss asking for it, but what he asked is that you suspend the sprint and do something else instead. So I don't think it makes much difference whether it's early or late in the sprint -- either way the sprint is ruined. So do the work on Friday and reschedule the sprint end date. — Steve Jessop, May 09 '16 at 15:40
@Mast if you refuse to work unpaid overtime, doesn't that give the company a reason to get rid of you? — bobo2000, May 09 '16 at 16:32
@bobo2000 So, what if it does? Expecting people to work unpaid overtime also gives those people a reason to find work somewhere else. It's a great way to make sure you end up with a team full of low-performers who can't get a job anywhere else. Also worth considering that there's an inverse relationship between productivity and long working hours. The more hours you make them work, the less productive they'll be. And the good ones will leave. — HopelessN00b, May 09 '16 at 17:31
There's a difference between the occasional hour of overtime and an entire weekend. Some boundaries shouldn't be crossed. — Mast, May 10 '16 at 06:20

score 110 · Answer 1 · edited Apr 13 '17 at 12:48

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.

edited Apr 13 '17 at 12:48

Community

1

answered May 08 '16 at 02:35

Jane S

46,669
18
145
177

4

Good points, Jane. – keshlam May 08 '16 at 03:28
1

Thanks! It's simply that I've faced this situation far too many times in my career, and it will just spiral out of control if you don't start managing upwards. – Jane S May 08 '16 at 03:31
38

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 08 '16 at 03:43
15

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 08 '16 at 04: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 08 '16 at 07:38
@ToddWilcox and keshlam that is exactly the problem I am having right now, glad to see that I am not the ONLY PM struggling with this. I am finding implementing pure agile a pain here, often I get met with answers, 'they are all important' – bobo2000 May 08 '16 at 11:40
2

To add , what I am also finding that tech debt increases when I put additional pressure on the team - work is rushed, they I get asked why there are bugs. It is a total catch 22. – bobo2000 May 08 '16 at 11:42
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 08 '16 at 11:54
1

@JaneS thanks Jane. I will mention this to him Tomorrow. – bobo2000 May 08 '16 at 11:59
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 09 '16 at 05:54
3

@ToddWilcox ultimately a decision has to be made about what work the team does, though. Something is going to happen whether the boss decides or not, so try to frame it to force a decision. Pose the alternatives and just let the boss pick one. e.g. "In order to prioritize your new request B, we will have to delay A by one week. Are you happy for us to proceed on this basis? Or we can go with the original plan and introduce B later." If you still don't get a clear answer just tell the boss what you plan to do. – May 09 '16 at 06:01
4

@JaneS boss seems to have agreed. I mentioned during my team meeting today to him and the rest of the team that work should be suggested before the sprints begin, once they begin, any new work should be carried out in the next sprint cycle or if the sprint finishes early. Had a call with a client this morning, boss told them the enhancement may be done this week or in the next sprint cycle. The hard part now will be maintaining this structure, easy to go back to old ways. – bobo2000 May 09 '16 at 10:24
2

If "it's all important" just tell your boss he can get all done 80% (or some other random number you imagine) by the end of the sprint or some tasks 100% complete and some 0%. Tell him, if you don't get priorities what to complete first soon, all tasks will be unfinished by the end of the sprint. Do that in writing. I got very good results with that. Just keep insisting that its impossible to finish all. If no decision is made by your boss what to complete first, nothing will be 100% complete and it is his responsibility then. – Josef May 09 '16 at 10:33
3

@Josef always in writing. And if they call you in response to an email, reply to the phone call, "As per our phone call/conversation in the break room/over lunch, I understood that you feel X is more important than Y. If I don't get an email telling me that's incorrect and Y is more important than X by 8AM on Friday, I will operate under the assumption that this understanding is correct. Thanks!" – Wayne Werner May 09 '16 at 12:31
@bobo2000 Awesome! Sometimes it takes a little courage and conviction, but so far I've found that most organisations will bow to logic. Eventually ;) – Jane S May 09 '16 at 13:04
2

@JaneS I never thought that project management would be so political. I used to be a developer, life was a lot simpler. Always get paranoid that I will end up stepping on someone's toes and piss them off. – bobo2000 May 09 '16 at 14:10
3

@bobo2000 If life was simple back then, you probably had a good manager who went in to bat for his or her team :) – Jane S May 09 '16 at 14:14
@JaneS my last line manager was absolutely terrible, but it was simpler in the sense that I wasn't at the centre of everything – bobo2000 May 09 '16 at 14:44

score 41 · Accepted Answer · edited May 08 '16 at 22:09

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:

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

edited May 08 '16 at 22:09

Tim Malone

113
1
2
8

answered May 08 '16 at 10:25

gnasher729

169,032
78
316
508

You're using Scrum terminology for the planning/talking/recovery. Unfortunately it sounds like these folks are still in waterfall mode... – keshlam May 08 '16 at 11:35
1

@keshlam We are working Scrum - we have weekly sprints and I am doing my best to get management to respect it, from time to time, one of the problems that I am having right now is where my boss or customers are not respecting my sprints, either they are expecting too much or in the MIDDLE of the sprint he is expecting me to add new things in. 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. Doing true agile is easier said than done. – bobo2000 May 08 '16 at 11:47
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 08 '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 08 '16 at 16:00
1

End the sprint on Wednesday or Thursday: good idea. – Bob Jarvis - Слава Україні May 08 '16 at 16:56
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 08 '16 at 18:11
@BobJarvis I run my sprints weekly, if we happen to finish on Thursday i.e. complete all of the items by then, then we do ad hoc work on the remaining day - Friday. That tends to happen on a very good week, we have some weeks where the developer literally gets stuck and needs the whole week to figure out how to solve the problem. – bobo2000 May 08 '16 at 18:25
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 08 '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 09 '16 at 11:32
1

@bobo2000: it's worth bearing in mind that there are some organisations for which a two-week sprint is just ridiculously long, and it's essential to be able to do new work at shorter notice than this. If the boss needs to sell things at shorter notice than your sprint duration, and you don't have enough people to split into a sprinting team and a non-sprinting team available for new assignments, then your process is wrong :-) – Steve Jessop May 09 '16 at 15:48
@SteveJessop for client projects I do kanban, for the in house product we are developing I find that scrum is working well when it is done properly. The challenges lies in my boss (in charge of sales) promising things to be delivered not thinking about sprints. That's where the change needs to happen. I haven't bothered with a 2 week sprint, because as you say, it is too long. – bobo2000 May 09 '16 at 15:54
@bobo2000: so in effect what's happening is that you've defined a sprint, but then the sprint can't be resourced if you meet the boss's request to pull developer-days over to the client-deliverable kanban side of the operation. Surely nobody expects a sprint to meet its forecast if it isn't resourced? – Steve Jessop May 09 '16 at 16:00
@SteveJessop sorry should have been clearer - when I work with freelancers on client projects I do kanban, in house we have our own dev team and they do scrum since it is easier to do when everyone is on site and working on one product. Sometimes though yes, we have to switch to kanban mode if a requirements comes out of the middle of nowhere for the product that needs to be urgently done. – bobo2000 May 09 '16 at 16:03
@JaneS it's already gone out of the window, boss has just given me an aggressive deadline not taking into account velocity. His attitude is that the team have the sprint to complete all the work even if it means working overtime. – bobo2000 May 12 '16 at 10:42
@bobo2000 So without estimation of effort, factoring in current workload, your boss has added a bunch of work to your schedule and expects it all to be done? Ask your boss how he estimated the effort to meet that deadline, where his task breakdown and resourcing has come from. When he says he doesn't have one, then ask him on what basis he came up with the deadline and how he expects you to have factored in the work if he hasn't. – Jane S May 12 '16 at 10:56
@JaneS he basically told me I have set this deadline because the end client is going on holiday and wants it to all be done by then. In other words, the clients are setting the deadlines and we have to deliver no matter what irrespective of effort and resources. I am getting really frustrated now. – bobo2000 May 12 '16 at 10:59
@bobo2000 Did you ask him what he was going to take out of the schedule then? Or did he want you to choose what to remove? I have come across bosses like this, and sometimes it takes some effort to face down their impossible expectations before they finally see the sense in what you are telling them. An attitude like his will do nothing but drive good people away. – Jane S May 12 '16 at 11:01
@JaneS well we agreed that next week we will spend a sprint and try and deliver all of the work, and I did tell him I couldn't promise him that the quality will be affected since tech debt will pile up so probably I will not be able to deliver everything. The other problem is that the workload for next week is far greater than the team's effort. My team are going to probably have to work a lot of overtime and get disgruntled in the process. – bobo2000 May 12 '16 at 11:05
@bobo2000 You can't know what you can deliver (regardless of quality) if you haven't had the opportunity to estimate and resource it. I'd suggest you do that as soon as possible, then present to your boss what you can deliver. But you need to make very sure you do deliver it. – Jane S May 12 '16 at 11:07
@JaneS when you are put on the spot by the stakeholder and told to give an estimate how do you do it accurately, I find it tricky sometimes doing this since I do not have a complete picture of what is required to deliver x requirement – bobo2000 May 12 '16 at 14:05
Hey guys, what are your thoughts about doing a 4 day sprint and ending it on Thursday and do what the OP has suggested? Switch to kanban mode on Thusday and Friday. – bobo2000 May 12 '16 at 16:11
@gnasher729 5 day sprint was just not working for us, since 1 week is a long time in this organisation. So my boss and I have agreed to do what you have suggested by ending the sprint on Thursday. Your point about pushing to production is a good one too. Thanks. – bobo2000 May 25 '16 at 08:51
1

Update since this question was posted. @gnasher729 approach to integrating Scrum in an organisation is what has ended up working for us. We end our sprints on Thursday, and then switch to Kanban on Friday. This has made my boss happy, since everything is less rigid, leaving the team to make ui ux fixes at the end of the week on an ad hoc bases. Deployment happening on Thursday is important for us, from nobody being on stand by. The team are also very productive since the 4 day sprint means that they have 4 days to get on with delivering high priority work, without being interrupted. – bobo2000 Jun 10 '16 at 08:47

score 24 · Answer 3 · answered May 08 '16 at 02:05

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.

answered May 08 '16 at 02:05

keshlam

66,609
15
121
227

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 08 '16 at 02: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 08 '16 at 04:08
@Jcm: not always different. And it isn't necessarily unpaid overtime, if the company is willing to return it as flextime/mdto after the crunch is past or issues a bonus for going above and beyond the call of sanity, both of which I have sometimes gotten. In the end, everyone needs to set their own priorities, with awareness that like it or not any decision has consequences. Of course ideally this situation shouldn't arises, but that and a buck fifty will get you a bad cup of coffee with a mermaid on it. – keshlam May 08 '16 at 04:27
@JaneS I find estimating sprints generally hard. Not every task is the same and vary in complexity, often you find this out when the work has begun. At best story points are an approximation, NOT an accurate estimation of how long something will take. Sometimes we get it right and the team are ahead of schedule for the week, other times the team gets it wrong and they are behind schedule. Scrum is not a framework that is based around estimates but approximates. – bobo2000 May 08 '16 at 12:34
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 08 '16 at 12:37
@JaneS I do both. But again, at best it is always an approximation, you can never be a 100% accurate unless the task is similar to a previous task in previous sprints so based on that you know they can solve it since they have solved it once before. – bobo2000 May 08 '16 at 13:32
1

@bobo2000 I don't actually think estimation is your issue here. It's factoring additional work into an already planned unit of work that is causing your problem. – Jane S May 08 '16 at 13:35
@JaneS what do you mean? Stories are not small enough? – bobo2000 May 08 '16 at 14:06
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 - Слава Україні May 08 '16 at 16:55
4

-1 Extended comment. When it comes done to it this doesn't answer the question. The OP's teams answer is no, but how is that best delivered constructively? And if the answer is to work weekends, do you propose the OP issue these threats to the team? – Nathan May 08 '16 at 18:22
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 08 '16 at 21:07
3

"No" is not a useful answer. "We can do a full-court poress on this but here are consequences -- other things are going to be delayed. It can't all be first priority. And if we are going to ask folks to work unpsaid overtime on more thgan a very occasional basis, we must allow them to reclaim those hours as flextime at thge very least, oir they are going to burn out and we'll have even more trouble meeting tight deadlines. If you asre OK with that I can try to sell it to the team... But we are also going to have to work to keep thius from happening again. Are we doing scrum or not?" – keshlam May 09 '16 at 00:17
3

"Your boss has the right to consider your answer when employee review time comes around.". - this appears to be an assumption, based on labor law in the USA. But the comments have clarified that this is in the UK. While the UK has an exemption from the EU overtime rules, I understand that this chiefly means that UK contracts can have more than 48 hours of non-overtime hours. – MSalters May 09 '16 at 08:46
4

"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.", I made the exact opposite experience. I wasted my time and nerves for nothing. – ASA May 09 '16 at 12:17
@traubenfuchs: They do remember. Not all, unfortunately, reward it except by being less likely to pick you as the one who gets laid off. That may still be worth working for, depending on how much you want to hold onto this job. – keshlam May 09 '16 at 12:29
2

(Btw, apologies again for the touch-keyboard typos. Still learning that I've gotta proofread this beast.) – keshlam May 09 '16 at 12:31

score 11 · Answer 4 · answered May 08 '16 at 14:26

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.

"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 09 '16 at 01:38
From my reading of the OP's question, it does not seem to be the case here. — njzk2, May 09 '16 at 02: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. — , May 09 '16 at 13:31
@QPaysTaxes It usually focuses more on the preparation of the plan, though — njzk2, May 09 '16 at 13:52
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 09 '16 at 14:10
@njzk2 Hence "roughly". If you substitute "planification" with "execution of the plan", it's still accurate, if slightly less precise. — , May 09 '16 at 15:12
@gnasher729 I don't disagree. :-) But I do think that, particularly if you're fairly new to managing a team, you gotta remember that you need to keep both those above and those under you happy. Not just say your role is to protect your team, end of story. — Carson63000, May 10 '16 at 01:08

coteyr · Answer 5 · 2016-05-09T09:23:33.840

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.

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 09 '16 at 08:25
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 09 '16 at 09:11
I see, what your saying. "Suck it up" refers to "stuff happens" not your promise. With your promise, sometimes the company has to eat that failed deadline, but sometimes you do. It all depends on the situation and how often theses failures occur. Ideally theses deadline failures should be very rare. If they are happening a lot you have a planing/management failure. — coteyr, May 09 '16 at 09:18
If there are a lot of those things happening on short notice, those can be classified as "day to day", and a blocking ticket can be planned into the sprint that can be used to do those. It gets assigned story points (or whatever other valueing-method is used). If none show up, the ticket was successful and only had positive impact on the overall performance during the sprint. If there is stuff, someone does it. It was planned that something might happen, all is well. It's a bit like not planning a stuff for one day, but I think it sells better to hard-to-convince management. — simbabque, May 09 '16 at 09:51
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 09 '16 at 13:37
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 09 '16 at 14:11
@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 09 '16 at 14:13
@gnasher729, The point is, there are events which are so important that you just fix them, and don't bother with "when". — coteyr, May 09 '16 at 14:39
@Gusdor, I like the accurate metrics argument. However if sprints are Monday to Monday then you have 7 days not 5. Just two of those days your non-productive. I suppose that's important if not everyone works the same shift. But then again metrics are what ever the people making them want them to be. I supposed you could do Tasks per hour and show the problem. — coteyr, May 09 '16 at 14:57
However if sprints are Monday to Monday then you have 7 days not 5. Just two of those days your non-productive. Not unproductive. Unpaid. The OP's team is paid to work 40 hours. Therefore a sprint of a week is 40 hours, not 7 days. Factoring in more than can be (realistically) achieved in 40 hours is poor planning. Besides, the situation here is that the boss is bringing additional work into the sprint after it's started. So you need to plan by reducing the amount of planned work, or push back on the boss to schedule it in properly. That's managing. — Jane S, May 09 '16 at 23:19
@JaneS I agree, it can be very challenging when you deal with end clients who don't care about respecting sprints or agile and want everything done as soon as possible. This is the knock on effect from the sales team right now causing some sprints to not be 40 hours worth of work but more. Then again, my boss doesn't care if the team works overtime to be honest, he encourages it. — bobo2000, May 12 '16 at 14:26
@bobo2000 Yes it can be, there is no easy solution. With regards to sprint changes, unless you can get your boss to honour your sprints it's like shuffling deck chairs on the Titanic. You need to resolve the underlying issue first. — Jane S, May 12 '16 at 20:38

Boss wants my team to work weekends

5 Answers5

Linked

Related