Our company is in the process of introducing elements from Scrum in our working process. As we have flexible work time (not completely sure how to say it in English. People can come to work when they want, in some limits, as long as they make their work hours), it's not easy to let the daily Scrum happen really early, as the method recommend it. My first idea would be to define a limit hour to let the Daily Scrum begins, even if everybody is not here, but to begin before this hour if everybody is here. How do you manage it?

  • 2
    In my environment we use the same term - flexible time (or flextime, or "core hours"). You are correct. – Mark C. Wallace Dec 15 '15 at 18:23

Consider the limits that are imposed on people's work hours. Most companies typically maintain "core hours" when all employees are expected to be present (barring exceptional circumstances). It would be a good idea to schedule scrum during those hours. I would suggest keeping it at the same time, even if everybody is present earlier, because doing so would establish a habit.

There will still be days when someone's away due to vacation or an emergency, but that's okay. In a previous job, if someone was away for a day or working from home, they'd typically send out an email to the team with a brief update on the status of their work.

I think even an afternoon scrum could be beneficial with some adjustment from "here's what I did yesterday and will do today" to "here's what I did today and plan to do tomorrow".

  • "here's what I did today" could be taken for granted, meaning you didn't make any commitments for the day, you only reported what you felt doing for the day. – setzamora May 11 '11 at 9:15
  • 1
    @Joset Could be, but it comes down to discipline and personal responsibility. Plus, the other part of it is "what I will do tomorrow", which can be treated as a commitment. – Adam Lear May 11 '11 at 13:42
  • 1
    In my opinion, considering what is said in such a meeting as a commitment is the best way to make these meetings degenerate in blaming-game, which is one of the identified risks. – Alexis Dufrenoy May 11 '11 at 15:53
  • 1
    @Traroth Team dynamics and culture would play a large role in mitigating that. Saying what you plan to do tomorrow is not much different from saying what you plan to do today. All of it is a commitment to get as much of that done as possible. If you're going to slack off and just report what you feel like, scrum won't prevent that regardless of the format used. – Adam Lear May 11 '11 at 16:45

I've run into this before, and seen it handled almost exactly how you describe. We pick a time, usually around 10AM when most people will be at work and we do the Scrum meeting then. If someone isn't there, we just go without them.

As long as you pick a time that corresponds well with the "core hours" of most of your team, you should be pretty safe.

  • 1
    And without the "core hours" it will be hard to introduce for example: pair programming. In most cases "agile" means "cooperation", so how do you cooperate when there is almost nobody around? – Bartosz Rakowski May 11 '11 at 5:25
  • 1
    @Bartosz Rakowski I completely agree. There is no way to really coordinate a team development effort without at least some standard overlap between the hours the engineering team works. – Rain May 11 '11 at 16:03

It's critical that all developers are present for the SCRUM meeting and that absences are the exception rather than the rule. Agile/SCRUM allows you to adapt to changes quickly and you can't do that if everyone is not participating. That being said, you also need the discipline to start on time as to not waste anyone's time. It may take a while, but teams usually get used to the SCRUM starting time as it becomes part of the culture.


This is a dicipline thing - you need your scrum developers to have some sort of discipline. They are being paid to code after all. The scrum is a core part of the methodology and a part of how the PM keeps track of what is going on.

Firstly, before changing anything or getting heavy handed, check with HR (or the contracts directly) there will almost always be a clause about hours in the office. Use this as your starting point.

10am is not unrealistic as a scrum time; however, it does tend to interrupt the flow for people who get there early, so try for earlier if you can.

The key thing is that all developers should be there. If you have one dev who starts late and thus is never at the scrum, he or she will always be behind. He/she won't get the benefit of the shared learning and will never really get Scrum as a whole.


Martin Fowler answers these questions (and more!) about stand-ups beautifully in the following article - it's the best one I've found about the topic. In it, he says


He also talks about the importance of holding the ceremony at the same time (in the same place) each day. I wouldn't recommend you change the time even if everyone is in the office early.


Take a read here for other recommended stand-up practices: http://martinfowler.com/articles/itsNotJustStandingUp.html


If everyone respects the core hours, then I recommend holding the stand up no later than 30 minutes after core hours start. This gives people a chance to get in, get settled, pour coffee, review what they achieved the day before, then join the stand up.

In general, I prefer having the meeting earlier in the day in order to provide the most time to handle obstacles, but, as always, let the team decide.

Your Answer

