How to deal with different daily working hours in a software company?

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
9
down vote

favorite

1

For employees life/work convenience in our company, we implemented something we call "Non-uniform Daily Working Times Policy".

It means that we have a default daily working hours starting from 9AM to 6PM (5 days a week=45 hours, Saturdays & Sundays are default weekend days) but each employee can override it at the beginning of each month and choose a different working times during a working day. The only rule here is that the total working hours should be 45 hours per week. i.e: John can override it and define his own working times for June: Monday (11AM-8PM - 9 Hours), Tuesday(9AM-6PM - 9 Hours), Wednesday (Off) , Thursday(9AM-6PM - 9 Hours), Friday( 1PM-10PM - 9 Hours ), Saturday( 9AM-1:30PM - 4.5 Hours ), Sunday( 9AM-1:30PM - 4.5 Hours)

This policy is to helping everyone to do their weekly tasks and manage their personal life beside, the way they like. Company doors is open for 24/7/365 hours/weeks/days per year.

The problem we have is that, we are doing agile and scrum and have daily standup meetings during our scrum sprints and I think that everyone should be present in this meeting. Standup meetings are around 9:30A.M each day and apparently not everyone can attend. Beside, we have different events and meetings which require everyone to participate.

Also, this makes another problem. As a scrum master and team leader, this force me to go to office 7 days per week because I have to held up standups everyday and provide stuff for everyone in each day and be present for possible helps, pair programmings and assistance.

What should we do? Should we stop this policy and force everyone to come to office in a non-negotiable daily working hours? Or is there any solution for the problems I mentioned ?

This question may seems ridiculous for some of you but we are in the beginning of our new procedure and needs some of your experience.

Thanks

software-industry work-life-balance meetings work-time scrum

share|improve this question

asked May 22 '16 at 10:50

Michel Gokan

183211

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Why not have stand up at the end of the day when everyone will be in
  – Pepone
  May 22 '16 at 15:25
  

  
  
  
  


• 
  
  
  

  
  28
  

  
  
  
  
  
  

  
  Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
  – Kaz
  May 22 '16 at 15:31
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
  – Vogel612
  May 22 '16 at 18:55
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Can you schedule the meeting at a time when all team members are going to be there?
  – Brandin
  May 23 '16 at 6:23
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
  – Michelfrancis Bustillos
  May 23 '16 at 14:15
  

  
  
  
  

 | 
show 7 more comments

up vote
9
down vote

favorite

1

For employees life/work convenience in our company, we implemented something we call "Non-uniform Daily Working Times Policy".

It means that we have a default daily working hours starting from 9AM to 6PM (5 days a week=45 hours, Saturdays & Sundays are default weekend days) but each employee can override it at the beginning of each month and choose a different working times during a working day. The only rule here is that the total working hours should be 45 hours per week. i.e: John can override it and define his own working times for June: Monday (11AM-8PM - 9 Hours), Tuesday(9AM-6PM - 9 Hours), Wednesday (Off) , Thursday(9AM-6PM - 9 Hours), Friday( 1PM-10PM - 9 Hours ), Saturday( 9AM-1:30PM - 4.5 Hours ), Sunday( 9AM-1:30PM - 4.5 Hours)

This policy is to helping everyone to do their weekly tasks and manage their personal life beside, the way they like. Company doors is open for 24/7/365 hours/weeks/days per year.

The problem we have is that, we are doing agile and scrum and have daily standup meetings during our scrum sprints and I think that everyone should be present in this meeting. Standup meetings are around 9:30A.M each day and apparently not everyone can attend. Beside, we have different events and meetings which require everyone to participate.

Also, this makes another problem. As a scrum master and team leader, this force me to go to office 7 days per week because I have to held up standups everyday and provide stuff for everyone in each day and be present for possible helps, pair programmings and assistance.

What should we do? Should we stop this policy and force everyone to come to office in a non-negotiable daily working hours? Or is there any solution for the problems I mentioned ?

This question may seems ridiculous for some of you but we are in the beginning of our new procedure and needs some of your experience.

Thanks

software-industry work-life-balance meetings work-time scrum

share|improve this question

asked May 22 '16 at 10:50

Michel Gokan

183211

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Why not have stand up at the end of the day when everyone will be in
  – Pepone
  May 22 '16 at 15:25
  

  
  
  
  


• 
  
  
  

  
  28
  

  
  
  
  
  
  

  
  Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
  – Kaz
  May 22 '16 at 15:31
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
  – Vogel612
  May 22 '16 at 18:55
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Can you schedule the meeting at a time when all team members are going to be there?
  – Brandin
  May 23 '16 at 6:23
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
  – Michelfrancis Bustillos
  May 23 '16 at 14:15
  

  
  
  
  

 | 
show 7 more comments

up vote
9
down vote

favorite

1

up vote
9
down vote

favorite

1

1

For employees life/work convenience in our company, we implemented something we call "Non-uniform Daily Working Times Policy".

It means that we have a default daily working hours starting from 9AM to 6PM (5 days a week=45 hours, Saturdays & Sundays are default weekend days) but each employee can override it at the beginning of each month and choose a different working times during a working day. The only rule here is that the total working hours should be 45 hours per week. i.e: John can override it and define his own working times for June: Monday (11AM-8PM - 9 Hours), Tuesday(9AM-6PM - 9 Hours), Wednesday (Off) , Thursday(9AM-6PM - 9 Hours), Friday( 1PM-10PM - 9 Hours ), Saturday( 9AM-1:30PM - 4.5 Hours ), Sunday( 9AM-1:30PM - 4.5 Hours)

This policy is to helping everyone to do their weekly tasks and manage their personal life beside, the way they like. Company doors is open for 24/7/365 hours/weeks/days per year.

The problem we have is that, we are doing agile and scrum and have daily standup meetings during our scrum sprints and I think that everyone should be present in this meeting. Standup meetings are around 9:30A.M each day and apparently not everyone can attend. Beside, we have different events and meetings which require everyone to participate.

Also, this makes another problem. As a scrum master and team leader, this force me to go to office 7 days per week because I have to held up standups everyday and provide stuff for everyone in each day and be present for possible helps, pair programmings and assistance.

What should we do? Should we stop this policy and force everyone to come to office in a non-negotiable daily working hours? Or is there any solution for the problems I mentioned ?

This question may seems ridiculous for some of you but we are in the beginning of our new procedure and needs some of your experience.

Thanks

software-industry work-life-balance meetings work-time scrum

share|improve this question

asked May 22 '16 at 10:50

Michel Gokan

183211

For employees life/work convenience in our company, we implemented something we call "Non-uniform Daily Working Times Policy".

