Back to back Sprint Reviews & Retrospectives becoming tiring for the team

if some of team members needed to work till late hours to develop & test their items in order to give the demo, they excuse themselves from the Retro, saying they are too tired to attend another 'meeting' after the Review session that goes for 2 hours.

Why are team members working until the late hours for a "demo"? Is that in their Sprint plan? I expect it would tire me out as well.

The first problem that stands out to me is the cases where one or more members of the team need to work late hours to finish their work prior to the Sprint Review.

Consider this statement in the Scrum Guide:

Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

Also, consider this statement from the Manifesto for Agile Software Development:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

It seems like working late is not a sustainable pace. In the short term, it looks like you're already experience issues with participation in your Sprint Retrospective, which is hampering a culture of continuous improvement. In the long term, you may also see team members experiencing burnout. Given the impact, this is the first thing I'd suggest addressing.

The next thing I'd look at is why you need to hold the Sprint Review and Sprint Retrospective back-to-back. There are three events to look at: the Sprint Review, the Sprint Retrospective, and Sprint Planning. Instead of holding the review and retrospective back-to-back, what about holding the review on one day and the retrospective and planning on the next day? What about spreading the events out over three days?

I do think that the limited overlap in working hours is going to cause issues. When Scrum was developed in the early 1990s, it was developed with colocated teams that regularly worked face-to-face. When it comes to distributing teams, there are different options. You can have remote working teams in the same time zone that can, with relative ease, gather face-to-face. You may also have geographically distributed teams with a significant majority (5-8 hours) of their day in overlap. The team could be distributed across a wide geographic area and have a limited number of shared hours (~4). The team could also be globally distributed and have little to no overlap in their working hours. The emphasis of Scrum and associated guidance tends to favor teams that can perform the activities as described in a synchronous manner.

By choosing to have a distributed team, the organization has accepted both the benefits and the risks of one. One of the risks, especially of a widely distributed team, is a reduction in synchronous communication between members of the team. You may need to look at methods for achieving the purpose and intent of the events, but in an asynchronous manner. I would not only recommend looking at the Sprint Review and Sprint Retrospective, but the Sprint Planning as well.

I have a few ideas, but this is something that the team should look at first. It may also depend on what tools the team has access to or what the budget is to acquire new tools to better support globally distributed teams. Fortunately, with the amount of remote work that has happened in the last year or so has led to a lot of options.

How can I help my team to actively participate in both the events, specially the Retros, so that they can discuss on relevant areas of things they did well & areas they struggled with and how can they improve upon in the subsequent Sprints?

@Soumyadeep Mishra, I agree with what others have said about a sustainable pace and being respectful about time, however, a few questions do arise. Does the Sprint Retrospective have to be 1.5 hours? Can this not be shortened in a way that the Scrum Team feels appropriate?

Thanks @Ian Mitchell for your response!

Although its not a regular occurence, it happens sometimes that any left-over work from the previous day spills over on to the last day of the Sprint. And the last day of the Sprint also being a working day for them, I don't see it concerning why they should not work on any of their items.

However, it so happens sometimes that due to some complexities or technical problems involved, they may continue working on that (which includes validation as well) till an hour before the demo. As long as its their decision to continue working on the item and finish them before the demo, I think its indeed sustainable; working on a sustainable pace doesn't mean you should work with plenty of slack, I think it would mean working at a pace at which you're comfortable with and don't burn yourselves out in the process.

The deeper problem is the thinking, the mindset. As I said, they make it an 'excuse' to not attend another 'meeting', which happens to be the Retro, just because they don't want to attend two back to back of these.

Thanks @Thomas Owens for your valuable comments!

As I mentioned in my previous response, its on to the team members to themselves decide what constitute a sustainable pace of work for them; if that includes working late till the demo on some of the Sprints, so be it. I do not see a burnout issue with the team when they work like that in some of their Sprints. Its more like a 'I can do it' attitude that drives them till the late hours.

