When it comes to scrum rituals, standup is usually a straightforward practice. But what happens to team dynamics when standup isn’t held at the beginning of the day? What works and what challenges are there? These are my observations on holding standup at three different times of the day and the impact on team outcomes.
Iteration 1: 4:45 p.m. Standup
Yes, that’s right. When this project first started, we had standup at 4:45 p.m.. In hindsight, I’m asking the same question you might be: Why? So how did we start here? The answer: Timezones, trust building, and a willingness to try something different.
Context
This was a greenfield project with a client we hadn’t worked with before. To build trust and get to know our client, we welcomed our client attending standup. As our client lived in a different timezone, we were already working two hours ahead of them. Add onto that crammed schedules, and the most logical time to meet was at the end of the day.
What Worked
In the early stages, it was important to have the client present. The team had an opportunity to get to know our client, and we cleared up any blockers with that client. And we build a team culture. Having our client attend standup built trust and connection. Additionally, there was the benefit of not having morning brain and trying to recall what you did yesterday.
What Was Missing
Over time, two challenges became apparent. By the end of the day, the team was tired. Having clarity on what one could commit to at the end of the day was hard. Add to that trying to remember what your team had said when starting your day the next day.
Another challenge was coordinating pairing sessions. The team didn’t have a common point of contact at the start of their day. As a result, team synchronicity began to decline.
Iteration 1.2
First, we wanted to increase visibility in our day. We began an asynchronous Slack morning update. The goal was to align the team around the work for the day and plan for pairing. This helped the team feel more aligned and improved pairing coordination. However, it also added a level of redundancy to the afternoon standup.
As trust grew and the project got underway, the client’s participation in standup was less necessary. As a result, they attended less often. On the one hand, this can signal an increase in trust and autonomy if they feel less of a need to attend. On the other hand, the value of having standup so late in the day declined.
We ran with these new changes for a couple of sprints. Still, the team recognized the need for change. Keeping the door open for the client to attend standup, we looked for a time earlier in the day to move standup to.
Iteration 2: 11:30 a.m. Standup
What worked
This, initially, was a very welcomed change. Key client stakeholders could still attend standup if they wanted to. The team could sync earlier in the day. We could still coordinate pairing for the afternoon. Additionally, this still allowed for our different start time preferences. We disbanded the asynchronous Slack update in favor of our new standup time. All around, this was an improvement on several fronts.
Challenges of a Mid-morning Standup
Moving standup to earlier in the day helped accommodate preferences in working hours. But it opened up new issues. By the time standup rolled around at 11:30 a.m., some of the team had been working for close to three hours. Others who preferred to work later in the day only had about an hour and a half of working time.
With the head start to the day, team needs varied. Some folks already had run into blockers and needed a pair soon. Others were settling into heads-down work and were less open to pairing. This difference meant that coordinating pairing became complicated.
Iteration 2.2
This time, we recognized sooner that a late-morning standup was clunky. It interrupted the day for both those starting early and those starting later in the morning. Accommodating the need for heads-down time and coordinating pairing became a challenge.
At this point in the project, there was solid trust with the client and clear lines of communication. As the team and the scope of work grew, cross-collaboration increased. We had more frequent points of contact through pairing with client-side devs. By this point, the need for the client to attend standup had diminished to zero. Taking into account the current relationship with the client and the team’s pain points, we moved standup yet again.
Iteration 3: 9:45 a.m. Standup
What Works
This is the most “normal” version of standup we tried. Moving standup closer to the beginning of the team’s day had a couple of benefits. There was still flexibility in start time but without letting the day get too far along before coming together as a team. Syncing earlier in the day opened up the remainder of the day to better accommodate team needs. The day was less interrupted by meetings, and it created large blocks of time for pairing and/or heads-down time.
What is Missing
At the beginning of the project, we optimized for allowing the client to join. However, given the trust and touch points established, we were able to maintain engagement. I’d argue that there isn’t anything missing from these standups at the current time.
The Ideal Standup Time Is…
Project, team, and client needs change throughout project lifecycles. Adjusting the standup time was just one way we remained agile by continuing to inspect and adapt. However, in doing so, we exposed new pain points.
In my opinion, holding standup within the first couple of hours of the team’s start time seems most effective. When teams can organize their days together, it allows them to plan and make more efficient use of their day.