It means that we have a default daily working hours starting from 9AM to 6PM (5 days a week=45 hours, Saturdays & Sundays are default weekend days) but each employee can override it at the beginning of each month and choose a different working times during a working day. The only rule here is that the total working hours should be 45 hours per week. i.e: John can override it and define his own working times for June: Monday (11AM-8PM - 9 Hours), Tuesday(9AM-6PM - 9 Hours), Wednesday (Off) , Thursday(9AM-6PM - 9 Hours), Friday( 1PM-10PM - 9 Hours ), Saturday( 9AM-1:30PM - 4.5 Hours ), Sunday( 9AM-1:30PM - 4.5 Hours)

This policy is to helping everyone to do their weekly tasks and manage their personal life beside, the way they like. Company doors is open for 24/7/365 hours/weeks/days per year.

The problem we have is that, we are doing agile and scrum and have daily standup meetings during our scrum sprints and I think that everyone should be present in this meeting. Standup meetings are around 9:30A.M each day and apparently not everyone can attend. Beside, we have different events and meetings which require everyone to participate.

Also, this makes another problem. As a scrum master and team leader, this force me to go to office 7 days per week because I have to held up standups everyday and provide stuff for everyone in each day and be present for possible helps, pair programmings and assistance.

What should we do? Should we stop this policy and force everyone to come to office in a non-negotiable daily working hours? Or is there any solution for the problems I mentioned ?

This question may seems ridiculous for some of you but we are in the beginning of our new procedure and needs some of your experience.

Thanks

software-industry work-life-balance meetings work-time scrum

share|improve this question

asked May 22 '16 at 10:50

Michel Gokan

183211

share|improve this question

share|improve this question

asked May 22 '16 at 10:50

Michel Gokan

183211

asked May 22 '16 at 10:50

Michel Gokan

183211

asked May 22 '16 at 10:50

Michel Gokan

183211

183211

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Why not have stand up at the end of the day when everyone will be in
  – Pepone
  May 22 '16 at 15:25
  

  
  
  
  


• 
  
  
  

  
  28
  

  
  
  
  
  
  

  
  Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
  – Kaz
  May 22 '16 at 15:31
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
  – Vogel612
  May 22 '16 at 18:55
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Can you schedule the meeting at a time when all team members are going to be there?
  – Brandin
  May 23 '16 at 6:23
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
  – Michelfrancis Bustillos
  May 23 '16 at 14:15
  

  
  
  
  

 | 
show 7 more comments

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Why not have stand up at the end of the day when everyone will be in
  – Pepone
  May 22 '16 at 15:25
  

  
  
  
  


• 
  
  
  

  
  28
  

  
  
  
  
  
  

  
  Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
  – Kaz
  May 22 '16 at 15:31
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
  – Vogel612
  May 22 '16 at 18:55
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Can you schedule the meeting at a time when all team members are going to be there?
  – Brandin
  May 23 '16 at 6:23
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
  – Michelfrancis Bustillos
  May 23 '16 at 14:15
  

  
  
  
  

1

1

Why not have stand up at the end of the day when everyone will be in
– Pepone
May 22 '16 at 15:25

Why not have stand up at the end of the day when everyone will be in
– Pepone
May 22 '16 at 15:25

28

28

Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
– Kaz
May 22 '16 at 15:31

Either you have completely flexible hours, or you have meetings where attendance is mandatory. You cannot have both.
– Kaz
May 22 '16 at 15:31

2

2

Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
– Vogel612
May 22 '16 at 18:55

Related: Scrum doesn't per se require the Scrum Master to be present during Standup. I just says that the Scrum Master should lead the "Meeting" to be productive. This can also mean effective self-empowerment of your development team. Teach them to "moderate" the standup themselves, then you don't have to be present per se
– Vogel612
May 22 '16 at 18:55

1

1

Can you schedule the meeting at a time when all team members are going to be there?
– Brandin
May 23 '16 at 6:23

Can you schedule the meeting at a time when all team members are going to be there?
– Brandin
May 23 '16 at 6:23

1

1

Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
– Michelfrancis Bustillos
May 23 '16 at 14:15

Have you considered having a meeting where members can dial in, such as TeamViewer or GoToMeeting?
– Michelfrancis Bustillos
May 23 '16 at 14:15

 | 
show 7 more comments

7 Answers
7

active

oldest

votes

up vote
12
down vote

In Europe it is a 5 day week. Most companies work up to 40 hours per week in software engineering.

We have core hours 10-4 where everybody that is not on holiday should be around. You can have up to an hour off for lunch (most take 1/2 hour).

Would this system work for you?

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I think (as a European) having a software house open 7 days a week is stupid
  – Ed Heal
  May 22 '16 at 11:25
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
  – Ed Heal
  May 22 '16 at 11:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
  – Ed Heal
  May 22 '16 at 11:58
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  If you have a day off, why would you phone into work?
  – Ed Heal
  May 22 '16 at 12:46
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
  – Monica Cellio♦
  May 22 '16 at 18:46
  

  
  
  
  

 | 
show 7 more comments

up vote
9
down vote

You have identified a key conflict between traditional scrum methodology, and the ever more popular flexible working environments employers are moving towards.

If the company supports the flexible working system, and staff are not required to be there at 09:30, then you will have to work your agile teaming around it.

Two simple solutions occur to me:

• Appoint a scrum deputy, so you can delegate for times you aren't there


• Allow for two standup meetings a day - so you or your deputy can engage all the staff

Otherwise the flexible working policy is not going to work for you, and you'll end up worn out.

Another alternative is to request attendance for key scrum sprints - perhaps at the start and end of important stages.

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Coooooool ideas !
  – Michel Gokan
  May 22 '16 at 11:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
  – Rory Alsop
  May 22 '16 at 11:11
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  See Ed Heal response under in the comments under his answer. What do you think?
  – Michel Gokan
  May 22 '16 at 12:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
  – Rory Alsop
  May 22 '16 at 12:02
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
  – Lumberjack
  May 22 '16 at 14:22
  

  
  
  
  

 | 
show 1 more comment

up vote
7
down vote

I think you need to leave this to the team to solve. They're all intelligent people who should want to put a little effort into solving this problem unless they all want to lose their flextime.

Make sure the company policy and your goal of the meeting is being met. I hope that goal goes beyond just getting everyone in the same room at the same time. That seems like a waste. This may require more documentation about meetings and providing information people in the people may need when someone is absent.

Someone missing a day of the week shouldn't be that big of a problem. Vacations and unscheduled absences happen. The goal of being agile is to be able to handle these situations and not make adhering to some process be the problem.

share|improve this answer