Coming to re-arranging the sequence of the events, although your suggestion has merit, shifting the Retro to the next day means doing the retro for the previous Sprint on the first day of the next Sprint, because our Sprints typically ends on the 10th day after concluding with the Review and the Retro events. Even if we stretch the previous Sprint to the next day until we finish the Retro, for the team members, it would be a fresh new day and they'll get into the thinking mindset of the next Sprint and will not actively participate in the Retro of the last Sprint. We normally have the Sprint Plannings of the next Sprint on the next day. 

Thanks @Steve Matthew for your response!

I do agree with you that 1.5 hours seem a bit length for the Sprint Retro, although we decided to have 2 hours duration for 15-days Sprint with 1.5 hours Retro. I guess we got it from the Scrum guide that time.

However, even if we reduce it to 1-hour, it'll still mean for some of the team members that they need to stay in another meeting for an hour. I have observed that they typically shut themselves off during the Retro and only answer when asked something specifically (after struggling to get the un-mute button for sometime!).

Nevertheless, I'll bring this up to the team and see what they feel about it. Thanks for your suggestion!

As I mentioned in my previous response, its on to the team members to themselves decide what constitute a sustainable pace of work for them; if that includes working late till the demo on some of the Sprints, so be it. I do not see a burnout issue with the team when they work like that in some of their Sprints. Its more like a 'I can do it' attitude that drives them till the late hours.

Not every individual is good at pacing themselves and setting themselves up for long-term sustainability. Similarly, some people aren't able to see the signs of burning out in themselves. Thus, the organization should be set up in a way that reduces behaviors like working late hours. The Scrum Master and anyone in a management hierarchy should also be watching for signs of burnout among the people they work with and take proactive steps to make a healthy work environment.

Often, once burnout sets in, the treatment options become more limited. It isn't easy to treat burnout while continuing to work in the environment that caused it. This leads to people needing longer periods of time to treat underlying physical and mental health conditions and perhaps even leave the organization. From an organizational perspective, these are costly due to their impact on the rest of the team. Preventing burnout is essential for healthy teams and organizations.

Coming to re-arranging the sequence of the events, although your suggestion has merit, shifting the Retro to the next day means doing the retro for the previous Sprint on the first day of the next Sprint, because our Sprints typically ends on the 10th day after concluding with the Review and the Retro events. Even if we stretch the previous Sprint to the next day until we finish the Retro, for the team members, it would be a fresh new day and they'll get into the thinking mindset of the next Sprint and will not actively participate in the Retro of the last Sprint. We normally have the Sprint Plannings of the next Sprint on the next day. 

Is there anything wrong with this? It seems like you're adding unnecessary constraints. The Scrum Guide only specifies a few rules. One is that the Sprint duration is no more than one month. Another is the ordering of the events, where the Sprint begins with the Sprint Planning and ends with the Sprint Review and Sprint Retrospective, in that order. A third rule is that a new Sprint starts immediately after the conclusion of the previous Sprint. There are also maximum timeboxes for the events.

The first question is if these rules and the other rules of Scrum make sense in your context. These rules were originally developed for colocated teams. Organizations have used them in cases where there is significant overlap in working hours across the team members. Having 3 hours of overlap stretches them beyond their intended use, so I'd consider designing a process that promotes a strong, healthy, agile team over strictly following the rules of Scrum.

Once you get to that point, the question becomes how to enact best the ideas of reviewing the product's state, the state of the team's health and way of working, and planning the next steps for the product. There are good ideas in Scrum, but there are also other sources for ideas as well. Some organizations have written about Agile Software Development with a widely distributed team - Thoughtworks, Basecamp, and others don't necessarily use Scrum, but promote lean and agile ways of working and experience working with distributed teams some publications that could help the team get some ideas.

The deeper problem is the thinking, the mindset. As I said, they make it an 'excuse' to not attend another 'meeting', which happens to be the Retro, just because they don't want to attend two back to back of these.

What are the consequences of this? What is the impact on improvement each Sprint, and who in the organization expects or requires better Sprint outcomes?

Thanks for your inputs @Thomas Owens! 

The points you made around employee burnout are all valid and worth considering. Thanks for bringing those up!

