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

Question

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

Answer 1

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?

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 of you and your team's 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.

Answer 6

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.

---

Answer 7

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.

Answer 8

We had a similar situation with flexible hours and a distributed team and dealt with it by having standups at a specific time where people were most likely to be around, but on a specific Slack channel. Standups were either via video if people were working from home, or just by text chat. We also did traditional face-to-face standups when attendance made it possible.

If a person was not going to be available they direct messaged their standup statement to the designated scrum master who posted or read it out at the appropriate time.

When a scrum master was not available a senior or lead would take the position, and take notes to pass on to the scrum master so they could deal with blockers (although quite often the team would just come up with a way to handle it during standup).

Retros and planning meetings required everyone to be in the office, but there were generally perks to encourage physical attendance on those dates (the department director paid for beer and food).

Answer 9

I wouldn't call my self an experience expert here, but I'm surprised not to see someone suggesting that you talk to your team, understand why they choose the hours they do and what their underlying interests are.

For example, one may be taking children to/from childcare or school, another may be caring for an elderly relative, another might be flying off to family on Friday afternoon and returning on Monday morning, and another might just have a late-rising chronotype.

Then juggle the times of the meetings to balance them as best you can. After all, you'd do that in a non-work context, so why not a work one, too?

Ultimately staff come to work because working on shared goals helps achieve their own. You're not going to escape trying to understand them anyway if you want to do this stuff well.

Suggestions to just impose a schedule or core hours are a bit of a cop-out, and will lose you the benefits of the flexible working when you might not need to. Are you really going to tell your staff to hire a nanny, miss seeing their family or be sleepy all day (or leave the company) just so that you can schedule a 15-minute chat more easily?

Some people may miss the meeting some days, but that happens anyway. As for having to run the meeting 7 days a week....is there really so much going on at the weekends that you can't deal with it on Friday and Monday? If so, can't someone else run it, just as might happen when you're on holiday, at a conference or sick?

In any case, flexible working doesn't usually mean 'do what you like no matter what your work looks like', it can easily mean 'there are no company wide-requirements, but make sure your work gets done and you find situation-specific solutions with your project manager/line manager'.