answered May 23 '16 at 18:11

user8365

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
  – Michel Gokan
  May 23 '16 at 18:19
  
  

  
  
  
  

suggest improvements | 

up vote
4
down vote

Remember: agile is about being agile, not following the rules as laid down in the holy book of Scrum as if they were scripture.

That means you can, and should, change them.

You have problems with the standups being difficult to schedule. So get rid of them. Replace them with some other way of communicating workload to the rest of the team, maybe emails, a scrum or other project website, or a "social media" style feed of updates from every team member. Then your standups will be rolling, continuous updates.

Whatever you choose, the point is that you change it to suit your team. Scrum was never very agile in the first place, but its important to force it to be so for you.

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
  – zebonaut
  Aug 23 '17 at 11:01
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
  – gbjbaanb
  Aug 23 '17 at 16:55
  
  

  
  
  
  

suggest improvements | 

up vote
3
down vote

Having a 'flexible working hours' policy actually ends up causing the same symptoms that distributed teams need to contend with. Some teams are scattered around the world across many different timezones and need to contend with this if they wish to practice Agile/Scrum.

Distributed teams don't share office space, or a common point in time that each team member can call "the start of their day". Therefore, they need to take their communication offline. Consider a dedicated Slack room where everyone can submit their updates.

As a Scrum Master for a distributed team, I sympathise with the organisational change you're going through - it is a tough problem to solve, and to solve well. I tweet about these problems at @albieio including experiments to improve remote Agile.

---

share|improve this answer

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
  – Michel Gokan
  May 23 '16 at 18:23
  

  
  
  
  

suggest improvements | 

up vote
3
down vote

You are scrum master/team lead so you have the opportunity to change this.

Call a retrospective (or whatever you would like to call it) about this aspect about work. Explain that you can't work 7 days a week and that the current system isn't working for you. Allow everyone in the team to voice their opinions (perhaps give them some prep time to bring along a positive, a negative and an aspect they would change) and ultimately work towards a system that works for everyone in the team. This may seem impossible to start with, but it could be implemented piece by piece to begin with, with a perfect solution in mind to guide you.

I think you should have the team agree to be all together at least twice a week, so you are all touching base. I think the deputy solution would also be beneficial here.

You should make the flexible rules work for you too, don't work 7 days a week if that doesn't work for you. There is a compromise.

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

suggest improvements | 

up vote
1
down vote

I agree with the point that this is a team problem. Your group is going to have to figure out what the most critical elements of the scrum are and how they will get met, and what happens if they aren't met in a given time frame. Certainly as scrum master your job is to make sure that blockers to the team are eliminated and that the team is able to be self-managing. But that doesn't mean that you personally need to be there 24/7/365.

Here's some specific ideas...

Status

Figure out a not-in-person status mechanism for some days. Either when you are out, or when a critical mass of the team is out. Find a way for status to persist so that team members gone for a day can catch up when they are back (like email, or a task board, or other out of band transmission).

Make team time planning part of your sprint cadence

The team commits to a cadence, the team commits to their time out of the office - make the team's monthly commitment align with the sprint plan, so they are accountable to each other (and you) in both what they do and when they take off. Make sure that regular team must-dos are covered in the time off plans.

Note, that doesn't need to mean that the team must go back to M-F 10-4 type commitment. If scrums MWF at 2:00PM and Sat, Tues, Thurs. at 8:00 AM work and there's deputy for half of those that does a meetup with you every other day... then as long as everyone gets what they need - great. But the team needs some sort of agreement.

Mentoring/Pair Programming

You may also need to provide some overall guidance on this area. The newest colleague, for example, may need to commit to a training period where they always are working with someone at hand - so if no one else is in on Saturday, then the new guy may not be able to choose Saturday either. Similarly, I tend to hold my most senior engineers most accountable for providing good guidance - so they may have to make sure that 80% of their time is spend with at least 60% of the group around - or something similar. This one is often grumbled about - because needing to guide others DOES reduce one's ability to focus completely on software work. The goal has to be does the entire team benefit - not one single individual's work.

Really good handoff

If you have people working wildly off of a norm (say that most of the team works 9 AM-6 PM and one person wants 7PM - 4AM) - you may need to force the point that there is SOME level of coordination required with in-person availability for X meetups per week or month. It's hard to believe that someone can work in a team situation where they are completely disjoint in scheduling from the whole team.

If they really, really can work that independently, you'll still need to scope how they report in, how they get help, how they coordinate work. It's totally OK to put the onus on your person who wants to diverge from the herd and to ask them to take the greatest accountability for keeping in touch.

Final Thought

If you really want to keep the super flexible schedule, you need to develop a really critical definition of what success or failure looks like for the output of an individual - not just the quality of the individual's technical work, but also their soft skills and their ability to be on a team. That kind of accountability is necessary if folks really want this level of independence. If they don't want to take the accountability as individuals, then they don't get the privilege to set highly individualistic schedules.

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

suggest improvements | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67519%2fhow-to-deal-with-different-daily-working-hours-in-a-software-company%23new-answer', 'question_page');

);

Post as a guest

Name Email

StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;

var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');

$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');

pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);

)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();


);
);

7 Answers
7

active

oldest

votes

7 Answers
7

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
12
down vote

In Europe it is a 5 day week. Most companies work up to 40 hours per week in software engineering.

We have core hours 10-4 where everybody that is not on holiday should be around. You can have up to an hour off for lunch (most take 1/2 hour).

Would this system work for you?

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I think (as a European) having a software house open 7 days a week is stupid
  – Ed Heal
  May 22 '16 at 11:25
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
  – Ed Heal
  May 22 '16 at 11:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
  – Ed Heal
  May 22 '16 at 11:58
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  If you have a day off, why would you phone into work?
  – Ed Heal
  May 22 '16 at 12:46
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
  – Monica Cellio♦
  May 22 '16 at 18:46
  

  
  
  
  

 | 
show 7 more comments

up vote
12
down vote

In Europe it is a 5 day week. Most companies work up to 40 hours per week in software engineering.

We have core hours 10-4 where everybody that is not on holiday should be around. You can have up to an hour off for lunch (most take 1/2 hour).

Would this system work for you?

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I think (as a European) having a software house open 7 days a week is stupid
  – Ed Heal
  May 22 '16 at 11:25
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
  – Ed Heal
  May 22 '16 at 11:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
  – Ed Heal
  May 22 '16 at 11:58
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  If you have a day off, why would you phone into work?
  – Ed Heal
  May 22 '16 at 12:46
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
  – Monica Cellio♦
  May 22 '16 at 18:46
  

  
  
  
  

 | 
show 7 more comments

up vote
12
down vote