Regarding the agile project management in distributed set up, I did check on Thoughtworks blogs and they indeed are worth pondering upon!

@What are the consequences of this? What is the impact on improvement each Sprint, and who in the organization expects or requires better Sprint outcomes?

The consequences are subtle and long-term. We ideally dont wait for the Retrospectives to bring up any process-improvements or pain points that we observe in the team- we bring it up as and when we observe them. so, in that case, reflection is an ongoing process, so does retrospection. However, Sprint Retrospectives are more like a platform where we try bringing up any points which we may have overlooked or which needs to have a more deeper discussion or introspection.

Better Sprint outcomes are expected by everyone in the organization as well as the client; we just need to work with our team to make them realize the subtle link between better Sprint outcomes and Retrospectives. 

Well, India and the US you only have little overlap in normal working hours, so I understand that this can be stressful. But don't you have a similar issue with Planning sessions?

I also have my team work remotely, fortunately in closer time-zones. But I also see that a web-meeting of 3 hours gets hard, so I do add breaks of 10-15 minutes or even lunch break.

As for the Retrospective itself, if you see that most times the team is tired and silence, you could try to vary the Retrospective. What I have done once was to have 1:1 meetings with everyone from the team to get some direct feedback and brought parts of that into the Retrospective. That way I got some points that were never brought up in Retro. And I once sent out a small kind of survey for the team to answer and used that to go directly to the important points in the Retro. In both cases I had quite a lively Retro.

Better Sprint outcomes are expected by everyone in the organization as well as the client; we just need to work with our team to make them realize the subtle link between better Sprint outcomes and Retrospectives. 

I'd suggest that if you need to work on this "subtle realization":

• the consequences of the present situation might not in truth be clear to the team, and that there is no timely evidence of penalty or of loss resulting from the status-quo
• the need for urgent change is not perhaps being communicated & reinforced by management as robustly as will be needed for agreed Sprint outcomes to be achieved

I'm coming in late but I want to call this out so you can clarify.  Your original post says 

 I am observing that on the last day of the 15-days Sprint when we have

One of your replies you state 

 because our Sprints typically ends on the 10th day after concluding with the Review and the Retro event

There is a 5 day difference that I'm struggling with. Can you help me understand the discrepancy? 

I'm also going to agree with splitting Review and Retrospective.  I had a team that exhibited similar behavior. I suggested to the team that we try having the Review at the end of one day then start the next day with Retrospective and Planning.  The team agreed to try it and found that it worked really well for them.  That way they were able to come in refreshed.  The Retrospective started to provide good discussion with action items and those action items were immediately carried into the Planning event which helped them actually feel an accomplishment and improve. 

The issue you will have is that part of your team will have a day of work with nothing planned for a Sprint but that is not different from what you have now.  

One more thing I want to address.  

The deeper problem is the thinking, the mindset. As I said, they make it an 'excuse' to not attend another 'meeting', which happens to be the Retro, just because they don't want to attend two back to back of these.

However, even if we reduce it to 1-hour, it'll still mean for some of the team members that they need to stay in another meeting for an hour.

This is one I'm going to put on you.  These are not meetings.  They are events.  They have specific purpose and value.  As Scrum Master is your responsibility to help them understand the purpose and value for each event.  It doesn't sound like you have accomplished that objective.  I also have had teams complain about "the meetings".  People do that because they feel like the meetings are ineffective or not productive.  If you want them to respect the events you have to help them understand how the gathering of people for a specific purpose is not a meeting.  Help them to make sure the time they spend is effective.  This is from the 2020 revision of the Scrum Guide's section on the Sprint Retrospective.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

This is what the 2017 Guide said

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

Is the team identifying opportunities for improvement and actually implementing them? You say that you continuously discuss and adapt but are those adaptions working?  When do you discuss if they are? Facilitate the Retrospectives and help them become useful to the team members.  I think you will see an attitude change if you do. I also suggest you look at the other events and evaluate them.  If the Sprint Review is really just a demo as you allude, then you have opportunities to improve there as well.