up vote
12
down vote

In Europe it is a 5 day week. Most companies work up to 40 hours per week in software engineering.

We have core hours 10-4 where everybody that is not on holiday should be around. You can have up to an hour off for lunch (most take 1/2 hour).

Would this system work for you?

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

In Europe it is a 5 day week. Most companies work up to 40 hours per week in software engineering.

We have core hours 10-4 where everybody that is not on holiday should be around. You can have up to an hour off for lunch (most take 1/2 hour).

Would this system work for you?

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

share|improve this answer

share|improve this answer

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

edited May 22 '16 at 11:35

Kilisi

94.5k50216376

94.5k50216376

answered May 22 '16 at 11:17

Ed Heal

8,33421440

answered May 22 '16 at 11:17

Ed Heal

8,33421440

answered May 22 '16 at 11:17

Ed Heal

8,33421440

8,33421440

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I think (as a European) having a software house open 7 days a week is stupid
  – Ed Heal
  May 22 '16 at 11:25
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
  – Ed Heal
  May 22 '16 at 11:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
  – Ed Heal
  May 22 '16 at 11:58
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  If you have a day off, why would you phone into work?
  – Ed Heal
  May 22 '16 at 12:46
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
  – Monica Cellio♦
  May 22 '16 at 18:46
  

  
  
  
  

 | 
show 7 more comments

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  I think (as a European) having a software house open 7 days a week is stupid
  – Ed Heal
  May 22 '16 at 11:25
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
  – Ed Heal
  May 22 '16 at 11:31
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
  – Ed Heal
  May 22 '16 at 11:58
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  If you have a day off, why would you phone into work?
  – Ed Heal
  May 22 '16 at 12:46
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
  – Monica Cellio♦
  May 22 '16 at 18:46
  

  
  
  
  

4

4

I think (as a European) having a software house open 7 days a week is stupid
– Ed Heal
May 22 '16 at 11:25

I think (as a European) having a software house open 7 days a week is stupid
– Ed Heal
May 22 '16 at 11:25

1

1

@JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
– Ed Heal
May 22 '16 at 11:31

@JoeStrazzere - Would flipping between Scrum master and the deputy work each week for the couple of days? I would think not as it is difficult enough to flip once in a while when somebody goes on holiday. Can they get the whole picture?
– Ed Heal
May 22 '16 at 11:31

1

1

@MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
– Ed Heal
May 22 '16 at 11:58

@MichelGokan - Please could you tell me when switching to/from a deputy it works. People tend to forget to tell the other things. This is ok when it is a few times a year - but each week
– Ed Heal
May 22 '16 at 11:58

2

2

If you have a day off, why would you phone into work?
– Ed Heal
May 22 '16 at 12:46

If you have a day off, why would you phone into work?
– Ed Heal
May 22 '16 at 12:46

1

1

I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
– Monica Cellio♦
May 22 '16 at 18:46

I've worked for several software companies in the US that had core hours -- we expect everybody to be here on weekdays between 10 and 4 (except lunch) unless you're on vacation or the like, and you're free to flex the rest of the time however you want. 10-4 is common in my experience but it doesn't have to be that; if a smaller core (to allow more flexibility) meets your needs for collaboration, go ahead and change it.
– Monica Cellio♦
May 22 '16 at 18:46

 | 
show 7 more comments

up vote
9
down vote

You have identified a key conflict between traditional scrum methodology, and the ever more popular flexible working environments employers are moving towards.

If the company supports the flexible working system, and staff are not required to be there at 09:30, then you will have to work your agile teaming around it.

Two simple solutions occur to me:

• Appoint a scrum deputy, so you can delegate for times you aren't there


• Allow for two standup meetings a day - so you or your deputy can engage all the staff

Otherwise the flexible working policy is not going to work for you, and you'll end up worn out.

Another alternative is to request attendance for key scrum sprints - perhaps at the start and end of important stages.

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Coooooool ideas !
  – Michel Gokan
  May 22 '16 at 11:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
  – Rory Alsop
  May 22 '16 at 11:11
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  See Ed Heal response under in the comments under his answer. What do you think?
  – Michel Gokan
  May 22 '16 at 12:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
  – Rory Alsop
  May 22 '16 at 12:02
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
  – Lumberjack
  May 22 '16 at 14:22
  

  
  
  
  

 | 
show 1 more comment

up vote
9
down vote

You have identified a key conflict between traditional scrum methodology, and the ever more popular flexible working environments employers are moving towards.

If the company supports the flexible working system, and staff are not required to be there at 09:30, then you will have to work your agile teaming around it.

Two simple solutions occur to me:

• Appoint a scrum deputy, so you can delegate for times you aren't there


• Allow for two standup meetings a day - so you or your deputy can engage all the staff

Otherwise the flexible working policy is not going to work for you, and you'll end up worn out.

Another alternative is to request attendance for key scrum sprints - perhaps at the start and end of important stages.

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Coooooool ideas !
  – Michel Gokan
  May 22 '16 at 11:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
  – Rory Alsop
  May 22 '16 at 11:11
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  See Ed Heal response under in the comments under his answer. What do you think?
  – Michel Gokan
  May 22 '16 at 12:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
  – Rory Alsop
  May 22 '16 at 12:02
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
  – Lumberjack
  May 22 '16 at 14:22
  

  
  
  
  

 | 
show 1 more comment

up vote
9
down vote

up vote
9
down vote

You have identified a key conflict between traditional scrum methodology, and the ever more popular flexible working environments employers are moving towards.

If the company supports the flexible working system, and staff are not required to be there at 09:30, then you will have to work your agile teaming around it.

Two simple solutions occur to me:

• Appoint a scrum deputy, so you can delegate for times you aren't there


• Allow for two standup meetings a day - so you or your deputy can engage all the staff

Otherwise the flexible working policy is not going to work for you, and you'll end up worn out.

Another alternative is to request attendance for key scrum sprints - perhaps at the start and end of important stages.

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

You have identified a key conflict between traditional scrum methodology, and the ever more popular flexible working environments employers are moving towards.

If the company supports the flexible working system, and staff are not required to be there at 09:30, then you will have to work your agile teaming around it.

Two simple solutions occur to me:

• Appoint a scrum deputy, so you can delegate for times you aren't there


• Allow for two standup meetings a day - so you or your deputy can engage all the staff

Otherwise the flexible working policy is not going to work for you, and you'll end up worn out.

Another alternative is to request attendance for key scrum sprints - perhaps at the start and end of important stages.

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

share|improve this answer

share|improve this answer

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

answered May 22 '16 at 11:03

Rory Alsop

5,55612340

5,55612340

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Coooooool ideas !
  – Michel Gokan
  May 22 '16 at 11:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
  – Rory Alsop
  May 22 '16 at 11:11
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  See Ed Heal response under in the comments under his answer. What do you think?
  – Michel Gokan
  May 22 '16 at 12:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
  – Rory Alsop
  May 22 '16 at 12:02
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
  – Lumberjack
  May 22 '16 at 14:22
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Coooooool ideas !
  – Michel Gokan
  May 22 '16 at 11:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
  – Rory Alsop
  May 22 '16 at 11:11
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  See Ed Heal response under in the comments under his answer. What do you think?
  – Michel Gokan
  May 22 '16 at 12:00
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
  – Rory Alsop
  May 22 '16 at 12:02
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  +1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
  – Lumberjack
  May 22 '16 at 14:22
  

  
  
  
  

Coooooool ideas !
– Michel Gokan
May 22 '16 at 11:06

Coooooool ideas !
– Michel Gokan
May 22 '16 at 11:06

1

1

We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
– Rory Alsop
May 22 '16 at 11:11

We run quite a flexible team here, with everyone allowed to work two days a week from home, and a choice of offices, so we keep updating options to make it work effectively
– Rory Alsop
May 22 '16 at 11:11

See Ed Heal response under in the comments under his answer. What do you think?
– Michel Gokan
May 22 '16 at 12:00

See Ed Heal response under in the comments under his answer. What do you think?
– Michel Gokan
May 22 '16 at 12:00

I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
– Rory Alsop
May 22 '16 at 12:02

I think he's answering a different question, tbh. It sounds like you just don't have those fixed hours ago my answer is on how to make that work.
– Rory Alsop
May 22 '16 at 12:02

+1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
– Lumberjack
May 22 '16 at 14:22

+1 For both of your suggested solutions. You could establish the key scrum attendance periods before the beginning of the month, and send those out for people to consider when setting their monthly "schedule."
– Lumberjack
May 22 '16 at 14:22

 | 
show 1 more comment

up vote
7
down vote

I think you need to leave this to the team to solve. They're all intelligent people who should want to put a little effort into solving this problem unless they all want to lose their flextime.

Make sure the company policy and your goal of the meeting is being met. I hope that goal goes beyond just getting everyone in the same room at the same time. That seems like a waste. This may require more documentation about meetings and providing information people in the people may need when someone is absent.

Someone missing a day of the week shouldn't be that big of a problem. Vacations and unscheduled absences happen. The goal of being agile is to be able to handle these situations and not make adhering to some process be the problem.

share|improve this answer

answered May 23 '16 at 18:11

user8365

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
  – Michel Gokan
  May 23 '16 at 18:19
  
  

  
  
  
  

suggest improvements | 

up vote
7
down vote

I think you need to leave this to the team to solve. They're all intelligent people who should want to put a little effort into solving this problem unless they all want to lose their flextime.

Make sure the company policy and your goal of the meeting is being met. I hope that goal goes beyond just getting everyone in the same room at the same time. That seems like a waste. This may require more documentation about meetings and providing information people in the people may need when someone is absent.

Someone missing a day of the week shouldn't be that big of a problem. Vacations and unscheduled absences happen. The goal of being agile is to be able to handle these situations and not make adhering to some process be the problem.

share|improve this answer

answered May 23 '16 at 18:11

user8365

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
  – Michel Gokan
  May 23 '16 at 18:19
  
  

  
  
  
  

suggest improvements | 

up vote
7
down vote

up vote
7
down vote

I think you need to leave this to the team to solve. They're all intelligent people who should want to put a little effort into solving this problem unless they all want to lose their flextime.

Make sure the company policy and your goal of the meeting is being met. I hope that goal goes beyond just getting everyone in the same room at the same time. That seems like a waste. This may require more documentation about meetings and providing information people in the people may need when someone is absent.

Someone missing a day of the week shouldn't be that big of a problem. Vacations and unscheduled absences happen. The goal of being agile is to be able to handle these situations and not make adhering to some process be the problem.

share|improve this answer

answered May 23 '16 at 18:11

user8365

I think you need to leave this to the team to solve. They're all intelligent people who should want to put a little effort into solving this problem unless they all want to lose their flextime.

Make sure the company policy and your goal of the meeting is being met. I hope that goal goes beyond just getting everyone in the same room at the same time. That seems like a waste. This may require more documentation about meetings and providing information people in the people may need when someone is absent.

Someone missing a day of the week shouldn't be that big of a problem. Vacations and unscheduled absences happen. The goal of being agile is to be able to handle these situations and not make adhering to some process be the problem.

share|improve this answer

answered May 23 '16 at 18:11

user8365

share|improve this answer

share|improve this answer

answered May 23 '16 at 18:11

user8365

answered May 23 '16 at 18:11

user8365

answered May 23 '16 at 18:11

user8365

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
  – Michel Gokan
  May 23 '16 at 18:19
  
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
  – Michel Gokan
  May 23 '16 at 18:19
  
  

  
  
  
  

I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
– Michel Gokan
May 23 '16 at 18:19

I agree with you. Actually I had a meeting with everyone a few days ago and asked them about the situation but we couldn't came up with a solution. That's why I'm asking the community. But anyway I agree with, maybe we have to put more time with the team about this issue AND get use of these great answers and comments here as a guideline.
– Michel Gokan
May 23 '16 at 18:19

suggest improvements | 

up vote
4
down vote

Remember: agile is about being agile, not following the rules as laid down in the holy book of Scrum as if they were scripture.

That means you can, and should, change them.

You have problems with the standups being difficult to schedule. So get rid of them. Replace them with some other way of communicating workload to the rest of the team, maybe emails, a scrum or other project website, or a "social media" style feed of updates from every team member. Then your standups will be rolling, continuous updates.

Whatever you choose, the point is that you change it to suit your team. Scrum was never very agile in the first place, but its important to force it to be so for you.

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
  – zebonaut
  Aug 23 '17 at 11:01
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
  – gbjbaanb
  Aug 23 '17 at 16:55
  
  

  
  
  
  

suggest improvements | 

up vote
4
down vote

Remember: agile is about being agile, not following the rules as laid down in the holy book of Scrum as if they were scripture.

That means you can, and should, change them.

You have problems with the standups being difficult to schedule. So get rid of them. Replace them with some other way of communicating workload to the rest of the team, maybe emails, a scrum or other project website, or a "social media" style feed of updates from every team member. Then your standups will be rolling, continuous updates.

Whatever you choose, the point is that you change it to suit your team. Scrum was never very agile in the first place, but its important to force it to be so for you.

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
  – zebonaut
  Aug 23 '17 at 11:01
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
  – gbjbaanb
  Aug 23 '17 at 16:55
  
  

  
  
  
  

suggest improvements | 

up vote
4
down vote

up vote
4
down vote

Remember: agile is about being agile, not following the rules as laid down in the holy book of Scrum as if they were scripture.

That means you can, and should, change them.

You have problems with the standups being difficult to schedule. So get rid of them. Replace them with some other way of communicating workload to the rest of the team, maybe emails, a scrum or other project website, or a "social media" style feed of updates from every team member. Then your standups will be rolling, continuous updates.

Whatever you choose, the point is that you change it to suit your team. Scrum was never very agile in the first place, but its important to force it to be so for you.

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

Remember: agile is about being agile, not following the rules as laid down in the holy book of Scrum as if they were scripture.

That means you can, and should, change them.

You have problems with the standups being difficult to schedule. So get rid of them. Replace them with some other way of communicating workload to the rest of the team, maybe emails, a scrum or other project website, or a "social media" style feed of updates from every team member. Then your standups will be rolling, continuous updates.

Whatever you choose, the point is that you change it to suit your team. Scrum was never very agile in the first place, but its important to force it to be so for you.

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

share|improve this answer

share|improve this answer

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

answered May 24 '16 at 13:13

gbjbaanb

2,2261019

2,2261019

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
  – zebonaut
  Aug 23 '17 at 11:01
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
  – gbjbaanb
  Aug 23 '17 at 16:55
  
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
  – zebonaut
  Aug 23 '17 at 11:01
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
  – gbjbaanb
  Aug 23 '17 at 16:55
  
  

  
  
  
  

Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
– zebonaut
Aug 23 '17 at 11:01

Before my company went agile/scrum, we had weekly project meetings, and they were fantastic. A week gives you enough time and mental flexibility to do a good job and not just hustle from post-it to post-it. With daily meetings (a.k.a. stand-ups), we get interrupted during what might be the most productive time of the day, and we try to justify every hour's worth of time, which is just not suitable for most of the work developers do. Getting rid of dailies should be the main focus for most Agile Coaches if they want productive teams.
– zebonaut
Aug 23 '17 at 11:01

1

1

@zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
– gbjbaanb
Aug 23 '17 at 16:55

@zebonaut yup. I worked at a place where the dailies were set at 9:30. What this meant in practice was that you killed time waiting for 9:30 meeting, and then the day of work started at 10am. An hour effectively wasted every day for nothing useful.
– gbjbaanb
Aug 23 '17 at 16:55

suggest improvements | 

up vote
3
down vote

Having a 'flexible working hours' policy actually ends up causing the same symptoms that distributed teams need to contend with. Some teams are scattered around the world across many different timezones and need to contend with this if they wish to practice Agile/Scrum.

Distributed teams don't share office space, or a common point in time that each team member can call "the start of their day". Therefore, they need to take their communication offline. Consider a dedicated Slack room where everyone can submit their updates.

As a Scrum Master for a distributed team, I sympathise with the organisational change you're going through - it is a tough problem to solve, and to solve well. I tweet about these problems at @albieio including experiments to improve remote Agile.

---

share|improve this answer

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
  – Michel Gokan
  May 23 '16 at 18:23
  

  
  
  
  

suggest improvements | 

up vote
3
down vote

Having a 'flexible working hours' policy actually ends up causing the same symptoms that distributed teams need to contend with. Some teams are scattered around the world across many different timezones and need to contend with this if they wish to practice Agile/Scrum.

Distributed teams don't share office space, or a common point in time that each team member can call "the start of their day". Therefore, they need to take their communication offline. Consider a dedicated Slack room where everyone can submit their updates.

As a Scrum Master for a distributed team, I sympathise with the organisational change you're going through - it is a tough problem to solve, and to solve well. I tweet about these problems at @albieio including experiments to improve remote Agile.

---

share|improve this answer

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
  – Michel Gokan
  May 23 '16 at 18:23
  

  
  
  
  

suggest improvements | 

up vote
3
down vote

up vote
3
down vote

Having a 'flexible working hours' policy actually ends up causing the same symptoms that distributed teams need to contend with. Some teams are scattered around the world across many different timezones and need to contend with this if they wish to practice Agile/Scrum.

Distributed teams don't share office space, or a common point in time that each team member can call "the start of their day". Therefore, they need to take their communication offline. Consider a dedicated Slack room where everyone can submit their updates.

As a Scrum Master for a distributed team, I sympathise with the organisational change you're going through - it is a tough problem to solve, and to solve well. I tweet about these problems at @albieio including experiments to improve remote Agile.

---

share|improve this answer

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

Having a 'flexible working hours' policy actually ends up causing the same symptoms that distributed teams need to contend with. Some teams are scattered around the world across many different timezones and need to contend with this if they wish to practice Agile/Scrum.

Distributed teams don't share office space, or a common point in time that each team member can call "the start of their day". Therefore, they need to take their communication offline. Consider a dedicated Slack room where everyone can submit their updates.

As a Scrum Master for a distributed team, I sympathise with the organisational change you're going through - it is a tough problem to solve, and to solve well. I tweet about these problems at @albieio including experiments to improve remote Agile.

---

share|improve this answer

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

share|improve this answer

share|improve this answer

edited May 23 '16 at 9:44

edited May 23 '16 at 9:44

edited May 23 '16 at 9:44

answered May 23 '16 at 9:39

acairns

1313

answered May 23 '16 at 9:39

acairns

1313

answered May 23 '16 at 9:39

acairns

1313

1313

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
  – Michel Gokan
  May 23 '16 at 18:23
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
  – Michel Gokan
  May 23 '16 at 18:23
  

  
  
  
  

I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
– Michel Gokan
May 23 '16 at 18:23

I worked as a distributed developer many years ago, but we have a constant and non-negotiable daily meeting time everyday and I had to attend in my working-days. But we are not distributed now, we are in the same office and building. I thought it should be easier, but its not. But I agree with you anyway.
– Michel Gokan
May 23 '16 at 18:23

suggest improvements | 

up vote
3
down vote

You are scrum master/team lead so you have the opportunity to change this.

Call a retrospective (or whatever you would like to call it) about this aspect about work. Explain that you can't work 7 days a week and that the current system isn't working for you. Allow everyone in the team to voice their opinions (perhaps give them some prep time to bring along a positive, a negative and an aspect they would change) and ultimately work towards a system that works for everyone in the team. This may seem impossible to start with, but it could be implemented piece by piece to begin with, with a perfect solution in mind to guide you.

I think you should have the team agree to be all together at least twice a week, so you are all touching base. I think the deputy solution would also be beneficial here.

You should make the flexible rules work for you too, don't work 7 days a week if that doesn't work for you. There is a compromise.

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

suggest improvements | 

up vote
3
down vote

You are scrum master/team lead so you have the opportunity to change this.

Call a retrospective (or whatever you would like to call it) about this aspect about work. Explain that you can't work 7 days a week and that the current system isn't working for you. Allow everyone in the team to voice their opinions (perhaps give them some prep time to bring along a positive, a negative and an aspect they would change) and ultimately work towards a system that works for everyone in the team. This may seem impossible to start with, but it could be implemented piece by piece to begin with, with a perfect solution in mind to guide you.

I think you should have the team agree to be all together at least twice a week, so you are all touching base. I think the deputy solution would also be beneficial here.

You should make the flexible rules work for you too, don't work 7 days a week if that doesn't work for you. There is a compromise.

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

suggest improvements | 

up vote
3
down vote

up vote
3
down vote

You are scrum master/team lead so you have the opportunity to change this.

Call a retrospective (or whatever you would like to call it) about this aspect about work. Explain that you can't work 7 days a week and that the current system isn't working for you. Allow everyone in the team to voice their opinions (perhaps give them some prep time to bring along a positive, a negative and an aspect they would change) and ultimately work towards a system that works for everyone in the team. This may seem impossible to start with, but it could be implemented piece by piece to begin with, with a perfect solution in mind to guide you.

I think you should have the team agree to be all together at least twice a week, so you are all touching base. I think the deputy solution would also be beneficial here.

You should make the flexible rules work for you too, don't work 7 days a week if that doesn't work for you. There is a compromise.

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

You are scrum master/team lead so you have the opportunity to change this.

Call a retrospective (or whatever you would like to call it) about this aspect about work. Explain that you can't work 7 days a week and that the current system isn't working for you. Allow everyone in the team to voice their opinions (perhaps give them some prep time to bring along a positive, a negative and an aspect they would change) and ultimately work towards a system that works for everyone in the team. This may seem impossible to start with, but it could be implemented piece by piece to begin with, with a perfect solution in mind to guide you.

I think you should have the team agree to be all together at least twice a week, so you are all touching base. I think the deputy solution would also be beneficial here.

You should make the flexible rules work for you too, don't work 7 days a week if that doesn't work for you. There is a compromise.

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

share|improve this answer

share|improve this answer

answered May 23 '16 at 22:12

fey

41849

answered May 23 '16 at 22:12

fey

41849

answered May 23 '16 at 22:12

fey

41849

41849

suggest improvements | 

suggest improvements | 

up vote
1
down vote

I agree with the point that this is a team problem. Your group is going to have to figure out what the most critical elements of the scrum are and how they will get met, and what happens if they aren't met in a given time frame. Certainly as scrum master your job is to make sure that blockers to the team are eliminated and that the team is able to be self-managing. But that doesn't mean that you personally need to be there 24/7/365.

Here's some specific ideas...

Status

Figure out a not-in-person status mechanism for some days. Either when you are out, or when a critical mass of the team is out. Find a way for status to persist so that team members gone for a day can catch up when they are back (like email, or a task board, or other out of band transmission).

Make team time planning part of your sprint cadence

The team commits to a cadence, the team commits to their time out of the office - make the team's monthly commitment align with the sprint plan, so they are accountable to each other (and you) in both what they do and when they take off. Make sure that regular team must-dos are covered in the time off plans.

Note, that doesn't need to mean that the team must go back to M-F 10-4 type commitment. If scrums MWF at 2:00PM and Sat, Tues, Thurs. at 8:00 AM work and there's deputy for half of those that does a meetup with you every other day... then as long as everyone gets what they need - great. But the team needs some sort of agreement.

Mentoring/Pair Programming

You may also need to provide some overall guidance on this area. The newest colleague, for example, may need to commit to a training period where they always are working with someone at hand - so if no one else is in on Saturday, then the new guy may not be able to choose Saturday either. Similarly, I tend to hold my most senior engineers most accountable for providing good guidance - so they may have to make sure that 80% of their time is spend with at least 60% of the group around - or something similar. This one is often grumbled about - because needing to guide others DOES reduce one's ability to focus completely on software work. The goal has to be does the entire team benefit - not one single individual's work.

Really good handoff

If you have people working wildly off of a norm (say that most of the team works 9 AM-6 PM and one person wants 7PM - 4AM) - you may need to force the point that there is SOME level of coordination required with in-person availability for X meetups per week or month. It's hard to believe that someone can work in a team situation where they are completely disjoint in scheduling from the whole team.

If they really, really can work that independently, you'll still need to scope how they report in, how they get help, how they coordinate work. It's totally OK to put the onus on your person who wants to diverge from the herd and to ask them to take the greatest accountability for keeping in touch.

Final Thought

If you really want to keep the super flexible schedule, you need to develop a really critical definition of what success or failure looks like for the output of an individual - not just the quality of the individual's technical work, but also their soft skills and their ability to be on a team. That kind of accountability is necessary if folks really want this level of independence. If they don't want to take the accountability as individuals, then they don't get the privilege to set highly individualistic schedules.

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

suggest improvements | 

up vote
1
down vote

I agree with the point that this is a team problem. Your group is going to have to figure out what the most critical elements of the scrum are and how they will get met, and what happens if they aren't met in a given time frame. Certainly as scrum master your job is to make sure that blockers to the team are eliminated and that the team is able to be self-managing. But that doesn't mean that you personally need to be there 24/7/365.

Here's some specific ideas...

Status

Figure out a not-in-person status mechanism for some days. Either when you are out, or when a critical mass of the team is out. Find a way for status to persist so that team members gone for a day can catch up when they are back (like email, or a task board, or other out of band transmission).

Make team time planning part of your sprint cadence

The team commits to a cadence, the team commits to their time out of the office - make the team's monthly commitment align with the sprint plan, so they are accountable to each other (and you) in both what they do and when they take off. Make sure that regular team must-dos are covered in the time off plans.

Note, that doesn't need to mean that the team must go back to M-F 10-4 type commitment. If scrums MWF at 2:00PM and Sat, Tues, Thurs. at 8:00 AM work and there's deputy for half of those that does a meetup with you every other day... then as long as everyone gets what they need - great. But the team needs some sort of agreement.

Mentoring/Pair Programming

You may also need to provide some overall guidance on this area. The newest colleague, for example, may need to commit to a training period where they always are working with someone at hand - so if no one else is in on Saturday, then the new guy may not be able to choose Saturday either. Similarly, I tend to hold my most senior engineers most accountable for providing good guidance - so they may have to make sure that 80% of their time is spend with at least 60% of the group around - or something similar. This one is often grumbled about - because needing to guide others DOES reduce one's ability to focus completely on software work. The goal has to be does the entire team benefit - not one single individual's work.

Really good handoff

If you have people working wildly off of a norm (say that most of the team works 9 AM-6 PM and one person wants 7PM - 4AM) - you may need to force the point that there is SOME level of coordination required with in-person availability for X meetups per week or month. It's hard to believe that someone can work in a team situation where they are completely disjoint in scheduling from the whole team.

If they really, really can work that independently, you'll still need to scope how they report in, how they get help, how they coordinate work. It's totally OK to put the onus on your person who wants to diverge from the herd and to ask them to take the greatest accountability for keeping in touch.

Final Thought

If you really want to keep the super flexible schedule, you need to develop a really critical definition of what success or failure looks like for the output of an individual - not just the quality of the individual's technical work, but also their soft skills and their ability to be on a team. That kind of accountability is necessary if folks really want this level of independence. If they don't want to take the accountability as individuals, then they don't get the privilege to set highly individualistic schedules.

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

suggest improvements | 

up vote
1
down vote

up vote
1
down vote

I agree with the point that this is a team problem. Your group is going to have to figure out what the most critical elements of the scrum are and how they will get met, and what happens if they aren't met in a given time frame. Certainly as scrum master your job is to make sure that blockers to the team are eliminated and that the team is able to be self-managing. But that doesn't mean that you personally need to be there 24/7/365.

Here's some specific ideas...

Status

Figure out a not-in-person status mechanism for some days. Either when you are out, or when a critical mass of the team is out. Find a way for status to persist so that team members gone for a day can catch up when they are back (like email, or a task board, or other out of band transmission).

Make team time planning part of your sprint cadence

The team commits to a cadence, the team commits to their time out of the office - make the team's monthly commitment align with the sprint plan, so they are accountable to each other (and you) in both what they do and when they take off. Make sure that regular team must-dos are covered in the time off plans.

Note, that doesn't need to mean that the team must go back to M-F 10-4 type commitment. If scrums MWF at 2:00PM and Sat, Tues, Thurs. at 8:00 AM work and there's deputy for half of those that does a meetup with you every other day... then as long as everyone gets what they need - great. But the team needs some sort of agreement.

Mentoring/Pair Programming

You may also need to provide some overall guidance on this area. The newest colleague, for example, may need to commit to a training period where they always are working with someone at hand - so if no one else is in on Saturday, then the new guy may not be able to choose Saturday either. Similarly, I tend to hold my most senior engineers most accountable for providing good guidance - so they may have to make sure that 80% of their time is spend with at least 60% of the group around - or something similar. This one is often grumbled about - because needing to guide others DOES reduce one's ability to focus completely on software work. The goal has to be does the entire team benefit - not one single individual's work.

Really good handoff

If you have people working wildly off of a norm (say that most of the team works 9 AM-6 PM and one person wants 7PM - 4AM) - you may need to force the point that there is SOME level of coordination required with in-person availability for X meetups per week or month. It's hard to believe that someone can work in a team situation where they are completely disjoint in scheduling from the whole team.

If they really, really can work that independently, you'll still need to scope how they report in, how they get help, how they coordinate work. It's totally OK to put the onus on your person who wants to diverge from the herd and to ask them to take the greatest accountability for keeping in touch.

Final Thought

If you really want to keep the super flexible schedule, you need to develop a really critical definition of what success or failure looks like for the output of an individual - not just the quality of the individual's technical work, but also their soft skills and their ability to be on a team. That kind of accountability is necessary if folks really want this level of independence. If they don't want to take the accountability as individuals, then they don't get the privilege to set highly individualistic schedules.

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

I agree with the point that this is a team problem. Your group is going to have to figure out what the most critical elements of the scrum are and how they will get met, and what happens if they aren't met in a given time frame. Certainly as scrum master your job is to make sure that blockers to the team are eliminated and that the team is able to be self-managing. But that doesn't mean that you personally need to be there 24/7/365.

Here's some specific ideas...

Status

Figure out a not-in-person status mechanism for some days. Either when you are out, or when a critical mass of the team is out. Find a way for status to persist so that team members gone for a day can catch up when they are back (like email, or a task board, or other out of band transmission).

Make team time planning part of your sprint cadence

The team commits to a cadence, the team commits to their time out of the office - make the team's monthly commitment align with the sprint plan, so they are accountable to each other (and you) in both what they do and when they take off. Make sure that regular team must-dos are covered in the time off plans.

Note, that doesn't need to mean that the team must go back to M-F 10-4 type commitment. If scrums MWF at 2:00PM and Sat, Tues, Thurs. at 8:00 AM work and there's deputy for half of those that does a meetup with you every other day... then as long as everyone gets what they need - great. But the team needs some sort of agreement.

Mentoring/Pair Programming

You may also need to provide some overall guidance on this area. The newest colleague, for example, may need to commit to a training period where they always are working with someone at hand - so if no one else is in on Saturday, then the new guy may not be able to choose Saturday either. Similarly, I tend to hold my most senior engineers most accountable for providing good guidance - so they may have to make sure that 80% of their time is spend with at least 60% of the group around - or something similar. This one is often grumbled about - because needing to guide others DOES reduce one's ability to focus completely on software work. The goal has to be does the entire team benefit - not one single individual's work.

Really good handoff

If you have people working wildly off of a norm (say that most of the team works 9 AM-6 PM and one person wants 7PM - 4AM) - you may need to force the point that there is SOME level of coordination required with in-person availability for X meetups per week or month. It's hard to believe that someone can work in a team situation where they are completely disjoint in scheduling from the whole team.

If they really, really can work that independently, you'll still need to scope how they report in, how they get help, how they coordinate work. It's totally OK to put the onus on your person who wants to diverge from the herd and to ask them to take the greatest accountability for keeping in touch.

Final Thought

If you really want to keep the super flexible schedule, you need to develop a really critical definition of what success or failure looks like for the output of an individual - not just the quality of the individual's technical work, but also their soft skills and their ability to be on a team. That kind of accountability is necessary if folks really want this level of independence. If they don't want to take the accountability as individuals, then they don't get the privilege to set highly individualistic schedules.

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

share|improve this answer

share|improve this answer

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

answered May 23 '16 at 22:34

bethlakshmi

70.3k4136277

70.3k4136277

suggest improvements | 

suggest improvements | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67519%2fhow-to-deal-with-different-daily-working-hours-in-a-software-company%23new-answer', 'question_page');

);

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email